ISO 27001 Statement of Applicability

Example Conversation

You: We’ve finished our risk assessment. Suggest which Annex A controls we should include in the SoA based on it.

Agent: Running suggest_soa_inclusions on your risk assessment…

Agent: The mapping engine matched risk themes: supplier/cloud, incident management, access and identity, backup and continuity, and policy/governance. It suggests 40+ controls as candidates for In, including A.5.19–A.5.23 (supplier/cloud), A.5.24–A.5.28 (incidents), A.5.15–A.5.18 and A.8.1–A.8.5 (access), A.5.29–A.5.30 and A.8.13–A.8.14 (continuity), and A.5.1, A.5.4, A.5.36, A.5.37 (governance). I’ll draft the full SoA so every one of the 93 controls has In/Out, justification, and where In, a link to a policy or procedure. We don’t develop software in-house, so I’ll mark A.8.25–A.8.34 as Out with justification “No in-house software development.”

You: Draft done. Run the justification audit and check that our policy paths exist.

Agent: I’ll normalize the SoA into the audit format the tool expects, then run control_justification_audit with workspace_root…

Agent: Control justification audit — 2 WARNINGs. A.5.23 references policies/cloud-security.md and the file exists. A.8.13 references docs/backup-procedure.docx but that path was not found under the workspace; please add the file or update the SoA reference. All excluded controls have specific justifications; no generic “N/A” only. Fix the missing evidence path and we can re-run.

What the Tools Validate

The skill includes two extension tools:

suggest_soa_inclusions (SoA mapping engine) suggests which Annex A controls to treat as In based on your risk assessment:

• Reads the risk assessment document (markdown or text) and matches risk themes/keywords (e.g. supplier, incident, access, development, physical, people, backup, cryptography, vulnerability, logging, classification, privacy, policy, legal, network)
• Returns a list of suggested control IDs (e.g. A.5.19–A.5.23 for supplier/cloud, A.5.24–A.5.28 for incidents) with short reasons
• Use after the risk assessment is written to bootstrap the SoA; the full SoA must still address all 93 controls with In/Out and justification

control_justification_audit checks the SoA for clause 6.1.3 and “living document” expectations:

• Excluded controls: Must have a non-empty justification. Generic-only text (e.g. “N/A”, “not applicable”) is reported as an ERROR; specific reasons (e.g. “Company does not develop software”, “No cloud services used”) are required
• Included controls: Must have a justification and a reference to an active policy, procedure, or implementation evidence (policy path, procedure name, or document reference). Missing references are reported as ERROR
• Optional workspace check: If workspace_root is provided, the tool verifies that referenced policy/evidence file paths exist; missing files are reported as WARNING so evidence links stay current

For the smoothest validation flow, normalize the SoA before running the audit tool:

• Preferred: JSON with an entries array using keys such as control_id, status, justification, exclusion_rationale, policy_sections, and implementation_evidence
• Accepted Markdown: One control per block with explicit labels such as Status: applicable, Justification: ..., and Policy: ...
• Accepted Markdown tables: One control per row with explicit Control, Status, Justification, and Implementation evidence columns

Avoid grouped ranges such as A.5.19-A.5.23, multi-control paragraphs, and loose summaries. Use exact IDs like A.5.1 and cover all 93 controls.

Run control_justification_audit after drafting or updating the SoA and before internal review or certification audit.

Auditable Formats

The audit tool works best when the SoA is normalized into one of these structures:

## A.5.1
Status: applicable
Justification: Group-wide ISMS policy set approved by leadership and reviewed annually.
Policy: policies/information-security-policy.md

## A.5.23
Status: applicable
Justification: Cloud services are used for core systems; security requirements are defined in supplier agreements and cloud security policy.
Policy: policies/cloud-security.md

## A.8.25
Status: excluded
Reason: Organisation does not develop software in-house; all development is outsourced.

{
  "entries": [
    {
      "control_id": "A.5.1",
      "status": "applicable",
      "justification": "Group-wide ISMS policy set approved by leadership and reviewed annually.",
      "policy_sections": ["policies/information-security-policy.md"]
    },
    {
      "control_id": "A.8.25",
      "status": "excluded",
      "exclusion_rationale": "Organisation does not develop software in-house; all development is outsourced."
    }
  ]
}

After drafting, normalize the SoA if needed, then run control_justification_audit so every included control links to policy or evidence and every excluded control has a defensible justification.

Getting Started

Add your risk assessment and any existing SoA or policy documents to the project workspace, then activate the ISO 27001 Statement of Applicability skill. The agent will suggest inclusions from the risk assessment, draft or update the SoA with all 93 controls, and validate justification and evidence links with the control justification audit.