The Statement of Applicability (SoA) records for each Annex A control whether it applies, how you implement it, and why you exclude it if not. For auditors the SoA is the navigation map — policies without SoA linkage are hard to sample.
The SoA evolves with scope, risks, and product features. SaaS teams tie rows to IAM, CI/CD, logging, and vendor contracts — not vague ‘we have a policy’ statements.
What does this mean?
Annex A (2022: 93 controls in four themes) is selected through the SoA with implementation status and exclusion rationale. Stage 2 samples via SoA — ‘show me A.5.15 for your identity setup’.
Ideal row: control ID, applicable yes/no, implementation description, risk ID, owner, evidence location. N/A needs argument — e.g. physical datacenter control N/A on full cloud with SOC 2 host.
SoA and risk register are bidirectional. Management review discusses open SoA actions.
Version control matters — auditors compare to last surveillance and ask why controls changed without change records.
Who is this for?
Security and compliance maintain the SoA; engineering supplies implementation detail. Sales gets customer questions on encryption and access review — current SoA prevents ad-hoc answers that fail audit.
SMEs may start with a subset if rationale is documented. Enterprises debate one SoA vs per-BU — certification usually needs one consistent SoA within scope.
What steps or requirements apply?
After risk assessment, map threats to Annex A. Mark relevant controls; document implementation or planned action.
Write concrete implementation: which system, process, frequency — e.g. quarterly Okta access review with Jira ticket. Link evidence.
Review SoA on scope change or major release. Leadership approves SoA status in management review.
Align SoA template with certification body expectations at stage 1.
Common mistakes
‘Policy in place’ without operational proof. Copy-paste from another org without stack-specific detail.
Marking controls N/A without rationale. SoA disconnected from risk register. No owner per control.
Forgetting HR and physical controls get sampled too.
Practical action plan
Export Annex A 2022 as base columns. Work top-down: identity, logging, development, vendors, incidents. Link risk assessment and evidence.
At least one evidence example per control in the evidence map. Auditor role dry-run: five random controls in two hours.
Quarterly SoA review after pentest or internal audit — findings within 30 days in SoA or risk register.
Relationship with ISO 27001, NIS2, GDPR or ISMS
SoA operationalises ISMS for certification. Tag NIS2 overlaps on logging, incidents, chain.
GDPR privacy controls map to A.5 and A.8 — one SoA, no orphan privacy matrix. Scope drives relevance.
Control implementation references specific tool configs — Okta policy name, GitHub org setting — auditors verify in console.
Planned controls need target dates and budget flag — ‘planned’ without date reads as gap at stage 2.
SoA change log cross-referenced to change management — same discipline as production changes.
Customer-facing control summaries approved by legal — prevents sales ad-hoc promises contradicting SoA.
Cross-BU SoA: if one register, name control owners per BU in implementation column.
Annex A 2022 theme grouping in SoA helps engineering navigate — organisational vs technological sections.
Compensating controls documented when primary control N/A — e.g. enhanced monitoring when physical datacenter excluded.
SoA row links to policy version number — traceability when auditor opens wrong PDF revision.
Pen test finding IDs mapped to SoA rows closed — proves reactive improvement.
Shared responsibility controls split between you and cloud provider — avoids double-counting or gaps.
Development controls A.8.25–A.8.32 linked to branch protection, dependency scanning, and release tickets — not a standalone SDLC PDF.
Compensating controls documented when primary Annex A control is N/A — enhanced monitoring or contractual assurance replaces missing physical controls.
SoA status field honest: planned vs operating — leadership sees real progress; auditors distrust all-green pre-audit dashboards.
Cross-reference SoA row to policy section and ticket template — triple link survives steekproef when interviewee opens wrong document first.
Implementation column vocabulary standardised: tool name, config object, procedure link, review cadence. Inconsistent verbs (‘managed’, ‘handled’, ‘covered’) confuse auditors mapping samples across teams.
SoA review cadence tied to release train — major feature launches trigger row check for new data types, integrations, or regions. AI features often add subprocessors and logging requirements absent from last quarter SoA.
Internal audit samples SoA changes since last surveillance first — unexplained removals of controls are majors; additions without implementation proof are minors at best.
Customer security questionnaire library synced to SoA wording — sales and support pull pre-approved answers instead of inventing control descriptions per deal.
SoA signed or approved in management review when material changes occur — signature trail matters for surveillance delta review.
Export SoA to CSV for certification body pre-review — catches column gaps before stage 1 scheduling.
Use consistent Annex A 2022 control IDs — mixing 2013 and 2022 numbers confuses auditors and internal teams; keep a mapping table during migration.
Link SoA rows to configuration artefacts: Okta groups for A.5.15, branch protection for A.8.25, backup job IDs for A.8.13 — auditors trace from control to system.
Quarterly SoA review with product and engineering — new microservices, APIs or data exports can make previously N/A controls applicable.
Document compensating controls when partially implementing Annex A — e.g. physical access outsourced to SOC 2 cloud host plus your logical access controls.
Export SoA to CSV before stage 1 so the certification body can flag gaps before stage 2 samples begin.
Material SoA changes belong in management review minutes with approver and date — unsigned drafts fail stage 1 regularly.
Cloud shared responsibility: SoA states which controls the provider covers via SOC 2 and which you implement — grey areas without owners fail stage 2 samples.
SoA change log tied to release notes helps auditors connect product updates to control applicability shifts in the same quarter.
Control owners in SoA must be named individuals with deputies — generic ‘IT’ owner fails interviews when auditors ask for specific decisions.
Annex A 2022 theme grouping in SoA helps auditors sample across organisational, people, physical and technological controls systematically.
Implementation status field in SoA — planned vs implemented vs not applicable — clarifies roadmap for stage 1 without pretending unfinished work is done.
Justification text for excluded physical controls when fully cloud — reference provider attestation and your logical compensating controls.
Cross-reference SoA rows to policy document IDs — auditors jump between SoA and policy during clause 5 samples.
Align SoA control descriptions with customer security questionnaire answers — contradictions between SoA and sales responses trigger enterprise distrust.
Review SoA after penetration test scope changes — new findings may require controls previously marked not applicable.
SoA review after each major cloud region launch — data residency controls may shift from not applicable to implemented within one quarter.
SoA appendix listing excluded legacy systems with decommission dates — prevents auditors sampling retired environments still listed in old exports.
SoA metadata: author, reviewer, approver and date on cover page — stage 1 documentation samples start here.