soa-exclusion-justification-review

Use this before every certification or surveillance audit, and whenever the scope, the product or the supplier list changes. You get two files in a new folder, ./soa-exclusion-justification-review/: a spreadsheet you can open in Excel with one row per control the company says does not apply, the tests it passed or failed, a verdict and a better-worded reason (exclusion-review.csv), and a short note summarising what should change and the questions for each owner (review-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Reversing or keeping an exclusion is the approver's decision.

Inputs to gather

Read: the statement of applicability (security, privacy or AI extension), the scope statement, the risk register and treatment plan, the asset and system inventory, the supplier list with what each supplier does, records of processing or the AI system inventory where an extension is in play, and the documents the company shows customers (security questionnaire answers, trust page, contract security annexes). Ask the reader who approves the statement and whether any exclusion was challenged at a previous audit.

Step 1: list every exclusion with its current wording

Build the review spreadsheet (exclusion-review.csv) with one row per excluded control: control id (bare identifier), current justification verbatim, and the source path. Also pull rows marked partially applicable; a partial exclusion hides the same weaknesses. First reconcile the statement against the framework's full control list (from the licensed source or a framework lookup): a control that appears nowhere, neither included nor excluded, is a worse defect than a weak justification, so list missing rows first. Mark every exclusion challenged at a previous audit; repeating challenged wording unchanged invites the same finding.

Step 2: run six tests on each exclusion

Answer each test with a fact and a source, not an opinion:

1. Activity: does the company do this kind of thing anywhere in scope, including staff working from home, contractors and teams outside the main office? Remote work and personal devices bring many premises-related practices back into scope.
2. Asset: does any in-scope asset exist that the control would protect (laptops, paper, removable media, source code, a model, a dataset)?
3. Supplier: is the activity done by a supplier? Outsourcing rarely removes a control; it usually moves the company's part into choosing, contracting and monitoring that supplier. "The cloud provider handles it" is a reason to check supplier oversight, not an exclusion.
4. Risk: does any risk in the register touch this topic, or name this control in its treatment, and does any treatment plan action strengthen it? If yes, the exclusion contradicts the risk assessment.
5. Commitment: does a contract, questionnaire answer or public page claim the company does this? If yes, the exclusion contradicts what customers were told.
6. Role: for a privacy or AI extension, does the exclusion rest on a role claim (processor only, uses AI but does not build it)? Check that role against the records of processing, the AI inventory and the contracts. Every employer is a controller for its own staff data, and a company that writes prompts, builds retrieval pipelines or fine-tunes models is doing more than using a tool.

Step 3: give a verdict

• Keep: all six tests support the exclusion and the wording is specific.
• Rewrite: the reason holds, the wording is weak ("N/A", "not relevant", "not applicable to our business").
• Reverse: a test fails; the control should be included, with a status and owner.
• Ask: a fact is missing; name the person by role and the question.

For every Keep and Rewrite, draft the justification in this shape: "Excluded because <fact about the company>. An auditor can see this in <document or record>. Revisit if <trigger, such as opening an office or onboarding a development contractor>." Keep each under 50 words, and name the role that watches for the trigger. For a partial exclusion, state which part is excluded and which applies, with the fact behind each half. Every justification is re-tested at each revision of the statement, whatever the triggers.

Step 4: write the notes

Write the review note (review-notes.md): counts per verdict, the reversals with the risk or commitment that forced them and what including the control will take, the questions per owner, and any pattern (for example, all premises-related controls excluded on a remote-first assumption the laptop fleet contradicts). Where the framework's own expectations for exclusions matter, run a framework lookup instead of assuming. Ask before overwriting.

What good looks like

• Each surviving justification rests on a fact an auditor can check in a named record, plus a trigger that would reopen it.
• The common mistake is excluding whole families of controls because the company is cloud-hosted or remote. The tell is a block of identical justifications covering many controls, and a laptop fleet in the asset list nobody reconciled.
• Reversals are explained by a specific risk id or customer commitment, so the approver understands why the statement grew.
• Exclusions never rely on "not implemented" or "too expensive"; those are treatment questions.
• A good review usually shrinks the exclusion list and makes the remaining entries shorter and sharper.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-soa-exclusion-justification-review

Rules

• MUST run all six tests on every exclusion and cite the source for each answer.
• MUST give every exclusion one verdict: keep, rewrite, reverse or ask.
• MUST write outputs only inside ./soa-exclusion-justification-review/ and ask before overwriting.
• NEVER accept "the supplier handles it" as an exclusion without checking supplier oversight.
• NEVER edit the statement of applicability itself; propose changes for the approver.
• NEVER write official control titles or requirement text; use bare identifiers.