# ISO 27001 Statement of Applicability > Build and validate the SoA (Clause 6.1.3): map 93 Annex A controls to In/Out with justification and implementation evidence. SoA mapping engine suggests inclusions from risk assessment; control justification audit ensures excluded controls have valid reasons and included controls link to active policies. Tags: ISO 27001, ISMS, Compliance, SoA, Clause 6.1.3, Annex A ## Example Prompts - Suggest which Annex A controls we should include based on our risk assessment - Audit our Statement of Applicability: check exclusions have valid reasons and inclusions link to policies - Draft our ISO 27001 SoA with In/Out and evidence links for every control - Check our SoA for consistency against the scope statement and risk assessment - Generate an evidence reference index from our SoA for audit preparation URL: https://rakenne.app/skills/iso27001-soa/index.md Try this skill: https://rakenne.app/a/?skill=iso27001-soa ## Overview Build and validate the SoA (Clause 6.1.3): map 93 Annex A controls to In/Out with justification and implementation evidence. SoA mapping engine suggests inclusions from risk assessment; control justification audit ensures excluded controls have valid reasons and included controls link to active policies. Aligned with 2026 auditor expectations for "living documents" and evidence-linked SoAs. For a step-by-step walkthrough of how this skill fits into the full ISMS flow, see the [**ISO 27001 ISMS workspace tutorial**](/learn/tutorials/iso27001-isms-workspace-guide/). ## 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: ```markdown ## 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. ``` ```json { "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. --- Back to [Skill Library](https://rakenne.app/skills/index.md)