The ISO 27001 Statement of Applicability documents the information security controls that apply to your business and is a key document in the information security management system (ISMS). It is one of the first documents and auditor will normally ask for. As a minimum it lists all of the ISO 27001 Annex A controls and records if they apply to your business or not. If not, it will record why not.
ISO 27001 SoA Scope Calculator & Exclusion Generator
A basic AI-Ready Interactive ISO 27001 Statement of Applicability Generator to kick start your ISO 27001:2022 Statement of Applicability
ISO 27001 SoA Scope Calculator & Exclusion Generator
Use this auditor-verified tool to instantly determine which of the 93 Annex A controls are mandatory for your organization and generate technical exclusion justifications for your Statement of Applicability.
1. Do you develop bespoke software or write proprietary code?
2. Do you have physical office locations or data centres?
3. Do you utilise third-party sub-processors or cloud SaaS vendors?
4. Do you employ remote or hybrid staff?
5. Do you handle physical storage media (USBs, Backup Tapes)?
Complete ISO 27001:2022 SoA Exclusion Rationale Generator
This tool provides auditor-verified exclusion justifications for **all 93 Annex A controls**. Select a control and your business model to generate your technical rationale.
Lead Auditor Tip: Exclusions are scrutinized under Clause 6.1.3(d). If you exclude a “Management” control (Theme 5), you must prove the risk is completely absorbed by a parent entity or third-party contract.
Download Professional SoA Matrix (XLS)Table of contents
- ISO 27001 SoA Scope Calculator & Exclusion Generator
- What is the ISO 27001 Statement of Applicability?
- ISO 27001:2013 vs 2022 SoA Comparison Table
- The 11 New ISO 27001:2022 Controls
- The ISO 27001 Compliance Roadmap: Where the SoA Fits
- ISO 27001 Annex A Control Owner Matrix
- Applicability to Small Businesses, Tech Startups, and AI Companies
- ISO 27001 Statement of Applicability Template
- How to Implement It
- How the ISO 27001 Toolkit Can Help
- Information Security Standards That Need It
- List of Relevant ISO 27001:2022 Controls
- ISO 27001 SoA Cross-Standard Mapping Table
- How do you decide what controls to include in a Statement of Applicability (SoA)?
- What if the Statement of Applicability (SoA) controls don’t apply?
- ISO 27001 Statement of Applicability Example
- ISO 27001 Statement of Applicability (SoA) vs Risk Treatment Plan (RTP) Technical Comparison
- The Auditor’s SoA Approval Checklist
- ISO 27001 SoA Redaction and Sharing Policy
- ISO 27001 SoA Version Control Template
- ISO 27001:2022 Control Attributes and #Tags Matrix
- ISO 27001 Statement of Applicability FAQ
What is the ISO 27001 Statement of Applicability?
A Statement of Applicability, or SoA, is basically a checklist for your company’s information security. When you want to get ISO 27001 certified, you have to show that you’re protecting your data. The SoA is where you list all the security controls you’ve chosen to use. You’ll also explain why you picked those and why you left others out. It’s your way of saying, “Here’s what we do to stay secure, and here’s why.”
| Compliance Aspect | Strategic Description & Purpose | Technical Application & Scope |
|---|---|---|
| Why You Need It | Vital for the ISO 27001 certification process; it documents security decisions, demonstrates technical compliance to auditors, and formalises risk management strategies. | Clause 6.1.3 Compliance & Audit Evidence |
| When You Need It | Created immediately following the risk assessment. It serves as the final technical bridge between identified risks and the selection of Annex A security controls. | Post-Risk Assessment Phase |
| Who Needs It | Any organisation seeking ISO 27001 certification, ranging from SMEs and tech startups to global corporations, to prove their commitment to information security. | Mandatory for all ISMS Scopes |
| Where You Need It | Maintained as a ‘living’ internal document within the ISMS. It is the primary reference point during external Stage 1 and Stage 2 certification audits. | Internal Governance Framework |
| How to Write It | Inventory all 93 controls from ISO 27001:2022, determine applicability, provide technical rationales for implementations or exclusions, and obtain senior management sign-off. | Annex A Control Scoping & Justification |
ISO 27001:2013 vs 2022 SoA Comparison Table
| Feature | ISO 27001:2013 (Old) | ISO 27001:2022 (New) |
|---|---|---|
| Total Controls | 114 Controls | 93 Controls |
| Structure | 14 Control Domains (A.5 to A.18) | 4 Themes (Organisational, People, Physical, Tech) |
| New Controls | None | 11 New Controls (e.g., Threat Intel, Cloud Services) |
| Control Attributes | Static descriptions | Includes #Tags (e.g., #Prevention, #Detection, #Cyber) |
| Transition Focus | Legacy focus on physical perimeter | Modern focus on Cloud, Privacy, and Data Deletion |
The 11 New ISO 27001:2022 Controls
| ID | Control Name | Requirement Description | Required Audit Evidence |
|---|---|---|---|
| 5.7 | Threat Intelligence | Collect and analyse threat data to provide situational awareness. | Vetted source list (NCSC/feeds), sample reports, and firewall/EDR action logs based on alerts. |
| 5.23 | Cloud Services Security | Protect data throughout the cloud lifecycle (acquisition to exit). | Cloud Security Policy, Shared Responsibility Matrix, and provider ISO 27001/SOC2 cert reviews. |
| 5.30 | ICT Readiness | Ensure ICT systems are recoverable within required timeframes (RTO/RPO). | BCP/DR plans with specific targets and documented failover/recovery test results. |
| 7.4 | Physical Monitoring | Detect unauthorised physical access using continuous monitoring. | CCTV maintenance logs, server room access logs, and sensor trigger response records. |
| 8.9 | Configuration Management | Manage security configurations for hardware, software, and networks. | Hardened baselines (CIS), change management logs, and drift detection reports. |
| 8.10 | Information Deletion | Delete data when no longer required for compliance or business. | Data Retention Schedule, software-generated deletion logs, and physical destruction certs. |
| 8.11 | Data Masking | Protect sensitive data using pseudonymisation or anonymisation. | Data Masking Policy, technical implementation records, and access logs for unmasked data. |
| 8.12 | Data Leakage Prevention | Detect and prevent unauthorised disclosure of sensitive info. | DLP tool configuration, logs of blocked transfers, and exfiltration incident reports. |
| 8.16 | Monitoring Activities | Monitor systems and applications for anomalous behaviour. | SIEM/Log alerts, activity baselines vs. anomalies, and periodic security log review evidence. |
| 8.23 | Web Filtering | Manage access to external websites to reduce malware exposure. | Web filtering policy, blocked malicious category logs, and URL white-list approval records. |
| 8.28 | Secure Coding | Apply secure coding principles to all software development. | Secure Coding Standards (OWASP), peer review logs, and SAST/DAST vulnerability reports. |
The ISO 27001 Compliance Roadmap: Where the SoA Fits
Gap Analysis & Scoping
Identify what you have and define the boundaries of your ISMS.
Risk Assessment
Identify specific threats to your assets. You cannot write a compliant SoA without this step.
Statement of Applicability (SoA)
The “Golden Thread.” Link your risks to the 93 Annex A controls and document your implementation or exclusion rationales.
Internal Audit
Test your controls against your SoA promises to ensure they are operating effectively.
External Certification
The Stage 1 & Stage 2 audits where the Lead Auditor uses your SoA as the primary audit map.
ISO 27001 Annex A Control Owner Matrix
| Department / Role | Primary Annex A Themes | Typical Evidence Required |
|---|---|---|
| Human Resources (HR) | Theme 6 (People Controls) | Screening records, signed NDAs, training logs, and termination checklists. |
| IT / DevOps | Theme 8 (Technological Controls) | System logs, encryption configs, backup reports, and secure coding SAST results. |
| Facilities / Office Mgmt | Theme 7 (Physical Controls) | CCTV logs, maintenance records for fire/power, and physical access visitor logs. |
| Legal & Compliance | Theme 5 (Organisational Controls) | Legal registers, supplier contracts, privacy impact assessments (DPIA), and IP registers. |
| C-Suite / Leadership | Theme 5 (Governance) | Management Review Meeting (MRM) minutes and signed SoA approval documents. |
Applicability to Small Businesses, Tech Startups, and AI Companies
Whether you’re a small business, a new tech startup, or an AI company, the SoA is a must-have. Here’s a quick look at why it’s so important for each:
| Organisation Type | Strategic Business Case | Practical Technical Examples |
|---|---|---|
| Small Businesses | Vital for establishing commercial trust with enterprise-level clients by demonstrating technical security maturity. | Mandating encryption for payment processing while excluding redundant physical controls like on-site security guards. |
| Tech Startups | Enables scalable innovation by embedding risk management and data protection into the product development lifecycle. | Priority focus on secure coding practices (Annex A 8.28) and granular access control for production environments. |
| AI Companies | Critical for safeguarding proprietary AI models and ensuring ethical handling of massive training datasets. | Implementation of data anonymisation techniques and technical protections for Intellectual Property (IP) theft prevention. |
ISO 27001 Statement of Applicability Template
The ISO 27001:2022 Statement of Applicability Template used in this guide is available to download. This is an ISO 27001 statement of applicability excel worksheet that is fully populated with all of the required controls and fully meets the requirements for ISO 27001 certification.
How to Implement It
Implementing your SoA means putting your plans into action. If your SoA says you’ll use two-factor authentication, you need to make sure you’ve actually set it up. It’s all about making sure what you wrote on paper is what you’re doing in real life. This is the part where you make your security promises a reality.
To implement an ISO 27001 Statement of Applicability (SoA), you must inventory all 93 Annex A controls and document technical rationales for their inclusion or exclusion. This formal record satisfies Clause 6.1.3 requirements, providing auditors with a traceable map of your chosen security posture for 2026 certification.
Step 1: Acquire the ISO 27002:2022 Implementation Guidance
Purchase the formal ISO 27002:2022 standard. While Annex A of ISO 27001 lists the controls, ISO 27002 provides the mandatory technical implementation guidance required for auditor-ready justifications.
- Action: Provision a legal copy of the ISO 27002:2022 standard.
- Result: Access to the technical depth required to implement each of the 93 controls.
Step 2: Provision the Microsoft Excel SoA Framework
Construct a centralised tracking spreadsheet to manage the ISMS scope. This framework must facilitate version control and granular tracking of the 2022 control set.
- Action: Create columns for Control ID, Title, Objective, Applicability, Justification, and Last Assessment Date.
- Result: A functional technical ledger ready for data population.
Step 3: Map Annex A Controls into the Ledger
Transfer the control numbers, titles, and technical objectives directly from the standard into your spreadsheet. This prevents the omission of “New” 2022 controls like Threat Intelligence or Data Masking.
- Action: Laboriously index each of the 93 controls as individual rows.
- Result: A comprehensive baseline that ensures 100% standard coverage.
Step 4: Formalise Technical Rationales for Inclusion
Document the specific drivers for every applicable control. Auditors reject “Because the standard says so”; you must attribute implementation to technical or business necessity.
- Action: Assign each control to a Contract, Legal, Risk, or Business rationale.
- Result: A defensible audit trail that justifies your security investment.
Step 5: Document Auditor-Ready Exclusion Justifications
Explicitly state why any non-applicable controls do not present a risk to your environment. If you do not write code or have a physical office, you must record this rationale to satisfy Clause 6.1.3(d).
- Action: Record specific justifications for “Out-of-Scope” areas like Secure Development or Physical Perimeters.
- Result: Elimination of Major Non-Conformities during the Stage 2 audit.
Step 6: Establish a Mandatory Annual Review Cycle
Review control applicability whenever significant changes occur and at minimum every 12 months. This proves to the auditor that the SoA is a “Living Document” and not a static artifact.
- Action: Timestamp the last assessment date for every control row.
- Result: Continuous compliance posture that reflects the current threat landscape.
Step 7: Tying Reviews to Management Meeting Minutes
Formalise the SoA sign-off within your Management Review Meetings. Tying the document status to your governance minutes is a Tier-1 audit requirement for 2026.
- Action: Record the SoA approval in formal meeting minutes.
- Result: Documented proof of Senior Management commitment to the ISMS.
How the ISO 27001 Toolkit Can Help
An ISO 27001 toolkit is a lifesaver. It’s a package of pre-made documents, templates, and guides. It helps you quickly put together your SoA, saving you a ton of time and effort. It takes the guesswork out of the process, making it much easier to achieve certification.
| Key Feature | HighTable ISO 27001 Toolkit | Online SaaS Platforms |
|---|---|---|
| Data Ownership | Permanent: You maintain absolute ownership of your files. Downloaded documents remain on your secure infrastructure indefinitely. | Rental Model: Access to your compliance data is revoked immediately upon termination of the monthly subscription. |
| Ease of Use | Zero Training: Fully compatible with Microsoft Word and Excel; your team is already proficient in the required software. | Learning Curve: Requires extensive, non-billable training on proprietary user interfaces and platform-specific logic. |
| Cost Structure | One-off Fee: Transparent pricing with no hidden renewals, per-user charges, or mandatory annual subscriptions. | Recurring Expense: Opaque, high-cost recurring fees that create a long-term drain on the information security budget. |
| Vendor Lock-in | Total Freedom: Portability is guaranteed. You can migrate your data between internal systems without “walled garden” restrictions. | Locked-in: Significant technical hurdles when attempting to export data in human-readable formats if you choose to switch. |
| Audit Readiness | Immediate: Highly portable files that can be instantly shared with auditors via secure email or shared drives. | Dependent: Often requires granting external platform access to auditors or navigating complex export menus. |
Information Security Standards That Need It
The Statement of Applicability is a core part of the ISO 27001 standard. You won’t find it in other standards, but many of them, like SOC 2 or NIST, have similar requirements for documenting security controls. The SoA is unique to ISO 27001, making it a key part of that specific certification. Other standards that may benefit include:
| Security Standard / Framework | Relationship to ISO 27001 SoA | Primary Regulatory Focus |
|---|---|---|
| ISO 27001 | Mandatory Requirement: The core technical record of control selection and justification per Clause 6.1.3. | Global Information Security Management |
| SOC 2 | The SoA maps directly to the SOC 2 Trust Services Criteria (TSC) for control documentation and validation. | Service Organisation Controls & Trust |
| NIST | Utilised to align ISO 27001 Annex A controls with the NIST Cybersecurity Framework (CSF) subcategories. | Critical Infrastructure & Federal Security |
| NIS2 | Supports the mandatory risk management measures and reporting obligations required by the EU Directive. | Network and Information Security (EU) |
| DORA | Provides the baseline for digital operational resilience and ICT risk management frameworks in financial services. | Financial Sector Digital Resilience |
| GDPR / CCPA | Acts as evidence for technical and organisational measures (TOMs) required for data privacy protection. | Global Data Privacy & Protection |
| HIPAA | Enables mapping of Administrative, Physical, and Technical Safeguards for protected health information. | Healthcare Information Portability |
List of Relevant ISO 27001:2022 Controls
The ISO 27001 Statement Of Applicability is defined in ISO 27001 clause 6.1.3 Information Security Risk Treatment
| Standard Reference | Control / Clause Name |
|---|---|
| ISO 27001:2022 Clause 6.1.3 | Information Security Risk Treatment |
| ISO 27001:2022 Clause 8.3 | Information Security Risk Treatment |
| ISO 27001:2022 Annex A 5 | Organisational Controls |
| ISO 27001:2022 Annex A 6 | People Controls |
| ISO 27001:2022 Annex A 7 | Physical Controls |
| ISO 27001:2022 Annex A 8 | Technological Controls |
The ISO 27001 Statement Of Applicability is defined in ISO 27001 clause 6.1.3 Information Security Risk Treatment
ISO 27001 SoA Cross-Standard Mapping Table
| ISO 27001:2022 Theme | SOC 2 Trust Services Criteria (TSC) | NIST CSF 2.0 Mapping |
|---|---|---|
| Organisational (Theme 5) | CC1.0 Control Environment & CC5.0 Control Activities | GV.OC (Organisational Context) & GV.PO (Policy) |
| People (Theme 6) | CC2.0 Communication and Information | PR.AT (Awareness and Training) |
| Physical (Theme 7) | CC6.4 Physical Access Controls | PR.PS (Physical Security) |
| Technological (Theme 8) | CC6.0 Logical & Physical Access / CC7.0 System Operations | PR.AC (Access Control) & PR.DS (Data Security) |
| Monitoring & Review | CC4.0 Monitoring Activities | ID.IM (Improvement) & DE.AE (Analysis) |
Leveraging Your SoA for Vendor Due Diligence
Your ISO 27001 Statement of Applicability (SoA) is the single most important document for satisfying customer security audits and vendor due diligence requests. Instead of completing hundreds of unique security questionnaires, you can use your auditor-verified SoA to provide immediate assurance.
- Standardised Evidence: Map the 93 Annex A controls directly to common framework requests like the Cloud Assessments Initiative Questionnaire (CAIQ) or SIG Lite.
- Proof of Implementation: Because your SoA includes rationales for inclusions and exclusions, it provides transparent proof that your security posture is risk-based and legally sound.
- Accelerated Sales Cycles: Proactively sharing your certification and a redacted SoA demonstrates maturity, often bypassing the need for intrusive technical deep-dives by your client’s procurement team.
Lead Auditor Note: When sharing your SoA externally, ensure you share the version that contains your implementation summaries but omit internal system names or specific IP addresses to maintain operational security.
How do you decide what controls to include in a Statement of Applicability (SoA)?
You decide on the controls to include in the Statement of Applicability (SoA) in a number of different ways.
The main approach to identifying the controls that you need is:
- Define ISMS Scope: Establish the organisational boundaries and applicability of your Information Security Management System to provide a clear foundation for control selection.
- Conduct Risk Assessment: Perform a formal evaluation to identify and analyse specific information security risks that threaten your business assets and operations.
- Select Annex A Controls: Identify and choose relevant security controls from ISO 27001 Annex A that effectively mitigate the risks discovered during your assessment.
As a minimum that list of controls is going to include the ISO 27001 Annex A controls. That forms the bare minimum part of the ISO 27001 certification. And to be fair is often enough.
Of course, there may be additional controls that you’re going to record as well that you are implementing either from other standards or from direct requests from your customers.
Additional customer requirements would be captured on your legal and contractual register and the actual controls would be added to your Statement of Applicability (SoA).
As a basic requirement we are going to make a start and we are going to include the ISO 27001 Annex A controls and list them.
The list of ISO 27001 Annex A controls is going to be used many times.
What if the Statement of Applicability (SoA) controls don’t apply?
It is very possible that the list of controls provided in the ISO 27001 Annex A controls includes controls that do not apply to your organisation.
So what should you do? Implement them anyway to pass the ISO 27001 certification?
No.
The approach that you take is record in the Statement of Applicability (SoA) that the controls do apply to you and you state the reason that they do not apply.
If you do not have physical premises and remote work then it is highly possible that the Physical Security Controls such ISO 27001 Annex A Control 7.1 Physical security perimeter, ISO 27001 Annex A Control 7.2 Physical entry controls that apply to data processing facilities will not apply to you. If you do not do software development then the software development controls such as ISO 27001 Annex A 8.25 Secure Development Life Cycle do not apply to you.
Have a complete list but show and record the controls that are not applicable stating the reason why.
As a top tip it would be my recommendation to record all of the out of scope controls on the risk register and manage them through the risk management process which includes accepting the risk and documenting the decision as evidence.
ISO 27001 Statement of Applicability Example
The Statement of Applicability example is what a Statement of Applicability would look like for ISO 27001.
This statement of applicability ISO 27001 example is taken directly from the High Table ISO 27001 Statement of Applicability Template.
ISO 27001 Statement of Applicability (SoA) vs Risk Treatment Plan (RTP) Technical Comparison
| Feature | Statement of Applicability (SoA) | Risk Treatment Plan (RTP) |
|---|---|---|
| Primary Goal | A comprehensive “Inventory of Controls” that justifies every implementation or exclusion decision. | An “Action Plan” detailing how specific risks will be mitigated, accepted, or transferred. |
| Clause Reference | Mandatory under Clause 6.1.3(d). | Mandatory under Clause 6.1.3(e). |
| Focus Area | Broad: Covers all 93 controls from Annex A. | Narrow: Focused only on controls needed to address specific risks found in the assessment. |
| Auditor View | Used to verify the Scope of the ISMS. | Used to verify the Operation and progress of security improvements. |
| External Sharing | High: Often shared with customers to prove security posture. | Low: Usually kept internal as it contains sensitive details about vulnerabilities. |
The Auditor’s SoA Approval Checklist
Under ISO 27001:2022 Clause 6.1.3 (g), your Statement of Applicability must be formally approved by the “Control Owners” and Senior Management. Technical automation is not enough; you must provide evidence of human governance.
- Management Review Minutes: Ensure the SoA is a specific agenda item in your Management Review Meeting (MRM). The minutes must record the date the specific version of the SoA was reviewed.
- Board-Level Exclusion Sign-off: Senior leadership must explicitly accept the risk of any excluded controls (e.g., agreeing that “Secure Coding” is out of scope because no development occurs).
- Digital Signature or Approval Trail: Maintain a version history at the bottom of your SoA spreadsheet that links to the specific MRM approval date.
- Performance Monitoring: Leadership should review the effectiveness of implemented controls, not just their existence, at least once every 12 months.
Lead Auditor Warning: A “Major Non-Conformity” is frequently issued when an SoA exists but the management team cannot demonstrate they understand or have approved the justifications within it.
ISO 27001 SoA Redaction and Sharing Policy
How to Share Your SoA Safely with Customers
Prospective clients often request your Statement of Applicability (SoA) as part of their due diligence. While you must be transparent, you should never compromise operational security. Use this Lead Auditor-verified redaction policy to protect your internal infrastructure.
| Data Field | Visibility Level | Technical Rationale |
|---|---|---|
| Control ID & Name | Always Show | Confirms you are tracking all 93 controls from the 2022 standard. |
| Applicability Status | Always Show | Proves that no critical risks are being ignored without reason. |
| Implementation Summary | Summarise | Describe the *method* (e.g., “MFA is used”) but hide the *vendor* (e.g., “We use Okta”). |
| System Names / IPs | Hide | Redact specific server names, internal IP ranges, or database paths to prevent reconnaissance. |
| Risk References | Hide | Remove internal Risk ID links that could reveal sensitive vulnerability data. |
Pro-Tip: Create a “Public-Facing SoA” PDF that includes the ‘Why it Applies’ column but omits the ‘Technical Evidence’ column used by auditors.
Auditor’s Final Sign-Off: Is Your SoA Audit-Ready?
Before you submit your Statement of Applicability for a UKAS-accredited audit, verify that you can answer ‘Yes’ to these five critical technical requirements. Failure on any single point typically results in a Major Non-Conformity.
- ✓ 100% Control Inclusion: Does your SoA explicitly list all 93 controls from ISO 27001:2022, even those you intend to exclude?
- ✓ Justification of Exclusions: Do all excluded controls have a technical rationale explaining why the risk is non-existent (mathematically zero) in your environment?
- ✓ Implementation Status Summary: For every ‘Applicable’ control, have you provided a brief summary of *how* it is implemented (e.g. policy name or specific technical tool)?
- ✓ Management Review Link: Is the current version of this SoA explicitly cited and approved in your latest Management Review Meeting (MRM) minutes?
- ✓ Version Integrity: Does the version number and date on the SoA match the version number cited in your internal audit and risk treatment reports?
Need a guaranteed pass? Download the Ultimate ISO 27001 Toolkit and get the exact SoA structure used by Lead Auditors.
ISO 27001 SoA Version Control Template
To satisfy Clause 7.5.3 (Control of documented information), your SoA must include a clear version history. Copy the structure below to the ‘Version History’ tab of your SoA spreadsheet.
| Version | Date | Description of Change | Approved By | Ref (MRM Minutes) |
|---|---|---|---|---|
| 1.0 | 2026-01-15 | Initial draft following Risk Assessment. | CISO / Head of IT | MRM-2026-01 |
| 1.1 | 2026-01-29 | Updated to include new 2022 attributes & #Tags. | Management Board | MRM-2026-Q1 |
| 2.0 | [Current] | Annual review: Validated implemented evidence. | CEO / Board | MRM-2027-01 |
Auditor Tip: Your ‘Approved By’ should ideally be a job title, not a person’s name, to ensure the ISMS remains robust during personnel changes.
ISO 27001:2022 Control Attributes and #Tags Matrix
| ID | Control Name (Hover for Objective) | Attributes (#Tags) |
|---|---|---|
| 5.1 | Policies for Information Security | #Preventive |
| 5.2 | Information Security Roles | #Preventive |
| 5.3 | Segregation of Duties | #Preventive |
| 5.4 | Management Responsibilities | #Preventive |
| 5.5 | Contact with Authorities | #Corrective |
| 5.6 | Contact with Interest Groups | #Preventive |
| 5.7 | Threat Intelligence | #Preventive #Detective #Corrective |
| 5.8 | Security in Project Mgmt | #Preventive |
| 5.9 | Inventory of Information | #Preventive |
| 5.10 | Acceptable Use of Assets | #Preventive |
| 5.11 | Return of Assets | #Preventive |
| 5.12 | Classification of Info | #Preventive |
| 5.13 | Labelling of Info | #Preventive |
| 5.14 | Information Transfer | #Preventive |
| 5.15 | Access Control | #Preventive |
| 5.16 | Identity Management | #Preventive |
| 5.17 | Authentication Info | #Preventive |
| 5.18 | Access Rights | #Preventive |
| 5.19 | Security in Supplier Rel | #Preventive |
| 5.20 | Supplier Security Agrmnts | #Preventive |
| 5.21 | Security in ICT Supply Chain | #Preventive |
| 5.22 | Monitoring Supplier Svcs | #Detective |
| 5.23 | Cloud Services Security | #Preventive |
| 5.24 | Incident Mgmt Planning | #Corrective |
| 5.25 | Assessment of Events | #Detective |
| 5.26 | Response to Incidents | #Corrective |
| 5.27 | Learning from Incidents | #Corrective |
| 5.28 | Collection of Evidence | #Corrective |
| 5.29 | Security during Disruption | #Corrective |
| 5.30 | ICT Readiness for BCP | #Corrective |
| 5.31 | Legal & Regulatory Reqs | #Preventive |
| 5.32 | IP Rights | #Preventive |
| 5.33 | Protection of Records | #Preventive |
| 5.34 | Privacy & PII Protection | #Preventive |
| 5.35 | Independent Review | #Detective |
| 5.36 | Compliance with Policies | #Preventive |
| 5.37 | Documented Op Procedures | #Preventive |
| 6.1 | Screening | #Preventive |
| 6.2 | Terms & Cond of Employment | #Preventive |
| 6.3 | Security Awareness/Training | #Preventive |
| 6.4 | Disciplinary Process | #Corrective |
| 6.5 | Resp after Termination | #Preventive |
| 6.6 | Confidentiality/NDA | #Preventive |
| 6.7 | Remote Working | #Preventive |
| 6.8 | Security Event Reporting | #Detective |
| 7.1 | Physical Perimeters | #Preventive |
| 7.2 | Physical Entry | #Preventive |
| 7.3 | Securing Offices/Facilities | #Preventive |
| 7.4 | Physical Security Monitoring | #Detective |
| 7.5 | Protecting against Threats | #Preventive |
| 7.6 | Working in Secure Areas | #Preventive |
| 7.7 | Clear Desk & Clear Screen | #Preventive |
| 7.8 | Equipment Siting/Protection | #Preventive |
| 7.9 | Assets Off-Premises | #Preventive |
| 7.10 | Storage Media | #Preventive |
| 7.11 | Supporting Utilities | #Preventive |
| 7.12 | Cabling Security | #Preventive |
| 7.13 | Equipment Maintenance | #Preventive |
| 7.14 | Secure Disposal/Reuse | #Preventive |
| 8.1 | User Endpoint Devices | #Preventive |
| 8.2 | Privileged Access Rights | #Preventive |
| 8.3 | Info Access Restriction | #Preventive |
| 8.4 | Access to Source Code | #Preventive |
| 8.5 | Secure Authentication | #Preventive |
| 8.6 | Capacity Management | #Preventive |
| 8.7 | Protection against Malware | #Preventive |
| 8.8 | Technical Vulnerability Mgmt | #Preventive |
| 8.9 | Configuration Management | #Preventive |
| 8.10 | Information Deletion | #Preventive |
| 8.11 | Data Masking | #Preventive |
| 8.12 | Data Leakage Prevention | #Preventive #Detective |
| 8.13 | Information Backup | #Corrective |
| 8.14 | Redundancy of Processing | #Preventive |
| 8.15 | Logging | #Detective |
| 8.16 | Monitoring Activities | #Detective |
| 8.17 | Clock Synchronisation | #Preventive |
| 8.18 | Use of Privileged Utilities | #Preventive |
| 8.19 | Software Installation | #Preventive |
| 8.20 | Network Security | #Preventive |
| 8.21 | Security of Network Svcs | #Preventive |
| 8.22 | Segregation of Networks | #Preventive |
| 8.23 | Web Filtering | #Preventive |
| 8.24 | Use of Cryptography | #Preventive |
| 8.25 | Secure Dev Life Cycle | #Preventive |
| 8.26 | App Security Reqs | #Preventive |
| 8.27 | Secure Architecture | #Preventive |
| 8.28 | Secure Coding | #Preventive |
| 8.29 | Security Testing in Dev | #Detective |
| 8.30 | Outsourced Development | #Preventive |
| 8.31 | Separation of Environments | #Preventive |
| 8.32 | Change Management | #Preventive |
| 8.33 | Test Information | #Preventive |
| 8.34 | Protection during Audit | #Preventive |
ISO 27001 Statement of Applicability FAQ
What is an ISO 27001 Statement of Applicability (SoA)?
The Statement of Applicability (SoA) is a mandatory document that identifies which of the 93 ISO 27001:2022 Annex A controls apply to your organisation’s Information Security Management System (ISMS). It serves as the definitive link between your risk assessment and your chosen risk treatment plan, providing a justification for every control included or excluded.
How do you write an ISO 27001 Statement of Applicability?
To write an ISO 27001 SoA, list all 93 Annex A controls in a table (ideally an Excel spreadsheet) and add columns for applicability, justifications (legal, business, or risk-based), and implementation descriptions. You must include columns for review dates to ensure the document remains a living record of your security posture.
Is the Statement of Applicability mandatory for ISO 27001 certification?
Yes, the Statement of Applicability is 100% mandatory under Clause 6.1.3 of the ISO 27001 standard. An organisation cannot achieve UKAS-accredited certification without a finalised SoA, as it is the primary document used by external auditors to verify the scope and effectiveness of the security controls you have implemented.
Is the SoA the same as a risk assessment?
No, the SoA and risk assessment perform different functions; the risk assessment identifies the specific security threats your business faces, whereas the SoA defines the specific controls you have chosen to mitigate those risks. Together, they form the core of your Risk Treatment Plan (RTP).
How long does it take to write an ISO 27001 Statement of Applicability?
Writing an SoA can take between one day and several weeks depending on your organisation’s size and complexity. While the mechanical task of listing controls is quick, the high-value activity lies in accurately justifying exclusions and describing implemented controls to satisfy auditor requirements.
Can you exclude controls from the ISO 27001 Statement of Applicability?
You can exclude any of the 93 Annex A controls if they are not relevant to your business operations, but you must provide a clear, documented justification for each exclusion. For example, if your organisation does not engage in software development, you may exclude the secure coding controls, provided this is recorded within the SoA document.
Is an ISO 27001 Statement of Applicability confidential?
No, the Statement of Applicability is not considered a confidential document and is frequently requested by clients, customers, and auditors during the due diligence process. While it shouldn’t contain sensitive technical passwords, it must be available to demonstrate your security framework’s maturity.
Who owns the ISO 27001 Statement of Applicability?
Ownership typically sits with the Head of Information Security or CISO, but for maximum effectiveness, it should be overseen by a member of the senior leadership team or board. This ensures that the security controls align with the business’s overall risk appetite and strategic objectives.
About the author
