%20(35)%20(1).png)
Key takeaways:
- The Statement of Applicability (SoA) is a mandatory document under ISO 27001 clause 6.1.3(d). It lists all 93 Annex A controls and documents, identifies which apply to your organization, which don’t, and explains why.
- The SoA is one of the first documents your Stage 1 auditor reviews. Gaps here signal gaps everywhere else in your ISMS.
- Every control entry requires four fields: applicability decision, justification, implementation status, and evidence reference. Missing any one of them is a finding.
- The problem isn’t in excluding a control, but failing to justify the exclusion. Auditors expect specific, risk-based reasoning.
- The SoA must stay aligned with your Risk Treatment Plan. If a risk requires a control but the SoA marks it excluded, you have a contradiction that will surface in Stage 2.
When a Stage 1 auditor sits down with an ISO 27001 documentation package, the Statement of Applicability is usually the first document they open.
The SoA tells them at a glance whether you understand what your ISMS is supposed to cover and whether you’ve made deliberate decisions about it.
Most startups treat the SoA as a table to fill in before the audit. The problems appear when the auditor finds controls marked as “not applicable” without explanation, or controls marked as “implemented” without the evidence.
This post covers what the SoA is, what every entry must contain, how to write exclusion justifications that hold up, and the mistakes that turn routine audits into findings lists.
What Is the Statement of Applicability
The Statement of Applicability is a document required by ISO 27001:2022 clause 6.1.3(d). It lists all 93 controls in Annex A of the standard and records, for each one, whether your organization has decided to apply it, why, what its current implementation status is, and where auditors can find the evidence.
It’s mandatory. ISO 27001 clause 6.1.3 is explicit: the organization “shall produce a Statement of Applicability.” Certification bodies won’t pass a Stage 1 audit without it.
The SoA doesn’t exist in isolation. It has to be consistent with your Risk Treatment Plan, which documents how you’ve decided to address each identified risk. If your risk assessment says a particular risk needs to be mitigated, and the RTP says the mitigation is Annex A control 8.8 (management of technical vulnerabilities), then the SoA must mark that control as applicable and implemented.
A contradiction between the two documents is a common Stage 2 finding. For a full picture of what the audit process looks like, check ISO 27001 Checklist: Practical Roadmap for SaaS & Startups.
The Four Fields Every SoA Entry Must Have
The structure of each SoA is also important. Auditors look for four specific pieces of information per control. If any one is missing, the entry is considered incomplete.
Some organizations add optional columns, like control owner, review date, or related risks. These aren’t required, but they make the SoA more useful as an operational document.
How to Structure the SoA
The standard doesn’t prescribe a specific format, but the most practical and widely accepted structure is a table organized by the four Annex A control themes: Organizational (controls 5.1–5.37), People (6.1–6.8), Physical (7.1–7.14), and Technological (8.1–8.34). This matches how auditors navigate the document and how most compliance platforms generate their SoA output.
Every SoA should include a document header with at minimum: document title, version number, date of last review, document owner, and approval signature or record. ISO 27001 auditors apply document control requirements to the SoA itself. An undated, unversioned SoA suggests the rest of the ISMS is managed the same way.
Compliance platforms like Vanta, Drata, and Secureframe generate a pre-populated SoA based on your environment. This is useful for getting the structure in place and mapping controls to evidence automatically.
What these platforms don’t generate is the justification text for each control, particularly for exclusions. That content has to reflect your specific risk assessment results and organizational context.
How to Write a Control Exclusion That Holds Up Under Audit
Excluding controls from the SoA is expected. A cloud-native startup with no physical offices doesn’t need most physical security controls.
Marking everything as applicable regardless of your actual environment is its own kind of problem: it creates implementation obligations you can’t meet and evidence requirements you can’t satisfy.
The problem auditors find is when control exclusions aren’t justified. Here are two examples:
Exclusion that creates a finding
Exclusion that passes the audit
The organization operates as a fully remote, cloud-native company with no physical offices or on-premises infrastructure. All systems are hosted on AWS (eu-west-1). There are no physical perimeters to secure. This was confirmed in the risk assessment dated 2024-03-15, reference RA-2024-012, which found no risks requiring physical entry controls.
The strong exclusion does a few things the weak one doesn’t: it names the specific reason (remote, cloud-native, no offices), names the specific technology context (AWS), explains the logical consequence (no physical perimeters to secure), and references the risk assessment that confirmed this conclusion.
There’s a third category worth calling out: controls that are not applicable because you don’t use the relevant technology. If you’ve never used removable media in your environment, control 8.12 (data masking on removable media) can be excluded. But the justification needs to clearly affirm that and, ideally, reference a policy or configuration that enforces this.
The Most Common SoA Mistakes Auditors Find
- Generic exclusion justifications: This is one of the most common findings in Stage 1 audits, but also the easiest to fix. It just requires replacing the generic phrase with the specific reason.
- SoA out of sync with the Risk Treatment Plan: If the RTP identifies a risk and names a control as the treatment, then the SoA can’t mark the same control as not applicable. The contradiction creates a major nonconformity because it means your risk treatment decision and your control selection decision directly contradict each other.
- Implemented controls with no evidence reference: The Stage 2 auditor cannot verify implementation without knowing where to look. Every implemented control needs a specific pointer.
- Treating the SoA as a one-time document: When new systems come in scope, new vendors are onboarded, or technology changes, the SoA becomes inaccurate, and inaccuracies discovered by an auditor are findings.
- Using ISO 27002 descriptions without mapping to ISO 27001 requirements: ISO 27002 provides implementation guidance for the same 93 controls. Some organizations copy descriptions from 27002 into their SoA without verifying if the control numbering aligns with the 27001:2022 Annex A structure, which was updated in the 2022 revision.
Keeping the SoA Current After Certification
Certification doesn’t end your obligation to maintain the SoA. The standard requires that the ISMS documentation, including the SoA, be kept current as the organization and its risk environment evolve.
Triggers that should prompt a review:
- A new application or system brought into ISMS scope;
- A new vendor with access to in-scope data;
- A significant change to your cloud infrastructure or architecture;
- A security incident that reveals a previously unidentified risk;
- Or a change in regulatory requirements applicable to your organization.
Each of these can change which controls are relevant and how they’re implemented.
The surveillance audits in Year 1 and Year 2 of your certification cycle will check that the SoA remains accurate. If the document hasn’t been touched since the original certification, that’s a signal to the auditor that the ISMS isn’t being actively maintained. For a detailed breakdown of what those audits check, check ISO 27001 Surveillance Audit: What to Expect.
Build an SoA That Holds Up Under Audit
The Statement of Applicability is the document that tells your auditor whether you’ve made deliberate, risk-based decisions about your security program. Getting it right the first time saves weeks of rework before Stage 2.
SecureLeap builds the SoA alongside the full ISO 27001 implementation, so the documents are consistent from the start. Our vCISO engagement includes the documentation, the audit relationship, and the pentest coordination, all through a single partner.
Ready to build your SoA correctly the first time? Book a free 30-min call or send us an email.
FAQ: Frequently asked questions
What is a Statement of Applicability in ISO 27001?
The Statement of Applicability (SoA) is a mandatory document under ISO 27001 clause 6.1.3(d) that lists all 93 Annex A controls and records whether each one applies to your organization, the justification for that decision, the current implementation status, and a reference to the evidence that demonstrates implementation.
How many controls are in the ISO 27001 Annex A?
ISO 27001:2022 Annex A contains 93 controls organized across four themes: Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). This is a reduction from the 114 controls in ISO 27001:2013, which was reorganized and restructured in the 2022 revision.
Can you exclude controls from the ISO 27001 Statement of Applicability?
Yes, and it’s expected that some controls won’t apply to every organization. The requirement is that every exclusion be justified with specific, risk-based reasoning tied to your risk assessment results. Generic justifications are common causes of documentation findings in Stage 1 audits.
What’s the difference between the SoA and the Risk Treatment Plan?
The Risk Treatment Plan (RTP) documents how you’ve decided to address each identified risk: accept it, mitigate it, transfer it, or avoid it. For risks you’ve decided to mitigate, the RTP names which Annex A control provides that mitigation. The SoA then records whether that control is implemented and where the evidence is. The two documents must be consistent: if the RTP says a risk is mitigated by a specific control, the SoA must mark that control as applicable and implemented. Contradictions between the two are a major nonconformity.
Does the SoA need to be reviewed after certification?
Yes. The SoA is a living document that must be kept accurate as your organization and risk environment change. New systems in scope, new vendors with data access, infrastructure changes, and security incidents can all affect which controls are relevant and how they’re implemented. Surveillance audits in Year 1 and Year 2 of your certification cycle will check that the SoA remains current. A document that hasn’t been updated since the original certification signals to auditors that the ISMS isn’t being actively maintained.
%20(22)%20(1).avif)
%20(19).avif)
%20(11)%20(1).avif)