ISO 27001 Statement of Applicability (SoA): What It Is and How to Write One
The Statement of Applicability is the single most scrutinised document in your entire certification audit and getting it wrong is one of the most common reasons Australian organisations stall at or before their Stage 2 audit. It outlines which controls from Annex A apply to the information security management system (ISMS), along with the justification for their inclusion or exclusion.
If you are working through ISO 27001 for the first time, or trying to tighten up a document that was put together in a hurry, this guide covers what the statement of applicability ISO 27001 requires, what it must contain and how to write one that holds up under scrutiny.
What Is the ISO 27001 Statement of Applicability?
The Statement of Applicability, referred to throughout the standard and by practitioners as the SoA, is a mandatory documented requirement under Clause 6.1.3 of ISO/IEC 27001:2022. It lists every Annex A control and formally declares whether your organisation has applied it, why it has been included, its current implementation status, and if excluded, why it doesn’t apply to you.
Think of it as the bridge between your risk assessment and your actual security controls. Your risk assessment identifies what could go wrong. Your risk treatment plan sets out how you intend to address those risks. The SoA maps those decisions to specific Annex A controls and provides the documented justification for each one.
Without a complete, accurately documented SoA, ISO 27001 certification is not achievable.
Is the Statement of Applicability Mandatory for ISO 27001?
Yes, without exception. ISO/IEC 27001:2022 Clause 6.1.3 explicitly requires you to produce an SoA. It is one of a small number of specific documented artefacts named in the standard by name. An auditor arriving at your Stage 1 audit will typically ask to see this document before anything else because it sets the context for everything that follows.
The SoA is not something you can approximate or substitute with another document. If any of the four required elements are missing, that is a nonconformity your certification body will flag.
What Changed in ISO 27001:2022
If your SoA was built against the 2013 version of the standard, it needs updating. ISO 27001:2022 restructured Annex A significantly. The original 114 controls across 14 domains were consolidated into 93 controls across four themes: Organisational (37 controls), People (8), Physical (14), and Technological (34).
Eleven new controls were added to reflect how organisations now operate, covering areas such as threat intelligence, cloud services security, data masking, configuration management, and ICT readiness for business continuity.
The transition deadline from the 2013 standard passed in October 2025. If your certification still references the old control set, your next surveillance or recertification audit will raise it. Updating the SoA to the 2022 control structure is non-negotiable.
The Four Mandatory Elements Your SoA Must Include
Clause 6.1.3 specifies exactly what the SoA must contain. Each of the following is a requirement, not a suggestion.
1. The list of all Annex A controls with applicability status
All 93 controls must appear, each marked as applicable or not applicable.
2. Justification for inclusion
For every applicable control, you need to document why it has been included. This could reference a specific risk from your risk assessment, a legal or regulatory obligation, a contractual requirement, or an operational necessity.
3. Implementation status
For each applicable control, you must state whether it is implemented, partially implemented, or not yet implemented. Auditors do not expect everything to be fully operational at Stage 1, but they expect the status to be accurate.
4. Justification for exclusion
Any control marked not applicable requires a documented rationale. A straightforward example: a software development security control excluded because the organisation does not develop software. What is not acceptable is excluding a control because it is inconvenient or resource-intensive.
What You Need Before You Can Write Your SoA
The SoA is an output of your risk process, not a starting point. Writing it before you have completed your risk assessment is one of the most common mistakes we see and it produces an SoA that auditors can dismantle quickly.
Before opening a spreadsheet, you need a completed risk assessment that identifies your information security risks, a risk treatment plan that documents how you have decided to address each one, and a defined ISMS scope that sets out which assets, systems, people and locations are covered. You also need a clear picture of your legal and regulatory obligations. In Australia, this includes the Privacy Act 1988, and for financial services organisations, APRA CPS 234, both of which can drive the inclusion of specific Annex A controls regardless of internal risk decisions.
How to Write Your ISO 27001 Statement of Applicability
1. Start with your risk treatment decisions
The most common mistake when writing an SoA is opening the Annex A control list and working through it in isolation, ticking yes or no based on a surface-level read of each control. The correct approach is the reverse: start from the risks you have identified and the treatment decisions you have made, then identify which Annex A controls support those decisions.
Once you have your risk-driven selections mapped, layer in any controls required by law, regulation, or contract. For Australian organisations pursuing Defence Industry Security Program (DISP) membership, this step carries extra weight. DISP membership requirements align closely with several ISO 27001 Annex A controls, particularly around access control, asset management, personnel security, and incident response. If your organisation is working towards DISP membership alongside ISO 27001, those control justifications should reference both frameworks explicitly.
You can read more about how Siege Cyber supports DISP membership at siegecyber.com.au/services/defence-industry-security-program-disp.
2. Work through all Annex A controls systematically
For each control, document the following: applicable or not applicable, justification for inclusion (if applicable), current implementation status, justification for exclusion (if not applicable), and a reference to the supporting policy, procedure, or evidence.
A spreadsheet remains the most practical format for this. Columns typically include Control ID, Control Name, Applicability (Yes/No), Justification for Inclusion, Justification for Exclusion, Implementation Status, Control Owner, Evidence Reference, and Date Last Reviewed.
3. Write justifications that are specific
Vague justifications are an audit red flag. Phrases like “best practice” or “industry standard” are not sufficient on their own. A defensible justification connects the control directly to a named risk, a specific obligation, or a defined operational requirement.
A poor justification reads: Access control is industry best practice.
A better one reads: Included to address Risk R-07 (unauthorised access to client data). Required under Privacy Act 1988 obligations and client contractual terms.
Auditors want to see that you understand your own risk environment, not that you have populated a template.
If You Are Not Sure Where to Start
If the SoA feels overwhelming, a gap analysis is a practical first step. It maps your current controls against the full Annex A control set and gives you a clear picture of what needs to be in place before you can write a defensible SoA. Siege Cyber offers gap analyses as a standalone service for organisations at any stage of their ISO 27001 journey. You can view our compliance service options at siegecyber.com.au/#compliance-pricing.
Common Mistakes That Create Audit Problems
-
Writing the SoA before completing the risk assessment
-
Marking all controls as fully implemented when some are still in progress
-
Using vague or generic justifications for inclusions and exclusions
-
Failing to update the SoA when your business, technology, or risk environment changes
-
Not referencing legal and contractual obligations as drivers for control inclusion alongside risk
The SoA is a living document. As your organisation adds new systems, changes cloud providers, engages new suppliers, or changes the scope of its operations, the SoA needs to reflect that. Treating it as a one-time exercise rather than an ongoing management document is a pattern that consistently causes problems at surveillance audits.
Using Compliance Automation Platforms
If your organisation is using a compliance automation platform such as Vanta or Drata, the platform will help build and maintain your SoA by connecting control assessments to evidence automatically. This streamlines the process considerably, particularly when tracking implementation status across a large control set.
The platform does not, however, perform your risk assessment, write your justifications, or make control selection decisions on your behalf. That still requires someone who understands your business, your risks, and the standard. Siege Cyber is an official partner of both Vanta and Drata, which means we work regularly with organisations that have already purchased one of these platforms but need experienced guidance to complete the process properly and achieve certification.
SoA ISO 27001 Template: What the Format Should Look Like
The standard does not prescribe a specific format for the SoA. Most organisations use a spreadsheet with, at minimum, the following columns: Control ID, Control Name, Applicable (Yes/No), Justification for Inclusion, Justification for Exclusion, Implementation Status, Control Owner, Evidence Reference, and Date Last Reviewed.
The right level of detail scales with your organisation’s size and complexity. A 10-person professional services firm will have a different SoA to a 300-person financial services business and both can be valid, provided they satisfy the four mandatory elements under Clause 6.1.3. Siege Cyber’s ISO 27001 compliance services include hands-on support with your Statement of Applicability, from control selection and justification through to audit-ready documentation.
Get Your SoA Right the First Time
A poorly constructed SoA creates problems that flow through the entire certification process. Inconsistencies between the SoA and your policies, gaps in risk treatment coverage, and exclusions that cannot be defended under questioning. These are all things that slow down certification and cost time and money to fix.
Siege Cyber has helped Australian businesses across a range of industries build defensible, audit-ready information security management systems, including the SoA. Whether you are starting from scratch, transitioning from ISO 27001:2013, or preparing for an upcoming certification audit, we can work through the process with you.
Visit siegecyber.com.au to learn more about our ISO 27001 services, or contact us directly at [email protected] to discuss where your organisation is at.