statement-of-applicability-author

name

statement-of-applicability-author

description

Author the Statement of Applicability — the ISO-mandatory document tying every reference control to a per-control inclusion or exclusion justification through the 6.1.3 risk-treatment process; serves BOTH ISO 27001:2022 (Annex A controls) and ISO 42001:2023 (Annex A control objectives) from one procedure. Rows record include/exclude with a risk-or-obligation trace, implementation status mapped to the compliance-control-foundation catalog, and controlled-document metadata (version, named approver). Requires the licensed standard's actual Annex A table — never reconstructs entries or counts from memory or secondary sources. The largest net-new ISO artifact SOC 2 lacks. Use when asked to write or update an SoA, or when ISO 27001/42001 certification prep reaches the applicability document. Do NOT use for the whole management system (iso-27001-isms-architect / iso-42001-aims-architect), the control catalog (compliance-control-foundation), or cross-framework references (multi-framework-crosswalk).

Statement of Applicability Author

Purpose

Produce the Statement of Applicability (SoA) — the document ISO certification audits open first: for every control in the standard's Annex A, is it applicable to this organization, why (traced to the 6.1.3 risk-treatment process or an obligation), and what is its implementation state. One procedure serves both certifiable ISO standards — ISO 27001:2022 (Annex A "Information security controls reference", normative) and ISO 42001:2023 (Annex A "Reference control objectives and controls", normative) — because the SoA logic is identical even though the control lists differ. Implementation status maps to the compliance-control-foundation catalog so the SoA points at real mechanisms, not aspirations. The SoA is a controlled document: this skill authors proposals and diffs, with versioning and a named approver — it never silently rewrites an operating SoA.

Use When

• Use when: asked to write, draft, or update a Statement of Applicability for ISO 27001, ISO 42001, or both.
• Use when: ISO certification prep reaches the point of deciding which Annex A controls/objectives apply and justifying exclusions.
• Use when: the risk-treatment process (6.1.3) has produced treatment decisions that must be reflected as control applicability.
• Do NOT use when: designing the management system around the SoA — iso-27001-isms-architect / iso-42001-aims-architect (they mandate and consume the SoA; this skill writes it).
• Do NOT use when: authoring the framework-agnostic control catalog (compliance-control-foundation) or mapping controls across frameworks (multi-framework-crosswalk).
• Do NOT use when: SOC 2 work — SOC 2 has no SoA; scoping lives in soc2-trust-criteria-mapper.

Inputs to Inspect

1. The licensed standard text's Annex A table for the target standard(s) — the actual control IDs, titles, and (for 42001) control objectives. This input is hard-required; see Stop Conditions.
2. Risk-treatment outputs: the risk register and treatment decisions the 6.1.3 process produced (technical inputs from threat-modeler / ai-threat-modeler; for 42001, AI risk and impact assessments from iso-42001-aims-architect's 6.1.2/6.1.4 machinery).
3. The compliance-control-foundation catalog and multi-framework-crosswalk rows — what mechanisms exist for each included control and where they live.
4. Legal/contractual/regulatory obligations that force inclusion independent of risk appetite.
5. Any existing SoA (version, approver, last review) — updates are diffs against it, never replacements.

Workflow

1. Confirm target standard(s) and obtain Annex A. ISO 27001:2022, ISO 42001:2023, or both (two SoAs or one combined document with per-standard columns — org's choice, recorded). Without the licensed Annex A table, stop.
2. Assemble the row skeleton from the actual Annex A entries using assets/soa-template.md. Never paraphrase control titles — quote them as the standard writes them.
3. Decide applicability per control. Include when a risk-treatment decision selects it or an obligation requires it; exclude only with a justification that survives an auditor ("no mobile app development" — concrete, verifiable), traced to the risk assessment scope.
4. Justify inclusions by trace. Each included control cites the risk(s) it treats or the obligation demanding it — "best practice" is not a justification; that's how SoAs bloat into unauditable checklists.
5. Record implementation status per included control by mapping to the foundation catalog: implemented (mechanism named) / partial (residue named) / planned (owner + date). The SoA never claims implemented without a mechanism to point at.
6. Apply controlled-document discipline. Version, date, author, named approver, review cadence; changes to an existing SoA are proposed as a reviewable diff with rationale per changed row (human-approval-boundary for approval).
7. Hand off. SoA → the owning ISO projection (internal audit and management review consume it), compliance-evidence-collector (included controls need operating evidence), compliance-gap-auditor (planned/partial rows are gaps with owners).

Output Format

STATEMENT OF APPLICABILITY — <org>, <ISO/IEC 27001:2022 | ISO/IEC 42001:2023 | both>
Version <n> | Date | Author | Approver: <named human> | Review cadence: <e.g. annual + on major change>
Source: Annex A of the licensed standard text (edition pinned) — entries quoted, never reconstructed
Per Annex A entry:
  <Annex A id — title as published>
    Applicable: yes | no
    Justification: <risk-treatment trace (risk id) | obligation | concrete exclusion rationale>
    Status: implemented (<mechanism from compliance-control-foundation>) | partial (<residue>) | planned (<owner, date>)
    Evidence hook: <→ compliance-evidence-collector>
Exclusions summary: <count + one-line rationale each>
Open items: <controls awaiting risk-treatment decisions>

Validation Checklist

• Every row comes from the licensed standard's Annex A table; zero entries reconstructed from memory or secondary sources.
• Every inclusion traces to a risk-treatment decision or named obligation; every exclusion has a concrete, verifiable justification.
• Implementation status maps to real mechanisms in the foundation catalog; no "implemented" without a named mechanism.
• Controlled-document metadata complete: version, author, named approver, review cadence.
• Updates delivered as diffs against the existing SoA with per-row rationale — no silent rewrite.
• 42001 rows treat Annex A entries as control objectives and controls per that standard's own structure, not as 27001 clones.

Compliance Precision Rules

• The SoA obligation and its tie to the risk-treatment process come from clause 6.1.3 — verify the exact clause wording against the licensed standard before quoting it.
• Never state ISO 27001 Annex A control counts (the widely cited 93 = 37/8/14/34 across A.5 Organizational / A.6 People / A.7 Physical / A.8 Technological is from secondary sources) without verifying against the Annex A table itself; never state ISO 42001 Annex A counts at all from memory — secondary sources conflict, so counts come only from the standard text in hand.
• ISO 27001/42001 are certifiable management-system standards; SOC 2 is an AICPA attestation with no SoA — never import SoA language into SOC 2 deliverables or vice versa.
• The SoA asserts applicability and status; it never asserts that the organization "is certified" or "will pass" — the accredited certification body decides.

Gotchas

• Include-everything SoAs are self-inflicted audit scope: every included control must be implemented and evidenced. Include by risk trace, not by fear of exclusions.
• Exclusion justifications age: "no remote work" from 2019 fails today's audit. The review cadence exists to catch these; stale justifications are findings.
• Copying another org's SoA imports their risk assessment; auditors ask for YOUR 6.1.3 trace and the mismatch shows immediately.
• For a combined 27001+42001 document, keep per-standard applicability distinct — an AI control objective excluded for 42001 reasons says nothing about a 27001 control, and vice versa.
• "Planned" rows without owner and date are decoration; auditors read them as unmanaged gaps.
• The SoA is not the risk assessment — it consumes treatment decisions. If the risk register doesn't exist yet, the SoA is blocked, not improvised.

Stop Conditions

• The licensed standard's Annex A table is not available — stop and say so; reconstructing Annex A entries from memory or vendor summaries produces a certifiably wrong document.
• No risk-treatment output exists to trace inclusions to — route to the owning ISO projection to run the 6.1 machinery first.
• Asked to rewrite or replace an operating SoA in place — produce a diff proposal for the named approver instead (human-approval-boundary).
• Asked to declare exclusions for controls whose risk relevance is genuinely undecided — surface the open decision to the risk owner; the SoA records decisions, it does not make them.
• Asked to write an SoA "for SOC 2" — explain SOC 2 has no SoA and hand scope questions to soc2-trust-criteria-mapper.

Supporting Files

• assets/soa-template.md — the SoA row template, controlled-document header, and justification patterns (inclusion by risk trace / by obligation; exclusion rationale tests).
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the compliance cluster (SoA vs ISMS/AIMS design vs catalog vs crosswalk) and against soc2-trust-criteria-mapper.