ISO 27001 SoA: How to Write It Without BS

The Statement of Applicability is the document that certification body auditors open first. It is the map they use to navigate your entire ISMS. A well-written SoA makes the audit efficient and predictable. A poorly written one generates questions, follow-ups, and nonconformities that could have been avoided.

Despite its importance, the SoA is the document most companies get wrong. They copy generic templates, use vague justifications, exclude controls without defensible reasoning, and fail to link the SoA to their actual risk treatment decisions.

This article explains what the SoA is, how to structure it so auditors accept it, how to justify exclusions without raising flags, and how to keep it maintainable as your organization changes. For broader ISMS context, see our guide on ISO 27001 for B2B SaaS.

What the SoA Is and Why Auditors Focus on It

The Statement of Applicability is a mandatory document required by ISO 27001 Clause 6.1.3. It lists all the controls from Annex A (93 controls in the 2022 version), states whether each control is applicable or not applicable to your organization, and provides a justification for each decision.

Why It Matters

The SoA serves three critical functions.

First, it defines the audit scope. The certification body uses your SoA to determine what they will test during the Stage 2 audit. Every control marked as applicable will be examined. Every exclusion will be scrutinized for justification.

Second, it links risk treatment to controls. The SoA connects your risk assessment to your control selection. It shows that you selected controls based on identified risks, not by copying a template.

Third, it communicates your security posture. The SoA tells customers, partners, and regulators exactly which controls your organization has implemented. It is the document procurement teams reference when evaluating your ISO 27001 certificate.

What Auditors Evaluate

Certification auditors look at five dimensions: completeness (does it cover all 93 controls), justification quality (are reasons specific to your organization), consistency (does it align with your risk assessment), currency (is it version-controlled and recently reviewed), and evidence mapping (can each applicable control be traced to specific artifacts).

SoA Structure: Column by Column

There is no mandatory format, but certification bodies expect certain information for each control. The most effective format is a spreadsheet or table with clearly defined columns.

Column 1: Control Reference

The Annex A control number and name. Example: A.5.1 Policies for information security. Use the exact numbering from the 2022 standard. If you are transitioning from 2013, make sure you have mapped to the new control numbering.

Column 2: Applicable / Not Applicable

A clear determination. Do not use "partially applicable" here. A control is either in scope or not. If a control is applicable but only partially implemented, that is captured in the implementation status column.

Column 3: Justification

This is the most important column. For applicable controls, explain why the control is relevant to your organization and how it relates to identified risks. For excluded controls, provide a specific, defensible reason tied to your environment.

Bad justification: "Not applicable to our business."

Good justification: "The organization operates entirely on cloud infrastructure (AWS eu-west-1 and us-east-1 regions). No company-owned data centers, server rooms, or co-location facilities exist within the ISMS scope. Physical environmental protection for server infrastructure is managed by the cloud provider under their ISO 27001 and SOC 2 certifications."

Column 4: Implementation Status

Use clear categories: Implemented, Partially Implemented, or Planned. A control marked as Planned is not a nonconformity if your risk treatment plan includes a timeline for implementation and the auditor agrees the interim risk is acceptable.

Column 5: Risk Reference

Link to the specific risk(s) in your risk register that this control addresses. Example: "R-001, R-015." This demonstrates that control selection is risk-driven. Some controls will map to multiple risks. Some risks require multiple controls.

Column 6: Evidence Reference

Point to the policy, procedure, configuration, or artifact that proves the control is operating. Example: "Access Control Policy v2.3, Okta SSO configuration screenshot, Quarterly Access Review Q4-2025." This saves the auditor time during the examination. For guidance on structuring your evidence, see the SOC 2 evidence checklist which maps evidence patterns that work across both frameworks.

Column 7: Control Owner

The individual responsible for maintaining and providing evidence for the control. Not a team name — a person's name and role.

Column 8: Last Review Date

When the applicability determination was last reviewed. This demonstrates that the SoA is maintained, not static.

The 4 Control Themes in 2022

ISO 27001:2022 reorganized Annex A from 14 domains into 4 themes. Understanding this structure helps you organize your SoA and communicate with auditors.

Organizational Controls (A.5): 37 Controls

These cover governance, policies, roles, threat intelligence, asset management, access control policies, supplier management, incident management, business continuity, and compliance. For a SaaS company, nearly all 37 are applicable.

Key controls that get the most auditor attention: A.5.1 (policies for information security — the foundation document), A.5.7 (threat intelligence — new in 2022, requires you to collect and act on threat information), A.5.19-A.5.23 (supplier management — covers your entire vendor ecosystem), and A.5.24-A.5.28 (incident management — the auditor will test your actual incident response capability).

People Controls (A.6): 8 Controls

All 8 are applicable for any company with employees. A.6.1 (screening/background checks), A.6.2 (terms of employment including security responsibilities), A.6.3 (awareness and training), A.6.4 (disciplinary process), A.6.5 (responsibilities after termination), A.6.6 (confidentiality agreements), A.6.7 (remote working — critical for distributed SaaS teams), and A.6.8 (information security event reporting).

Physical Controls (A.7): 14 Controls

This is where SaaS companies have the most legitimate exclusions. But do not exclude too aggressively. Even without a data center, you likely have an office (or co-working space), employee laptops, and potentially physical media.

Applicable for most SaaS: A.7.1 (physical security perimeters — your office), A.7.7 (clear desk/clear screen), A.7.8 (equipment siting and protection), A.7.9 (security of assets off-premises — employee laptops), A.7.10 (storage media), A.7.13 (equipment maintenance), A.7.14 (secure disposal — for employee devices).

Commonly excluded with justification: A.7.3 (securing offices for server rooms), A.7.4 (physical security monitoring for data centers), A.7.5 (protecting against environmental threats to server infrastructure), A.7.11 (supporting utilities for data centers), A.7.12 (cabling security for data centers).

Technological Controls (A.8): 34 Controls

Nearly all 34 apply to SaaS companies. This is the most evidence-intensive theme. Key groups:

Access management (A.8.2-A.8.5): user endpoint devices, privileged access, access restriction, secure authentication. Evidence comes from Okta, AWS IAM, and your identity provider.

Operations security (A.8.7-A.8.10): malware protection, vulnerability management, configuration management, information deletion.

Monitoring and logging (A.8.15-A.8.16): logging and monitoring activities. Evidence from Datadog, Splunk, CloudWatch, or your SIEM.

Development (A.8.25-A.8.28): secure development lifecycle, application security requirements, secure system architecture, and secure coding. For SaaS companies, these require documented SDLC practices, code review requirements, and security testing integration.

Controls SaaS Companies Commonly Exclude

Here are the most common exclusions with justification language that auditors accept.

A.7.4 (Physical security monitoring): "The organization does not operate physical data center facilities. All computing infrastructure is hosted on AWS within the provider's SOC 2 Type II and ISO 27001 certified data centers. Physical security monitoring of compute infrastructure is managed by AWS."

A.7.5 (Protecting against physical and environmental threats): "Excluded for server infrastructure. The organization has no on-premises computing equipment. Cloud provider manages environmental controls. Note: This control remains applicable for the organization's office space regarding fire safety and environmental conditions for employee workstations."

A.7.11 (Supporting utilities): "The organization does not manage uninterruptible power supplies, backup generators, or redundant cooling systems for computing infrastructure. These are managed by the cloud provider."

A.7.12 (Cabling security): "The organization does not manage network cabling for computing infrastructure. All networking is software-defined within the cloud environment."

Do not exclude controls related to employee equipment, office security, or portable devices. Even if you are fully remote, laptops and mobile devices require physical security considerations.

Linking SoA to Risk Treatment

The connection between your risk assessment, risk treatment plan, and SoA is what transforms the SoA from a compliance checklist into a meaningful security document.

The Traceability Chain

The chain works like this: Risk Assessment identifies threats and rates them by likelihood and impact. Risk Treatment Plan determines how each risk will be treated (mitigate, accept, transfer, avoid) and specifies which controls will be applied. Statement of Applicability documents which Annex A controls are selected based on treatment decisions, plus any additional controls selected for legal, contractual, or business reasons.

When an auditor reads your SoA, they should be able to trace any applicable control back through the risk treatment plan to a specific identified risk. This traceability is what demonstrates that your ISMS is risk-driven rather than checkbox-driven.

Controls Without Risk References

Some controls will be applicable not because of a specific identified risk but because of legal or contractual requirements. GDPR requires certain data protection controls regardless of risk assessment outcomes. Customer contracts may mandate specific security measures. Document these drivers in the justification column. For practical guidance on GDPR control mapping, see our GDPR operations guide.

Common Auditor Pushback on SoAs

After reviewing hundreds of SoAs, certification body auditors have patterns they flag immediately.

Generic Justifications

If your justification reads the same for five different controls, the auditor will question whether you actually assessed each one individually. Every justification should reference your specific environment, risk assessment findings, or operational context.

Over-Exclusion of Physical Controls

Excluding all physical controls because you are "cloud-native" does not work if you have an office with employee workstations, a reception area, or visitor access. The auditor will ask about your office environment during Stage 2 interviews.

Missing Implementation for Applicable Controls

Marking a control as applicable and implemented when you cannot produce evidence is worse than marking it as partially implemented. Be honest about implementation status. An auditor prefers transparency over false claims.

No Version Control

The SoA without version history, review dates, or approver information fails the document control requirements of the standard. Include version number, effective date, next review date, and approver name in the document header.

Inconsistency with Risk Register

If your risk register identifies unauthorized access as a high risk but your SoA does not show robust access control implementation, the auditor will flag the disconnect. Review the SoA and risk register together to verify alignment.

SoA Review and Maintenance

Review Triggers

Review the SoA when any of these occur: annual management review cycle, ISMS scope change, major infrastructure migration (switching cloud providers, adding regions), new product line or business function entering scope, organizational restructuring, regulatory change affecting your industry, and after any significant security incident.

Review Process

Assign one person to coordinate the review (typically CISO or compliance lead). Ask each control owner to confirm: is this control still applicable, is the implementation status accurate, is the evidence reference current, has anything changed in their domain since last review.

Document the review with date, participants, and any changes made. Update the version number. Have the review approved by the ISMS management representative.

Version Control

Maintain a version history table in the SoA document: version number, date, author, changes made, approver. This demonstrates that the document is actively managed under your document control process.

Vendor and Subprocessor Controls

Supplier management controls (A.5.19 through A.5.23) are among the most scrutinized for SaaS companies because your entire infrastructure depends on third parties.

Your SoA should show that you have: a vendor management policy (A.5.19), information security requirements in supplier agreements (A.5.20), management of information security in the ICT supply chain (A.5.21), monitoring and review of supplier services (A.5.22), and information security for cloud services (A.5.23).

For each of these, the evidence should demonstrate active vendor management, not just a policy sitting in a folder. Auditors want to see current vendor SOC 2 reports, completed vendor risk assessments, and documented review processes. For a detailed approach to building this program, see our vendor risk management guide.

Getting Started

The Statement of Applicability is the backbone of your ISO 27001 ISMS. Getting it right from the start saves significant time during the certification audit and makes ongoing maintenance straightforward.

Start with the complete list of 93 controls. For each one, ask: does this control address a risk we identified, and can we implement it in our environment? Document the answer with specific justification. Link to risks. Assign owners. Reference evidence.

CertifyOps helps B2B SaaS companies build Statements of Applicability that are audit-ready, risk-driven, and maintainable. If you are preparing for ISO 27001 certification and need guidance on your SoA, contact us to discuss your ISMS program.