ISO 27001 Statement of Applicability Requirements and Common Mistakes

The Statement of Applicability is the first document a certification body auditor asks for, and it's also the document most organizations get wrong. That's not a coincidence. The SOA sits at the exact point where risk assessment meets control implementation, and any weakness in the logic connecting the two is visible there before it is visible anywhere else.

The timing matters. ISO 27001 certificates nearly doubled worldwide between 2023 and 2024, climbing from 48,671 to 96,709. Large enterprises and government agencies are increasingly treating certification as a condition of doing business with vendors, using it as a signal of security maturity before a contract is even discussed. Organizations across sectors are fielding the same request from enterprise buyers, insurers, and regulators: show us the certificate. Behind that certificate sits the SOA, the document that determines, in an afternoon, whether an ISMS is even ready to be assessed.

What the SOA is and where it sits in the ISMS

The SOA is a formal requirement under Clause 6.1.3 of ISO/IEC 27001:2022, specifically sub-clause (d), which sits inside the risk treatment process. It's a formal requirement under Clause 6.1.3 of ISO/IEC 27001:2022, specifically sub-clause (d), which sits inside the risk treatment process. That placement tells you what the document is for. It exists to bridge the risk assessment to whatever controls the organization has actually put in place, giving auditors and internal stakeholders a single reference point for how identified risks are being handled.

In practice, the SOA lists all 93 Annex A controls and states, for each one, whether it applies and where implementation stands. Technically, every control an organization applies, not just the Annex A set, belongs in the SOA. Almost nobody does this in practice, though, because Annex A represents the required minimum and most organizations stop there. That's a defensible shortcut, but only if the 93 controls are handled with real rigor rather than treated as a checkbox exercise.

How the 2022 revision changed Annex A for every SOA

The 2013 version of Annex A had 114 controls spread across 14 domains, a structure since consolidated. That structure is gone. The 2022 revision consolidated everything into 93 controls organized under four themes: Organizational (A.5, 37 controls), People (A.6, 8 controls), Physical (A.7, 14 controls), and Technological (A.8, 34 controls).

Eleven of those 93 controls are entirely new, added to address priorities that simply didn't exist, or didn't exist at scale, when the 2013 standard was written: physical security monitoring, information deletion, ICT readiness for business continuity, data leakage prevention, and secure coding among them. The 2022 revision consolidated and reorganized the prior controls into the new structure rather than simply removing them. A SOA that drops a control because it seems to have "disappeared" from the 2013 list is simply wrong. Auditors will catch this quickly, because the relationship between the two versions is traceable and any competent reviewer can identify where each 2013 control was addressed.

What a complete, audit-ready SOA must contain

Clause 6.1.3 sets a bare minimum, and that minimum needs to be stated precisely. Every one of the 93 Annex A controls needs a line item, even ones the organization thinks are irrelevant. Each control needs a stated position, applicable or not applicable, with no ambiguity. Applicable controls need a justification tied to specific risks or business context, distinct from a restatement of the control's title. Excluded controls need a documented reason for exclusion, never a blank cell. And each applicable control needs an implementation status.

A SOA built to survive scrutiny, rather than merely satisfy the letter of the clause, must at minimum name a control owner, either a role or a specific person, for each line item. A SOA built to survive scrutiny, rather than merely satisfy the letter of the clause, usually goes further. It names a control owner, either a role or a specific person, for each line item. It links controls explicitly to the risks they treat. It flags controls that are planned but not yet live, with expected implementation dates attached. It points to supporting evidence, whether that's a policy document, a procedure, or a system configuration, that proves the control is actually operating rather than existing only on paper. And it carries implementation and last-review dates so an auditor can see the document has a pulse.

Justifications are where a surprising number of otherwise solid SOAs fall apart. "Best practice" is not a justification; it's a placeholder for one. Auditors expect language that ties back to a contract clause, a legal obligation, a specific threat, or an actual risk the assessment identified. Generic language reads, correctly, as evidence that nobody actually thought through why the control exists.

Management sign-off closes the loop. Senior leadership needs to formally approve the SOA, and the cleanest way to demonstrate that approval is by tying it to Management Review Meeting minutes. That linkage turns the SOA into a decision the organization formally made, rather than a document produced in isolation.

How auditors use the SOA across Stage 1 and Stage 2

Stage 1 is a documentation review. The certification body auditor works through the ISMS paperwork, the SOA, and the risk treatment plan to confirm the management system is actually designed the way the standard requires before anyone starts testing controls in the field. It is a focused review that gives the document relatively little time to make its case, which is why preparation matters.

The SOA usually comes up first. Its quality, whether the justifications are specific, whether all 93 controls are present, whether the risk linkage is visible, signals the maturity of the whole ISMS before the auditor has looked at a single control in operation.

Stage 2 is the operational audit, and this is where a common misconception needs correcting: auditors do not expect all 93 controls to be fully implemented. Nobody expects perfection here. What they expect is that every exclusion is justified and every implemented control actually works the way the SOA claims it does. Auditors tend to probe two things specifically: why particular controls were left out, and how the controls that are in place map back to the risk assessment. If the team has to scramble to answer either question on the spot, that's already a bad sign.

The most common SOA mistakes that fail audits or delay certification

Four mistakes account for most of the non-conformities tied to the SOA, and they tend to cluster in predictable ways.

Omitting controls from the listing entirely is the most basic failure, and it's an immediate non-conformity. This is disproportionately common among organizations transitioning from the 2013 standard, where teams assume that a control merged into a new 2022 control number no longer needs its own entry. This is an immediate non-conformity, and it shows up disproportionately among organizations transitioning from the 2013 standard, where teams assume that a control merged into a new 2022 control number no longer needs its own entry.

Using the wrong control set is closely related but distinct. A SOA still built around the 114-control 2013 structure, or one missing the 11 new 2022 controls, is non-conforming as of the 2022 transition deadline in October 2025. This is especially common among organizations that built their SOA years ago, achieved certification, and never revisited the document as the standard evolved underneath it.

Weak or generic justifications are the third failure mode, and probably the most pervasive. Many SOAs simply don't explain why a control is included or excluded in any way that connects back to the risk assessment. "Because the standard says so" is not a justification an auditor will accept, and neither is an unadorned reference to best practice. This pattern signals poor risk governance, not just poor documentation.

Selecting controls without risk linkage is the fourth issue, and it's arguably the deepest because it's usually a symptom of something upstream. Controls get selected because they appear in Annex A, full stop, with no attempt to tie them to a risk the organization actually identified. A weak risk assessment produces a SOA that cannot be defended, because auditors trace the logic backward from control to risk, and if that thread breaks, the gap is immediately visible.

AI tool use and the SOA: controls that now need explicit coverage

ISO/IEC 27001:2022 does not address AI tools specifically, and its controls require organizations to do the mapping work themselves. The standard's controls still govern AI tools; organizations have to do the mapping themselves, and auditors can be expected to probe whether this mapping has happened. An organization with no SOA coverage for the AI tools it actually uses has created an undocumented risk surface, and a certification audit is designed to surface exactly that gap.

Several existing controls carry this weight directly. Supplier relationships fall under Control 5.19, which should cover the vendor assessment process for any AI tool in use. Control 5.20 covers supplier agreements, meaning data processing agreements and contractual commitments specific to those tools. Control 5.22 covers ongoing monitoring and review of supplier services, which applies to AI vendors as a category of supplier. Control 5.23 covers cloud services, and AI tools are, functionally, cloud services, so the policy and assessment obligations that already apply to cloud vendors apply here too.

On the technical side, control 8.10 (information deletion) needs to state what the retention and deletion policy is for data submitted to AI tools. Control 8.11 (data masking) should cover whether sensitive data gets masked or redacted before it's submitted to a model. Control 8.12 (data leakage prevention) should extend existing DLP policy to cover AI endpoints specifically, in addition to traditional network egress points.

For organizations building or selling AI products rather than merely using them, the SOA becomes the place to show that risks like model integrity, data bias, and third-party cloud security were addressed on purpose, not overlooked because the standard doesn't name them.

How to build and maintain the SOA as a working governance document

Getting the construction sequence wrong is a quiet way to fail an audit months later. The risk assessment comes first, always. The SOA is an output of risk treatment decisions, not a starting point, and any control selected without a risk driving it behind the scenes will be impossible to justify convincingly when an auditor asks why it's there.

From there, ISO 27002:2022 is worth acquiring directly, since Annex A only lists the controls by name while ISO 27002 supplies the implementation detail needed to write justifications that hold up under scrutiny. Build a single ledger covering all 93 controls, capturing at minimum the applicability decision, justification, implementation status, owner, and last-review date for each. Map each applicable control to the specific risk or risks it treats, since that's the exact thread an auditor will pull. Document every exclusion with a specific reason, never a blank field and never a generic line. Attach supporting evidence for each implemented control: the actual policy, procedure, or configuration. Then get formal sign-off, tied to Management Review Meeting minutes.

Ownership shouldn't sit entirely with IT. HR, legal, procurement, and operations all own controls in a properly built SOA, because plenty of Annex A controls, screening, contracts, supplier terms, have nothing to do with infrastructure and everything to do with how the rest of the business operates.

Currency is the last piece, and it's the one organizations neglect once certification is achieved. A minimum annual review cycle, with a timestamp recorded on the document itself, is the baseline. Beyond that, an ad-hoc review should trigger whenever something material shifts, such as a significant organizational change, a newly identified risk, the adoption of a new AI tool, or a change in a supplier relationship. Ongoing audits will expose whether that review cycle is real or aspirational, and a SOA that hasn't moved since the last certification audit tends to answer that question on its own.