Use this after the risk assessment and treatment plan exist, not before: an applicability statement written first is a guess dressed as a decision. You get two files in a new folder, ./soa-first-draft/: a draft statement of applicability as a spreadsheet you can open in Excel, one row per control saying whether it applies, why, how far along it is and where the proof sits (soa.csv), and a short note with the status scale, the mismatches found and the questions for owners (soa-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Control selection is a management decision; the agent proposes it.
Inputs to gather
Read: the scope statement, the risk register and treatment plan, the register of legal, regulatory and contractual obligations if one exists, customer contracts and questionnaire answers that promise specific practices, policies and procedures, and any evidence index or compliance platform export. Then load the list of control identifiers from the reader's licensed copy of the standard or their compliance platform. If neither is available, stop and ask; never reconstruct the control list or its titles from memory. Ask the reader who approves the statement and when the next audit is.
Step 1: collect the reasons to include
For every control identifier, collect every reason it is needed, each with an id, as the first columns of the draft statement (soa.csv):
- Risk: a treated risk in the register whose treatment names this control or an action it covers (R-012).
- Obligation: a law, regulation or contract clause that calls for the practice (OBL-04, or the contract reference).
- Commitment: a customer questionnaire answer, trust page claim or certification promise that says the company does it.
- Baseline: a practice the company runs as a matter of policy even without a specific risk; say why.
A control with at least one reason is included. Record all reasons, not only the first; the auditor reads the reasons to judge whether the risk assessment drove the selection.
Step 2: test exclusions hard
A control is a candidate for exclusion only when no in-scope activity, asset or process exists for it to act on. Write the fact ("no premises of its own; all staff work remotely; the hosting provider operates the data centres") and where an auditor sees that fact. Three reasons are never enough on their own: "not implemented yet" (that is a status, not applicability), "low risk" without a risk id and score, and "the provider handles it" (outsourcing usually moves the control into supplier management, it rarely removes it). For each exclusion, also check the risk register and the commitments from step 1; a contradiction there reverses the exclusion. For a full exclusion review, use the exclusion justification review skill.
Step 3: set implementation status from records
Use one scale and define it in the notes file (soa-notes.md):
- Implemented: operating, and a record from the current period exists. Give the path.
- Implemented, evidence pending: operating, record not yet located.
- In progress: a treatment action is open; give its id and due date.
- Planned: decided, not started.
Take status from the treatment plan and the records, never from the policy alone. Where status is unclear, choose the lower one and add a question for the owner.
Step 4: fill the remaining columns
For each row: control id (bare identifier), included (yes, partial or no; for partial, state which part of the scope it covers and the fact for each half, in the same shape the exclusion justification review uses), reasons (ids), justification in one sentence in the company's terms, status, evidence path and date of that record, owner role, linked treatment action. Flag evidence older than the review cadence as stale. Keep justifications specific to the company: "Customer data in three production databases; R-007 and R-015 treated by encryption at rest and key rotation." A sentence that would fit any company adds nothing.
Step 5: reconcile and hand over
Before handing over, check that every identifier from the licensed list has exactly one row; list absent identifiers first in the notes, since a control missing from the statement is a defect good wording elsewhere cannot cure. Then check both directions: every risk the treatment plan says is reduced by a control points to an included row, and every included row has at least one reason. Record mismatches in the notes file with the decision needed, the versions of the register and treatment plan the draft was built from, and an approval block (version, approver role, date) with the rule that a change to scope, register or treatment plan triggers a re-reconciliation and re-approval. Ask before overwriting existing files. Run a framework lookup for what the standard expects the statement to show, instead of assuming the column set.
What good looks like
- Every included row cites at least one risk, obligation or commitment id; reasons vary row by row.
- The common mistake is a statement where every control is included and implemented. The tell is a young programme showing no In progress rows, or justifications copied unchanged across dozens of rows.
- Exclusions are few, factual and checkable, and none contradicts the risk register or what sales has promised customers.
- Status matches the records: a reviewer opening five random evidence paths finds dated records from the current period.
- Owners are roles that run the practice, and each open action carries a date.
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-first-draft
Rules
- MUST cite at least one risk, obligation, commitment or baseline reason for every included control.
- MUST take control identifiers from the reader's licensed source or platform, never from memory.
- MUST write outputs only inside
./soa-first-draft/ and ask before overwriting.
- NEVER exclude a control because it is not implemented yet.
- NEVER write official control titles or requirement text into the statement; use bare identifiers and the company's own words.
- NEVER record the statement as approved; the approver named by the reader signs it.