ISO 27001 Statement of Applicability (SoA): How to Create It

The Statement of Applicability is the single most important document in your ISO 27001 ISMS. That is not hyperbole. It is the document that connects your risk assessment to your controls, justifies why you implemented what you implemented (and excluded what you excluded), and serves as the primary reference point for certification auditors. An inadequate SoA is the fastest path to audit nonconformities, and a well-crafted SoA demonstrates that your ISMS is a coherent, risk-driven system rather than a collection of controls chosen at random.

Clause 6.1.3 d) of ISO 27001 requires organizations to produce a Statement of Applicability that contains the necessary controls, the justification for their inclusion, whether they are implemented or not, and the justification for excluding any controls from Annex A. Every one of the 93 Annex A controls must be addressed — you cannot simply omit controls without explanation.

This guide walks through what the SoA is, what it must contain, how to create one step by step from your risk treatment plan, and the common mistakes that lead to audit findings.

What Is the Statement of Applicability?

The Statement of Applicability is a documented record of all controls considered for the ISMS, along with the justification for their inclusion or exclusion. It bridges two critical processes:

1. Risk assessment results — the risks you have identified, analyzed, and evaluated
2. Control implementation — the specific measures you have deployed to treat those risks

Without the SoA, there is no formal connection between “we identified these risks” and “we implemented these controls.” The risk assessment tells you what could go wrong. The SoA tells you what you did about it — and, equally important, what you decided not to do and why.

Where the SoA Sits in the ISMS

The SoA is produced after the risk assessment and risk treatment plan, and before (or concurrent with) control implementation. The sequence is:

1. Risk assessment (Clause 6.1.2) — identify and evaluate risks
2. Risk treatment plan (Clause 6.1.3) — decide how to treat each risk
3. Statement of Applicability (Clause 6.1.3 d) — document which controls address which risks
4. Control implementation — deploy the controls documented in the SoA
5. Internal audit (Clause 9.2) — verify controls are implemented and effective
6. Certification audit — external auditor reviews the SoA and verifies implementation

In practice, steps 3 and 4 are often iterative — you may refine the SoA as you implement controls and discover that some controls need to be adjusted or additional controls are needed.

What Clause 6.1.3 Actually Requires

Clause 6.1.3 d) states that the organization shall produce a Statement of Applicability that contains:

• The necessary controls — considering the results of the risk assessment and risk treatment process, and regardless of whether they are from Annex A or another source
• Justification for their inclusion — why each control is in scope
• Whether the necessary controls are implemented or not — current implementation status
• Justification for excluding any Annex A controls — why excluded controls do not apply

The phrase “regardless of whether they are from Annex A or another source” is important. Your SoA must include all 93 Annex A controls as a baseline, but you can also include controls from other sources (NIST, CIS, industry-specific frameworks, or custom controls your organization has developed). Annex A is the minimum set to consider, not the maximum.

Required Components of the SoA

A complete SoA includes the following information for each control:

Control Reference and Title

The Annex A control number and its name. For the 2022 version, this is A.5.1 through A.8.34. If you have additional controls from other sources, include those with a consistent reference scheme (e.g., CUSTOM-001, NIST-AC-2).

Inclusion or Exclusion Decision

A clear statement of whether the control is included (applicable) or excluded (not applicable) for your ISMS. This is a binary decision — there is no “partially applicable.” If any aspect of a control applies, it is included.

Justification for Inclusion

For each included control, state why it is necessary. The justification should trace to one or more of the following:

• Risk treatment — the control mitigates a specific risk identified in the risk assessment (reference the risk ID)
• Legal or regulatory requirement — the control is required by applicable law or regulation (e.g., GDPR, industry regulation)
• Contractual obligation — the control is required by customer contracts or business agreements
• Best practice — the control is implemented as a best practice even though no specific risk, legal, or contractual requirement mandates it (this is acceptable but should be the exception, not the rule)

Example justification for inclusion: “Included. A.8.5 (Secure authentication) addresses RISK-2026-003 (Unauthorized access to customer data through credential compromise) and RISK-2026-015 (Account takeover via phishing). MFA is also a contractual requirement in our enterprise customer agreements.”

Justification for Exclusion

For each excluded control, state why it is not applicable to your ISMS. The justification must demonstrate that excluding the control does not compromise information security. Generic statements like “not applicable” are insufficient.

Example justification for exclusion: “Excluded. A.7.12 (Cabling security) is not applicable because the organization has no on-premises data center or server room. All production infrastructure is hosted in AWS, where physical cabling security is managed by AWS under their shared responsibility model. Office networking uses standard commercial equipment with no sensitive data processed locally. Excluding this control does not create an unaddressed security risk.”

Implementation Status

For each included control, indicate whether it is:

• Implemented — the control is fully deployed and operating
• Partially implemented — some aspects are in place but others are pending (describe what is done and what remains)
• Planned — the control is not yet implemented but is scheduled for implementation (include target date)
• Not yet started — the control is included but implementation has not begun (include target date)

The implementation status is particularly important during initial certification. It is acceptable to have controls that are “planned” or “partially implemented” at the time you produce the SoA — but they must be fully implemented before the Stage 2 certification audit. Auditors will verify implementation against what the SoA claims.

Control Owner

Designate an individual responsible for each control’s implementation and ongoing operation. This is not always required by auditors, but it is strongly recommended because it establishes accountability and ensures controls do not become orphaned.

Step-by-Step: Creating the SoA from Your Risk Treatment Plan

Step 1: Start with the Complete Annex A Control List

Create a document (spreadsheet, database, or compliance management tool) that lists all 93 Annex A controls. Each row represents one control with columns for: control reference, control title, inclusion/exclusion, justification, implementation status, risk reference(s), and owner.

Do not skip controls. Every one of the 93 must have a row and a decision. Auditors will check for completeness.

Step 2: Map Your Risk Treatment Plan to Annex A Controls

Take your risk treatment plan — which lists each risk and the treatment actions you have decided on — and map each treatment action to one or more Annex A controls.

Example mapping:

Risk	Treatment Action	Annex A Control
RISK-001: Unauthorized access to production database	Implement MFA for all production access	A.8.5 (Secure authentication)
RISK-001: Unauthorized access to production database	Enforce role-based access with least privilege	A.5.15 (Access control), A.8.3 (Information access restriction)
RISK-001: Unauthorized access to production database	Conduct quarterly access reviews	A.5.18 (Access rights)
RISK-002: Data breach via software vulnerability	Implement vulnerability scanning in CI/CD	A.8.8 (Management of technical vulnerabilities), A.8.29 (Security testing)
RISK-002: Data breach via software vulnerability	Enforce code review for all changes	A.8.25 (Secure development lifecycle)
RISK-003: Vendor breach exposing customer data	Conduct vendor security assessments	A.5.19 (Supplier relationships)
RISK-003: Vendor breach exposing customer data	Include security requirements in vendor contracts	A.5.20 (Supplier agreements)

This mapping identifies which Annex A controls are “necessary” — they are included because they directly address identified risks.

Step 3: Identify Controls Required by Law, Regulation, or Contract

Some Annex A controls are necessary not because of a specific risk in your register but because of legal, regulatory, or contractual obligations.

Examples:

• A.5.34 (Privacy and protection of PII) — required if you process personal data subject to GDPR or other privacy regulations
• A.5.31 (Legal, statutory, regulatory requirements) — required for all organizations to identify applicable legal requirements
• A.5.28 (Collection of evidence) — may be required by industry regulations mandating forensic readiness
• A.8.24 (Use of cryptography) — encryption requirements may be contractual obligations in enterprise customer agreements

Mark these controls as included with the appropriate justification (legal requirement, contractual obligation).

Step 4: Review Remaining Controls for Applicability

After mapping risk treatment actions and legal/contractual requirements, some Annex A controls may not yet be addressed. For each remaining control, determine whether it is applicable to your organization:

• Does the control address a risk that exists in your environment? If yes, you may have a gap in your risk assessment — consider whether the risk should be added to your register, or whether existing controls already address it under a different Annex A reference.
• Is the control relevant to your operations, technology, or business model? Cloud-native SaaS companies may find some physical controls genuinely inapplicable. But be cautious about exclusions — auditors scrutinize them.
• Would excluding the control create a security gap? If excluding a control means no measure addresses a relevant threat, the exclusion is inappropriate.

Step 5: Document Justifications

For every control — included and excluded — write a clear, specific justification. This is the most time-consuming step but also the most important for audit readiness.

Justification quality spectrum:

Poor (will trigger audit questions):

• “Included — required for security”
• “Excluded — not applicable”
• “Included — best practice”

Acceptable (meets minimum requirements):

• “Included — addresses the risk of unauthorized access to production systems (RISK-2026-003)”
• “Excluded — the organization has no physical data center; all infrastructure is cloud-hosted”

Strong (demonstrates a mature, risk-driven ISMS):

• “Included — addresses RISK-2026-003 (unauthorized access to production systems via credential compromise, rated High). Implemented through Okta MFA enforcement for all production access, SSO integration with AWS IAM Identity Center, and session management policies requiring re-authentication after 12 hours of inactivity. Last verified during Q3 2026 access review.”
• “Excluded — the organization operates no physical data center or server room. All production infrastructure is hosted in AWS eu-west-1 and eu-central-1 regions, where physical cabling security is managed by AWS under SOC 2 Type II certification (report reviewed annually under A.5.22). Office networking consists of standard commercial equipment processing no sensitive data. Residual risk from this exclusion: negligible.”

Step 6: Record Implementation Status

For each included control, assess and document the current implementation status. Be honest — misrepresenting implementation status and getting caught during the audit is far worse than acknowledging that a control is still being implemented.

Implementation status examples:

• A.8.5 (Secure authentication) — Implemented. MFA enforced via Okta for all internal systems. SSO configured for AWS, GitHub, Datadog, and Jira. Hardware security keys issued to all engineers with production access. Last configuration review: January 2026.

• A.8.12 (Data leakage prevention) — Partially implemented. Endpoint DLP deployed on all company-managed laptops (CrowdStrike Falcon). Email DLP rules active in Google Workspace. API-level DLP monitoring planned for Q2 2026 (target completion: May 2026).

• A.8.11 (Data masking) — Planned. Data masking tool evaluation completed. Selected solution: Tonic.ai. Implementation scheduled for Q2 2026, starting with staging environment data refresh pipeline. Target completion: June 2026.

Step 7: Assign Owners

Assign a named individual (not a team or role) as the owner for each control. The owner is accountable for:

• Ensuring the control is implemented as documented
• Maintaining evidence of the control’s operation
• Reporting on the control’s effectiveness during management reviews
• Updating the control when risks, requirements, or the environment change

For SaaS companies, control ownership often follows this pattern:

Control Theme	Typical Owner
A.5 Organizational (governance, policies)	CISO / Head of Security
A.5 Organizational (supplier management)	Vendor Management Lead / Procurement
A.6 People	HR Lead / People Operations
A.7 Physical	Office Manager / Facilities
A.8 Technological (infrastructure)	Platform / Infrastructure Engineering Lead
A.8 Technological (application)	Engineering Lead / CTO
A.8 Technological (endpoints)	IT Operations Lead

Step 8: Review and Approve

The completed SoA must be reviewed and approved by management — typically the ISMS owner (CISO), the management representative, or the risk committee. Approval demonstrates that management has reviewed and accepted the control selection, the exclusion decisions, and the current implementation status.

Document the approval with:

• Approver name and role
• Approval date
• Version number — the SoA is a versioned document that changes over time
• Next review date — when the SoA will be formally reviewed (at minimum, annually)

The SoA as a Living Document

The Statement of Applicability is not a one-time deliverable that you create for certification and file away. It is a living document that must be updated whenever your ISMS changes.

Triggers for SoA Updates

Risk assessment changes. When new risks are identified, existing risks are re-evaluated, or risk treatment plans change, the SoA must be updated to reflect any changes in control selection or justification. If your annual risk assessment identifies new threats that require additional controls, those controls are added to the SoA.

Control implementation progress. As controls move from “planned” to “partially implemented” to “implemented,” update the SoA to reflect the current status. This is particularly important in the period between initial SoA creation and the Stage 2 certification audit.

Organizational changes. New products, services, markets, or business models may introduce new risks or make previously excluded controls relevant. If your SaaS company launches a product that processes health data, controls related to regulatory compliance (A.5.31, A.5.34) may need updated justification.

Regulatory changes. New laws or updated regulations may require additional controls or change the justification for existing ones.

Audit findings. If your internal audit or a surveillance audit identifies gaps, the SoA may need updates to add controls, strengthen justifications, or correct implementation status claims.

Technology changes. Migrating cloud providers, adopting new development tools, or changing your architecture may affect which controls are applicable and how they are implemented.

Version Control

Maintain version history for the SoA:

Version	Date	Author	Changes	Approved By
1.0	2026-01-15	Jane Smith, CISO	Initial SoA for certification	John Doe, CTO
1.1	2026-04-20	Jane Smith, CISO	Updated A.8.12 status to Implemented; added RISK-2026-042 mapping to A.5.23	John Doe, CTO
1.2	2026-07-10	Jane Smith, CISO	Annual review; updated justifications for A.7.1-A.7.6 following office relocation	John Doe, CTO

Review Cadence

• Minimum: Annual review aligned with the management review cycle
• Recommended: Quarterly review aligned with risk register reviews
• Triggered: Update within 30 days of significant changes (new risks, audit findings, organizational changes)

SoA vs. Risk Treatment Plan: Understanding the Difference

The SoA and the risk treatment plan are closely related but serve different purposes. Confusing the two — or treating them as interchangeable — is a common mistake.

Risk Treatment Plan

Purpose: Documents how each identified risk will be treated (mitigate, transfer, avoid, accept) and the specific actions planned.

Content:

• Each risk requiring treatment
• Selected treatment option
• Specific treatment actions
• Owner and target dates
• Expected residual risk after treatment

Focus: Risk-centric. Organized around risks, not controls.

Audience: Risk owners, management, auditors (for verifying treatment decisions).

Statement of Applicability

Purpose: Documents which controls are in scope for the ISMS, with justification for inclusion and exclusion.

Content:

• Every Annex A control (all 93)
• Inclusion/exclusion decision with justification
• Implementation status
• Risk references (tracing controls back to risks)
• Control owners

Focus: Control-centric. Organized around the Annex A control structure.

Audience: Auditors (primary reference during certification), management, implementation teams.

How They Connect

The risk treatment plan is an input to the SoA. When your risk treatment plan says “mitigate RISK-001 by implementing MFA,” the SoA records that A.8.5 (Secure authentication) is included because it addresses RISK-001, and notes its implementation status.

The relationship is many-to-many:

• One risk may require multiple controls (RISK-001 maps to A.5.15, A.5.18, A.8.3, A.8.5)
• One control may address multiple risks (A.8.15 Logging addresses risks related to unauthorized access, incident detection, forensic readiness, and compliance)

Both documents must be consistent. If the risk treatment plan says a risk is being mitigated through specific controls, the SoA must show those controls as included. If the SoA excludes a control, no risk in the treatment plan should depend on that control for mitigation.

Common SoA Audit Nonconformities

Understanding what auditors look for helps you avoid the most common findings.

Nonconformity 1: Missing or Incomplete Justifications

The finding: Controls are marked as included or excluded without adequate justification. The SoA says “Included” or “Excluded” but does not explain why.

Why it matters: Without justification, the auditor cannot verify that your control selection is risk-driven. It appears that controls were selected arbitrarily or copied from a template.

How to avoid it: Write specific justifications that reference risk IDs, legal requirements, or contractual obligations. For exclusions, explain why the risk the control addresses is not applicable to your organization.

Nonconformity 2: Controls Excluded Without Valid Justification

The finding: Controls are excluded with justifications that do not hold up to scrutiny. For example, excluding A.8.8 (Management of technical vulnerabilities) with the justification “managed by cloud provider” when the organization runs custom application code that is clearly within scope for vulnerability management.

Why it matters: Invalid exclusions suggest either a lack of understanding of the controls or an attempt to reduce the implementation burden by excluding applicable controls.

How to avoid it: Before excluding any control, ask: “Is there any scenario within our ISMS scope where the risk this control addresses could materialize?” If yes, the control should likely be included. The shared responsibility model with cloud providers is a common source of confusion — your cloud provider manages physical security, but you manage application security, access control, configuration, and most other controls.

Nonconformity 3: Implementation Status Misrepresented

The finding: The SoA claims a control is “Implemented” but the auditor finds no evidence of implementation, or the implementation does not meet the intent of the control.

Why it matters: Misrepresenting implementation status undermines the credibility of the entire SoA and can result in a major nonconformity.

How to avoid it: Be honest about implementation status. “Partially implemented” or “Planned with target date” is far better than claiming full implementation that cannot be demonstrated. Auditors respect transparency and work with organizations to address gaps — they do not respect misrepresentation.

Nonconformity 4: SoA Not Updated After Changes

The finding: The SoA reflects the state of the ISMS at a point in time that no longer matches reality. New risks have been identified, controls have been implemented or removed, but the SoA has not been updated.

Why it matters: An outdated SoA indicates that the document is treated as a one-time certification artifact rather than a living part of the ISMS. It also means the auditor cannot rely on the SoA as an accurate representation of the control environment.

How to avoid it: Establish a review cadence (quarterly recommended) and triggers for ad hoc updates. Include SoA maintenance as an agenda item in management reviews.

Nonconformity 5: No Traceability Between Risk Assessment and SoA

The finding: The risk register identifies certain risks, but the SoA does not include controls that address those risks. Or the SoA includes controls without referencing the risks they address.

Why it matters: Traceability is the core principle of ISO 27001. The standard requires a risk-driven approach to control selection. Without traceability, there is no evidence that the approach is risk-driven.

How to avoid it: Include risk reference IDs in the SoA justification column. When reviewing the SoA, cross-reference against the risk register to verify that every risk above the acceptance threshold has corresponding controls, and every included control has a documented reason for inclusion.

Nonconformity 6: Annex A Controls Not Fully Addressed

The finding: The SoA does not list all 93 Annex A controls. Some controls are simply absent from the document.

Why it matters: Clause 6.1.3 d) requires the organization to determine “all controls that are necessary” and compare them against Annex A to verify nothing has been overlooked. If controls are missing from the SoA, there is no evidence that they were considered.

How to avoid it: Start with a complete list of all 93 controls and work through each one. Use a template or compliance tool that enforces completeness.

Nonconformity 7: SoA and Actual Controls Do Not Match

The finding: The SoA documents certain controls, but the actual implementation differs. For example, the SoA says MFA is implemented for all users, but the auditor finds that service accounts bypass MFA.

Why it matters: The SoA is supposed to accurately represent the control environment. Discrepancies indicate either that the SoA is aspirational rather than factual, or that controls have drifted since the SoA was last updated.

How to avoid it: Validate the SoA against actual implementation before audits. Conduct an internal review where someone (not the control owner) verifies that each “Implemented” control is actually operating as described.

Building a Practical SoA: Format and Structure

Spreadsheet Format

The most common format is a spreadsheet with the following columns:

Column	Content
Control Reference	A.5.1 through A.8.34
Control Title	Full control name from Annex A
Applicable?	Yes / No
Justification	Reason for inclusion or exclusion
Risk Reference(s)	Risk IDs from the risk register
Implementation Status	Implemented / Partially / Planned / Not Started
Implementation Details	How the control is implemented (brief)
Evidence Reference	Where to find evidence of implementation
Owner	Named individual responsible
Last Reviewed	Date of last review
Notes	Additional context for auditors

Organizing by Theme

Organize the SoA following the Annex A structure: A.5 Organizational, A.6 People, A.7 Physical, A.8 Technological. Within each theme, list controls in numerical order. This makes it easy for auditors to navigate and cross-reference with the standard.

Level of Detail

Strike a balance between thoroughness and maintainability. The justification should be specific enough to demonstrate risk-driven decision-making but concise enough that the document remains usable. A one-line justification per control is usually too brief. A full paragraph per control is usually sufficient. A page per control is excessive and will make the document unmaintainable.

Example SoA Entries

Included control with risk justification:

Field	Content
Reference	A.8.5
Title	Secure authentication
Applicable	Yes
Justification	Addresses RISK-2026-003 (credential compromise leading to unauthorized access) and RISK-2026-015 (phishing-based account takeover). Also a contractual requirement in enterprise customer DPAs.
Risk Ref	RISK-2026-003, RISK-2026-015
Status	Implemented
Implementation	MFA via Okta for all internal systems. SSO integration with AWS, GitHub, Datadog. Hardware security keys for production access. Session timeout: 12 hours.
Evidence	Okta MFA enrollment report, SSO configuration screenshots, hardware key inventory
Owner	Sarah Chen, Head of IT
Reviewed	2026-02-15

Excluded control with justification:

Field	Content
Reference	A.7.12
Title	Cabling security
Applicable	No
Justification	The organization operates no physical data center, server room, or network infrastructure beyond standard office equipment. All production infrastructure is hosted in AWS (eu-west-1, eu-central-1), where physical cabling security is managed by AWS under their SOC 2 Type II certification. Office networking uses wireless connectivity for employee devices with no sensitive data processed on-premises.
Risk Ref	N/A
Status	N/A
Implementation	N/A
Evidence	N/A
Owner	N/A
Reviewed	2026-02-15

SoA for SaaS Companies: Practical Considerations

Cloud Shared Responsibility Model

Many SaaS companies struggle with how to handle controls that fall under the cloud provider’s shared responsibility model. The key principle: you cannot exclude a control simply because your cloud provider handles part of it. You can reference the cloud provider’s controls as part of your implementation, but the control is still applicable to your organization.

Example: A.7.5 (Protecting against physical and environmental threats) is primarily handled by AWS for production infrastructure. But the control is not excluded — it is included with the justification: “For production infrastructure, physical and environmental protection is provided by AWS, verified through annual review of AWS SOC 2 Type II report (A.5.22). For office premises, fire detection and suppression systems are maintained by the building landlord, verified through annual lease review.”

Multi-Framework Alignment

If your SaaS company is also pursuing SOC 2, aligning your SoA with SOC 2 Trust Service Criteria can reduce duplication. Many Annex A controls map directly to SOC 2 Common Criteria. Your SoA can note these mappings to demonstrate a unified control framework.

Scaling the SoA with Growth

As your SaaS company grows, your SoA will evolve:

• Early stage (< 50 employees): More controls may be “Planned” or “Partially implemented.” Focus on getting the structure right and building toward full implementation.
• Growth stage (50-200 employees): Most controls should be implemented. Begin formalizing processes that were previously handled informally. Add controls for supplier management as your vendor ecosystem grows.
• Scale stage (200+ employees): Full implementation expected. Focus on evidence collection, continuous monitoring, and control effectiveness measurement. Consider adding controls beyond Annex A for advanced threats.

SoA and Internal Audit

Your internal audit program uses the SoA as the basis for audit planning. The internal auditor verifies that:

• Every included control is implemented as described
• Exclusion justifications remain valid
• Implementation status is accurate
• Evidence supports the claims in the SoA
• The SoA reflects current risks and controls

Internal audit findings should feed back into SoA updates, creating a continuous improvement loop.

How GRCTrail Helps

GRCTrail provides SaaS teams with a structured, auditor-ready approach to creating and maintaining the Statement of Applicability.

• Automated SoA generation that maps your risk assessment results to all 93 Annex A controls, pre-populating justifications based on your identified risks and treatment decisions so you start from a risk-driven document rather than a blank spreadsheet
• Control implementation tracking with evidence linking, so each SoA entry connects to implementation details, assigned owners, and supporting evidence — giving auditors the traceability they look for without manual cross-referencing
• Living document management with version control, change tracking, and automated review reminders that keep your SoA current between audits rather than letting it become a stale certification artifact

Get started with GRCTrail →

Related Guides

• What Is ISO 27001? A Guide for SaaS Companies
• ISO 27001 Risk Assessment: Process, Methodology, and Examples
• ISO 27001 Annex A Controls: Complete Guide to All 93 Controls
• ISO 27001 Certification Checklist
• ISO 27001 Internal Audit Guide
• ISO 27001 Requirements: Understanding Clauses 4-10