ISO 27001 Statement of Applicability: Free SoA Template for 2026

The ISO 27001 Statement of Applicability, often shortened to SoA, is the single document an external auditor will request first when your certification audit begins. It maps every Annex A control to your implementation status, links each control to a documented risk, and explains the reasoning behind any exclusions. Get the SoA wrong and the audit slows to a crawl. Get it right and the rest of the certification process flows from it.

This guide walks through the exact structure of an ISO 27001 statement of applicability, the 93 Annex A controls you must address under ISO/IEC 27001:2022, and a free template you can adapt to your organization. By the end you will have a defensible SoA that satisfies both internal auditors and external certification bodies.

What Is the ISO 27001 Statement of Applicability?

The ISO 27001 statement of applicability is a mandatory clause 6.1.3 d) document that describes which information security controls from Annex A of ISO/IEC 27001:2022 you have selected, which you have excluded, and the rationale for each decision. It is the bridge between your risk assessment and your operational control set.

A complete SoA includes four pieces of information for each Annex A control:

1. The control reference and name (for example, A.5.1 Policies for information security).
2. Whether the control is included or excluded from your scope.
3. The justification for the inclusion or exclusion, tied to a specific risk or legal requirement.
4. The current implementation status (planned, partially implemented, or fully implemented) and a reference to the supporting evidence.

The 2022 revision consolidated the original 114 controls down to 93 and reorganized them into four themes: organizational (37), people (8), physical (14), and technological (34). Any SoA still using the 2013 control structure is out of date and will be flagged at audit.

Why the Statement of Applicability Matters

Auditors use the SoA as their primary roadmap. They sample controls from it, request evidence, and verify that what you claim to have implemented actually exists. The SoA is also the document executives sign to formally accept residual risk. If a control is excluded and a related incident occurs later, the SoA is the paper trail that shows whether the exclusion was reasonable.

Three practical reasons the SoA carries weight beyond the certification audit:

• Legal and contractual proof. Customers performing vendor due diligence often request the SoA. It demonstrates that information security controls have been deliberately selected, not improvised.
• Internal accountability. Each row of the SoA names a control owner, which forces real ownership of every safeguard.
• Continuous improvement. Comparing this year's SoA against last year's reveals which controls were added, retired, or changed in scope.

A poorly maintained SoA is the most common cause of a major nonconformity at the surveillance audit. Treat it as a living document, not a one-time deliverable.

Required Inputs Before You Start

You cannot write the SoA in a vacuum. ISO 27001 requires three artifacts to exist first:

1. Defined ISMS scope. Clause 4.3 requires you to formally state the boundaries of your information security management system. The SoA reflects only the assets, processes, and locations inside that scope.
2. Risk assessment. Clause 6.1.2 requires a documented risk assessment that identifies threats, vulnerabilities, and impact levels for each information asset.
3. Risk treatment plan. Clause 6.1.3 requires you to choose a treatment for each risk: modify, retain, avoid, or share. The SoA captures the modify decisions by mapping them to controls.

If any of these three is incomplete, pause SoA work and finish them first. Building a statement of applicability on weak foundations produces a document that will fall apart at the first auditor question.

The 93 Annex A Controls (2022 Revision)

ISO/IEC 27001:2022 reorganized Annex A into four themes. Your SoA must include a row for every control in all four themes, even if the decision is to exclude it.

Theme A.5: Organizational Controls (37 controls)

These cover policies, roles, supplier relationships, and incident handling. Examples include A.5.1 Policies for information security, A.5.7 Threat intelligence (new in 2022), A.5.23 Information security for use of cloud services (new in 2022), and A.5.30 ICT readiness for business continuity (new in 2022).

Theme A.6: People Controls (8 controls)

These address the human element: screening, terms of employment, awareness training, disciplinary processes, and remote working. Two notable controls are A.6.7 Remote working and A.6.8 Information security event reporting.

Theme A.7: Physical Controls (14 controls)

These cover physical perimeters, secure areas, equipment maintenance, secure disposal, and clear desk policies. A.7.4 Physical security monitoring (new in 2022) requires continuous monitoring of physical access events.

Theme A.8: Technological Controls (34 controls)

The largest theme covers user access, cryptography, system hardening, malware protection, logging, network security, application security, and secure development. New 2022 controls include A.8.9 Configuration management, A.8.10 Information deletion, A.8.11 Data masking, A.8.12 Data leakage prevention, and A.8.28 Secure coding.

You can find the full control list in the ISO 27002:2022 standard, which provides implementation guidance for each Annex A control. ISO 27002 is not certifiable on its own, but it is the companion document every auditor expects you to reference.

Statement of Applicability Template Structure

Below is the column layout used by the most efficient SoA implementations. The same structure works in Excel, Google Sheets, or any GRC platform.

A simple text-based justification is rarely enough. Auditors look for the link to a risk ID. If your risk register identifies R-014 as the threat of unauthorized access to source code, the justification for A.5.1 should reference R-014 explicitly. This traceability between risk register, treatment plan, and SoA is what makes the document defensible.

How to Write Justifications That Pass Audit

The justification column is where most SoA fail audit. Vague language like "industry best practice" or "to protect the business" tells the auditor nothing. A strong justification has three parts.

1. Reference the source of the requirement. This can be a risk ID from your risk register, a clause number from ISO 27001, a contractual obligation, or a law (such as GDPR Article 32 or HIPAA 164.308).

2. State the threat or impact in business terms. "Unauthorized disclosure of customer payment information could trigger PCI DSS penalties of up to $100,000 per month and breach our merchant agreement with Stripe."

3. Confirm the treatment decision. "Control A.8.24 Use of cryptography is selected to mitigate this risk by enforcing TLS 1.3 in transit and AES-256 at rest."

Justifications for excluded controls require the same rigor. An exclusion of A.7.6 Working in secure areas might read: "Excluded. The organization operates as a fully remote SaaS company with no physical offices, server rooms, or designated secure areas. No assets within ISMS scope reside in physical environments owned by the organization. The risk is transferred to AWS through the shared responsibility model and addressed under A.5.23 Information security for use of cloud services."

Common Mistakes That Trigger Nonconformities

External auditors see the same SoA mistakes year after year. The four most common ones produce major or minor nonconformities at certification.

1. Boilerplate justifications. Every row reads "implemented to meet ISO requirements." There is no link to a risk, no business context, and no evidence reference.
2. Outdated control numbering. The SoA still uses the 2013 control structure (114 controls in 14 categories) instead of the 2022 structure (93 controls in 4 themes).
3. Missing exclusions. The SoA only lists included controls. Auditors require you to address every control in Annex A, even if to mark it as not applicable with justification.
4. No version control. The SoA carries no version number, no approval signature, and no review date. Auditors cannot verify it is the current document.

How Often to Review the Statement of Applicability

ISO 27001 clause 9.3 requires management review of the ISMS at planned intervals, and the SoA is one of the inputs. In practice, three review triggers should drive SoA updates:

• Annual cycle. A full review of every row at least once per 12-month period, ideally aligned with the surveillance audit window.
• Significant change. Any acquisition, major architecture shift, new product launch, or change in regulatory environment requires an SoA review within 30 days.
• After security incidents. A confirmed incident often reveals a gap between claimed and actual control effectiveness. Update the relevant SoA rows during the incident post-mortem.

Track every change in a versioned change log, with date, control affected, change made, and approver. Auditors will sample the change log to verify clause 7.5.3 documented information control.

Tools That Generate or Maintain the SoA

You can keep the SoA in a spreadsheet, but for organizations with more than a handful of controls under active monitoring, a GRC platform reduces the manual work. The most common options used by SaaS companies pursuing ISO 27001 are:

• Vanta and Drata. Both ship with pre-built ISO 27001:2022 frameworks and produce an SoA report that maps directly to your evidence collection. Useful for fast-growing organizations that want continuous monitoring rather than annual snapshots.
• Sprinto. Targets startups with smaller compliance budgets. The SoA module is lighter than Vanta or Drata but covers the essentials.
• OneTrust and ServiceNow GRC. Enterprise-grade options that integrate with broader risk and compliance programs.
• Spreadsheet-based. Free templates from the British Standards Institution (BSI) and certification bodies are sufficient for organizations with under 30 employees and a single ISMS scope.

The right choice depends on the maturity of your compliance program. Spreadsheet works at first. As soon as you have more than 10 control owners or are pursuing multiple frameworks (ISO 27001 plus SOC 2, for example), the manual maintenance burden of a spreadsheet exceeds the cost of automation.

Statement of Applicability and the Certification Audit

During the stage 1 audit, the certification body reviews your SoA against your risk assessment, treatment plan, and ISMS scope. Stage 2 audits then sample controls from the SoA and verify implementation. Three things make the difference between a smooth audit and a series of nonconformities:

• Cross-references work both ways. Every risk in the register must point to one or more controls in the SoA. Every applicable control in the SoA must point back to at least one risk.
• Evidence is current. If the SoA references POL-001 v3.2 ratified November 2025, the auditor will request POL-001 v3.2 specifically. A v2.0 in the document store is a finding.
• Owners answer questions. Auditors will interview the named control owner. If the row says "CISO" but the CISO cannot describe how A.8.16 Monitoring activities is operated, the audit will note the gap.

For a deeper look at what to expect during stage 1 and stage 2 audits, see our guide on the ISO 27001 internal audit checklist and the ISO 27001 certification cost breakdown.

Frequently Asked Questions

Is the ISO 27001 Statement of Applicability mandatory?

Yes. Clause 6.1.3 d) of ISO/IEC 27001:2022 explicitly requires a documented ISO 27001 Statement of Applicability. There is no path to certification without one.

How long should an ISO 27001 Statement of Applicability be?

The 2022 revision has 93 controls, so the ISO 27001 statement of applicability must address 93 rows minimum. With justifications, evidence references, and a change log, most SoA documents run between 30 and 60 pages when exported to PDF.

Can I exclude controls from the ISO 27001 Statement of Applicability?

Yes, but every exclusion in the ISO 27001 statement of applicability requires a written justification. The most common exclusions are A.7 Physical controls for fully remote organizations, but even those should reference how the equivalent risk is handled (typically through cloud provider responsibility).

What is the difference between the SoA and the risk treatment plan?

The risk treatment plan describes which risks you have decided to modify, retain, avoid, or share. The ISO 27001 statement of applicability documents the specific Annex A controls you have selected to modify those risks. The two documents are linked: every modify decision in the treatment plan should map to one or more controls in the SoA.

How does the 2022 revision change the ISO 27001 Statement of Applicability?

ISO/IEC 27001:2022 reduced the control count from 114 to 93, reorganized them from 14 categories into 4 themes, and added 11 new controls covering threat intelligence, cloud services, data masking, monitoring activities, secure coding, and configuration management. Any ISO 27001 statement of applicability built from the 2013 standard must be remapped to the 2022 structure before the next audit.

Who signs off on the Statement of Applicability?

Top management. ISO 27001 clause 5.1 requires top management to demonstrate leadership and commitment to the ISMS, and the ISO 27001 statement of applicability is one of the artifacts they must formally approve. The signature line typically includes the role (CEO, CISO, or equivalent) and the date.

For supporting context, the official ISO 27001 standard page lists the current revision and certification bodies.

Final Word on the Statement of Applicability

A defensible Statement of Applicability has three properties: every Annex A control is addressed, every justification ties to a specific risk or requirement, and every claim has supporting evidence. Build the document with that mindset and the certification audit becomes a verification exercise rather than a discovery exercise. Treat the SoA as the artifact your future self will be grateful you maintained, and the rest of your ISMS will follow its discipline.