ISO 27001 Statement of Applicability Template With Example

What Is the Statement of Applicability in ISO 27001?

If you are working towards ISO 27001 certification, the Statement of Applicability (SoA) is one of the most important documents you will produce. It is also one of the most misunderstood. Many businesses treat it as a box-ticking exercise, copy a template from the internet, mark everything as “applicable” and wonder why their auditor raises a major nonconformance on day one of the Stage 2 audit.

The SoA is a mandatory document required by ISO 27001 Clause 6.1.3. It lists every control from Annex A of the standard, states whether each control applies to your organisation, provides a justification for that decision, and references where the control has been implemented. Done properly, it tells the story of your information security posture. Done poorly, it is just a spreadsheet with ticks in it.

This guide will walk you through exactly what the SoA needs to contain, give you a practical template structure you can use, and show you a real-world example of how a mid-sized Australian software company might complete it. Whether you are building your SoA from scratch or reviewing one that a consultant has handed you, this article will help you understand what good looks like.

Why the Statement of Applicability Matters So Much

The SoA sits at the heart of your Information Security Management System (ISMS). It is the bridge between your risk assessment and your actual security controls. Your auditor will use it to verify that you have thought carefully about which controls are relevant to your context, that you have not simply excluded controls to avoid the work, and that the controls you say are implemented are actually in place.

There are two common mistakes businesses make with the SoA. The first is including every single Annex A control regardless of whether it actually applies to their business. A five-person accounting firm does not run a physical data centre, so controls around physical access to server rooms may genuinely not apply. Marking everything as applicable without justification shows your auditor that you have not done a proper risk assessment.

The second mistake is excluding controls without a documented reason. If you exclude a control, you must be able to justify why. “It does not apply to us” is not a justification. A proper justification references your risk assessment, your business context, or a specific reason why the threat is not relevant.

Getting the SoA right also has commercial value. Many enterprise clients and government agencies will ask to see your SoA as part of their supplier security assessments. A well-structured SoA demonstrates maturity. A sloppy one raises red flags. If you want to understand more about what the full certification process involves, our article on the ISO 27001 certification process step by step covers the broader journey.

What ISO 27001 Actually Requires in the SoA

Clause 6.1.3(d) of ISO 27001 requires that the SoA contains the following for each control in Annex A:

• Whether the control is applicable or not applicable
• Justification for inclusion or exclusion
• Whether the control has been implemented
• A reference to where the control is documented or evidenced

The current version of ISO 27001 (the 2022 edition) restructured Annex A from 114 controls across 14 domains to 93 controls across four themes: Organisational, People, Physical, and Technological. If you are still working from the 2013 version, you will need to transition. ISO.org confirms that ISO/IEC 27001:2022 is the current active version and all new certifications must be issued against it.

The four control themes in the 2022 edition are:

• Organisational controls (Controls 5.1 to 5.37): Policies, roles, responsibilities, supplier relationships, incident management
• People controls (Controls 6.1 to 6.8): Screening, terms of employment, awareness, disciplinary process, remote working
• Physical controls (Controls 7.1 to 7.14): Physical security perimeters, clear desk, equipment maintenance, secure disposal
• Technological controls (Controls 8.1 to 8.34): Access control, malware protection, backup, logging, cryptography, vulnerability management

The SoA Template Structure

Below is the recommended column structure for your SoA. You can build this in Excel, Google Sheets, or a purpose-built GRC tool. The format does not matter as much as the content.

Column 1: Control Reference

List each Annex A control by its reference number. For example, 5.1, 5.2, 5.3 and so on through to 8.34. Do not skip any controls, even if you plan to exclude them. Every control must appear in the document.

Column 2: Control Name and Description

Include the name of the control as it appears in the standard. For example, Control 5.1 is “Policies for information security.” You do not need to reproduce the full control text, but enough description so that someone reading the SoA understands what is being assessed.

Column 3: Applicable or Not Applicable

Mark each control as either applicable or not applicable. Some organisations use a third option such as “partially applicable” but keep in mind that your auditor will want to see evidence that partially applicable controls are implemented to the extent that they are applicable. Keep it simple unless your context genuinely requires nuance.

Column 4: Justification

This is the column most businesses get wrong. For applicable controls, reference the risk assessment finding or business requirement that makes the control necessary. For example: “Risk assessment identified unauthorised access to customer data as a high risk. This control mitigates that risk.” For excluded controls, explain why the threat or scenario does not apply. For example: “Organisation does not operate physical media transfer processes. This control is not applicable.”

Column 5: Implementation Status

Indicate whether the control is fully implemented, partially implemented, or planned. At the time of your Stage 2 audit, all applicable controls should be at least partially implemented, with a clear timeline for full implementation if they are not complete. Having a large number of controls marked as “planned” at Stage 2 is a red flag for auditors.

Column 6: Evidence or Reference

Point to where the control is documented or evidenced. This might be a policy document, a procedure, a system configuration record, a training record, or a contract clause. For example: “Information Security Policy v2.1, Section 4” or “Azure Active Directory configuration, Access Control Procedure.” This column is what your auditor will use to pull evidence during the audit.

Optional Column: Control Owner

Many organisations add a control owner column, which assigns responsibility for each control to a specific role or person. This is not strictly required by the standard but it makes your SoA far more useful as an operational document and demonstrates clear accountability to your auditor.

Real-World SoA Example: Australian SaaS Company

To make this concrete, here is how a 30-person Australian SaaS company providing HR software to enterprise clients might complete selected rows of their SoA.

Example Row 1: Control 5.1 Policies for Information Security

• Applicable: Yes
• Justification: Risk assessment identified lack of documented security direction as a gap. Enterprise clients require evidence of formal security governance. Regulatory context includes the Australian Privacy Act 1988.
• Implementation Status: Fully implemented
• Evidence: Information Security Policy v3.0, approved by CEO, reviewed annually. Stored in document management system under ISMS folder.

Example Row 2: Control 7.4 Physical Security Monitoring

• Applicable: Partially applicable
• Justification: Organisation operates from a co-working space. Physical security monitoring of the building is managed by the building operator. Organisation has no control over CCTV or access logs. Control is applicable only to the extent of the organisation's own equipment and locked storage areas within the space.
• Implementation Status: Partially implemented
• Evidence: Physical Security Procedure v1.2, Section 3. Lease agreement with building operator confirming their security obligations.

Example Row 3: Control 8.12 Data Leakage Prevention

• Applicable: Yes
• Justification: Organisation processes sensitive HR data including payroll and personal information for enterprise clients. Risk of data exfiltration by insiders or via misconfigured cloud storage is rated high. DLP controls are required to meet both internal risk appetite and client contractual obligations.
• Implementation Status: Partially implemented
• Evidence: Microsoft Purview DLP policies configured. Full implementation planned by Q2 2026. DLP Implementation Project Plan v1.0.

Example Row 4: Control 7.9 Security of Assets Off-Premises

• Applicable: Yes
• Justification: All staff work remotely or in hybrid arrangements. Company laptops and mobile devices are regularly used outside the office. Risk of loss or theft of devices containing sensitive data is rated medium-high.
• Implementation Status: Fully implemented
• Evidence: Remote Working Policy v2.0. Mobile Device Management (MDM) configuration records. Device encryption confirmed via Intune compliance reports.

Example Row 5: Control 7.1 Physical Security Perimeters

• Applicable: Not applicable
• Justification: Organisation does not own or operate its own premises. All infrastructure is hosted in AWS Sydney region. No on-premises servers or data centre facilities exist. Physical perimeter security for cloud infrastructure is managed by AWS under their shared responsibility model.
• Implementation Status: N/A
• Evidence: AWS Shared Responsibility Model documentation. AWS SOC 2 Type II report referenced as compensating evidence.

Common SoA Mistakes That Cause Audit Failures

Having reviewed hundreds of SoAs over the years, the same problems come up repeatedly. Here are the ones that most commonly result in nonconformances.

Copying a Template Without Adapting It

A generic template from the internet will have generic justifications. Auditors can spot these immediately. If your justification for every control reads like it came from a textbook, your auditor will question whether you have actually done a risk assessment or just filled in a form. Your SoA needs to reflect your specific business, your specific risks, and your specific context.

Excluding Controls to Reduce Workload

Some businesses exclude controls not because they are genuinely not applicable, but because implementing them is hard. This is a significant risk. If an auditor identifies that a control is relevant to your business and you have excluded it without a credible justification, that is a nonconformance. In some cases it can result in certification being withheld.

Saying “Implemented” Without Evidence

Marking a control as fully implemented means nothing if you cannot produce evidence. Your SoA is only as good as the evidence column. If you cannot point to a document, a system record, a configuration, or a training log, the control is not implemented from an audit perspective. Our article on what documents ISO auditors check during an audit gives you a clear picture of what evidence is expected.

Not Keeping the SoA Updated

The SoA is a living document. When your business changes, when new risks emerge, or when you implement new controls, the SoA needs to be updated. An SoA that has not been reviewed in two years will not reflect your current state and will raise questions about the effectiveness of your management review process. This ties directly into how well you maintain your ISMS over time, which is something we cover in our guide on how to check if your ISO management system is actually working.

How the SoA Connects to Your Risk Assessment

Your SoA does not exist in isolation. It is directly linked to your risk assessment and risk treatment plan. The logical flow is: identify your information assets, assess the threats and vulnerabilities, determine the risks, select controls from Annex A to treat those risks, and then document those decisions in your SoA.

If your SoA includes a control but your risk assessment does not identify a corresponding risk, your auditor will ask why that control is there. Conversely, if your risk assessment identifies a significant risk but your SoA excludes the relevant control, your auditor will want a very good explanation. The two documents must be consistent with each other.

For businesses that are new to the risk assessment process, our ISO 27001 risk assessment guide for non-technical business owners breaks down the process in plain language without requiring a technical background.

SoA Tips for Small and Medium Businesses

If you are a small business, the SoA can feel overwhelming. Here are some practical tips to make the process manageable.

• Start with your risk assessment. Do not start with the SoA. Complete your risk assessment first, then use it to drive your SoA decisions. The SoA is an output of the risk assessment, not the starting point.
• Be honest about what you have not done yet. It is far better to mark a control as “planned” with a realistic implementation date than to mark it as “implemented” and be unable to produce evidence. Auditors respect honesty and a credible plan.
• Use plain language in your justifications. You do not need legal or technical language. Write your justifications as if you are explaining your business to someone who does not know it. Clear, specific, and relevant is what matters.
• Assign an owner to every applicable control. Even if your business is small, someone needs to be responsible for each control. This makes your SoA operational rather than just a compliance document.
• Review it before every audit. Before your annual surveillance audit or recertification audit, review the SoA and update it to reflect any changes in your business or your control environment.

Should You Use a Consultant to Build Your SoA?

This depends on your internal capability and how much time you have. A good ISO 27001 consultant will not just fill in the template for you. They will work through your risk assessment with you, help you understand which controls genuinely apply to your context, and make sure the justifications are credible and defensible. The SoA they produce should be specific to your business, not a generic document with your logo on it.

If you are considering engaging a consultant, make sure you understand what they are actually delivering. A consultant who hands you a completed SoA without involving you in the process is doing you a disservice. You need to understand your own SoA because your auditor will ask you questions about it, and “my consultant wrote it” is not an acceptable answer during an audit.

If you are looking for qualified ISO 27001 consultants who can guide you through the SoA and the broader ISMS implementation, CertBetter connects Australian businesses with verified consultants and accredited certification bodies. You submit one form and receive up to three competing quotes, so you can compare expertise and pricing before committing. The service is completely free for businesses seeking certification help.