ISO 27001 Statement of Applicability (SoA): Complete Guide

Key Takeaways

Point	Summary
What it is	Document listing all 93 Annex A controls with applicability status and justification
Required by	Clause 6.1.3 d) - mandatory ISMS documentation
Key contents	Control reference, applicable (Yes/No), justification, implementation status
Common exclusions	Rarely excluded: access control, encryption, incident response. Often excluded: physical security (for cloud-native)
Auditor focus	Primary reference document for certification audits

Quick Answer: The Statement of Applicability (SoA) lists all 93 Annex A controls and documents which ones apply to your organization and why. Every control must have a justification for inclusion or exclusion. It's the auditor's primary reference during certification.

What is a Statement of Applicability?

Definition

The Statement of Applicability (SoA) is a documented list of all Annex A controls with:

• Whether each control is applicable or not
• Justification for inclusion or exclusion
• Implementation status

ISO 27001 Requirement

Clause 6.1.3 d) requires you to produce a Statement of Applicability that contains:

• The necessary controls (from risk treatment)
• Justification for inclusions
• Whether controls are implemented or not
• Justification for exclusions of any Annex A controls

Why It Matters

Stakeholder	SoA Value
Auditors	Primary reference for control verification
Management	Overview of security controls
Customers	Understanding of your security measures
Operations	Reference for control implementation

SoA Structure

Essential Components

Statement of Applicability Structure:

Header Information:

• Organization name
• ISMS scope reference
• Version and date
• Approval signatures

Control Information (for each of 93 Annex A controls):

• Control reference (e.g., 5.1)
• Control title
• Applicable? (Yes/No)
• Justification (inclusion or exclusion)
• Implementation status
• Implementation description (optional)
• Evidence location (optional)

Summary:

• Total applicable controls
• Total excluded controls
• Implementation statistics

SoA Template

Control	Title	Applicable	Justification	Status	Description
5.1	Policies for information security	Yes	Required for ISMS governance	Implemented	Security policy approved by CEO
5.2	Information security roles	Yes	Required for accountability	Implemented	Roles defined in ISMS documentation
...	...	...	...	...	...
8.4	Access to source code	No	No software development in scope	N/A	Development excluded from ISMS scope

Creating Your SoA

Step 1: Start with Risk Treatment

Your SoA should reflect your risk treatment decisions:

Risk Treatment to Control Selection to SoA:

Risk: Unauthorized access to customer data

Treatment: Modify (implement controls)

Controls Selected:

• 5.15 Access control
• 5.16 Identity management
• 8.2 Privileged access rights
• 8.5 Secure authentication

SoA: Mark these controls as applicable with risk justification

Step 2: Review All Annex A Controls

Even if not selected through risk treatment, consider all 93 controls:

Control Status	Action Required
Selected via risk treatment	Mark applicable, document risk reference
Required by regulation	Mark applicable, document requirement
Best practice	Consider including, document rationale
Not applicable	Justify exclusion

Step 3: Document Justifications

For Applicable Controls:

Justification Type	Example
Risk-based	"Required to mitigate risk R001 (unauthorized access)"
Regulatory	"Required for GDPR Article 32 compliance"
Contractual	"Required by customer security requirements"
Best practice	"Industry standard for SaaS providers"

For Excluded Controls:

Justification Type	Example
Scope exclusion	"Physical data centers excluded from ISMS scope; cloud-only"
Not applicable	"No source code development; using only third-party software"
Risk-based	"Risk assessed as acceptable without this control"

Step 4: Document Implementation Status

Status	Description
Implemented	Control is fully operational
Partially Implemented	Some aspects implemented
Planned	Implementation scheduled
Not Implemented	Applicable but not yet implemented
N/A	Control excluded

SoA Examples by Control Theme

Theme 5: Organizational Controls

Control	Common Applicability	Typical Justification
5.1 Policies	Yes (always)	Core ISMS requirement
5.7 Threat intelligence	Often yes	Risk-based security decision
5.23 Cloud services	Yes (if using cloud)	Cloud security governance

Sample Entry:
Control: 5.23 Information security for use of cloud services

Applicable: Yes

Justification: Organization uses AWS, GCP, and multiple SaaS applications requiring cloud security governance

Status: Implemented

Description: Cloud security policy established; all cloud services inventoried and assessed; provider certifications reviewed

Theme 6: People Controls

Control	Common Applicability	Typical Justification
6.1 Screening	Yes (usually)	Required for employment security
6.3 Awareness	Yes (always)	Fundamental security requirement
6.7 Remote working	Yes (if remote work)	Increasing relevance

Sample Entry:
Control: 6.1 Screening

Applicable: Yes

Justification: All employees with access to systems and data require background verification to mitigate insider threat risk

Status: Implemented

Description: Background checks conducted for all employees through verified third-party provider before start date

Theme 7: Physical Controls

Control	Common Applicability	Typical Justification
7.1 Physical perimeters	Depends on scope	May be cloud provider responsibility
7.4 Physical monitoring	Depends on scope	Office security vs. data center
7.7 Clear desk	Usually yes	Regardless of physical infrastructure

Sample Exclusion Entry:
Control: 7.1 Physical security perimeters

Applicable: No

Justification: Organization is fully cloud-based with no physical data centers. All infrastructure hosted in AWS which maintains ISO 27001 certification covering physical security (SOC 2 report reference: Section X.X)

Status: N/A

Theme 8: Technological Controls

Control	Common Applicability	Typical Justification
8.1 User endpoints	Yes (almost always)	Endpoint security essential
8.4 Source code access	Only if developing	May exclude if no development
8.28 Secure coding	Only if developing	Exclude if using only third-party

Sample Entry:
Control: 8.24 Use of cryptography

Applicable: Yes

Justification: Required to protect data confidentiality and integrity for customer data (mitigates risks R003, R007)

Status: Implemented

Description:

• Data at rest: AES-256 encryption for all databases and storage
• Data in transit: TLS 1.2+ for all connections
• Key management: AWS KMS with defined key rotation

Common SoA Mistakes

Mistake 1: Excluding Without Justification

Problem: "N/A" without explanation

Solution: Every exclusion needs documented justification

Bad:

Control 8.4 Access to source code: N/A

Good:

Control 8.4 Access to source code: No

Justification: The organization does not develop software internally. All applications are procured SaaS solutions. Development activities are explicitly excluded from ISMS scope (see Scope Document v2.1).

Mistake 2: Generic Justifications

Problem: "Required for security" doesn't explain why

Solution: Link to specific risks or requirements

Bad:

Control 8.5: Yes - Required for security

Good:

Control 8.5: Yes - Required to mitigate credential compromise risk (R001, R004) and meet customer contractual requirements (Contract template Section 7.3)

Mistake 3: Outdated Status

Problem: SoA says "Planned" for implemented controls

Solution: Regular SoA reviews and updates

Mistake 4: Missing Risk Linkage

Problem: Controls selected without clear risk basis

Solution: Reference risk register entries

SoA Maintenance

When to Update

Trigger	Action
Risk assessment update	Review control selection
Scope change	Add/remove controls
New regulatory requirement	Add controls
Audit finding	Update status/description
Annual review	Verify accuracy

Version Control

Version	Date	Changes	Approved By
1.0	2024-01-15	Initial release	CISO
1.1	2024-04-01	Updated status for 8.9, 8.12	CISO
1.2	2024-07-15	Added 5.23 details for new cloud services	CISO

SoA for Auditors

What Auditors Check

Audit Focus	Evidence Needed
All controls addressed	93 controls documented
Justifications present	Inclusion and exclusion reasons
Risk alignment	Link to risk treatment
Status accuracy	Implementation matches reality
Regular review	Evidence of updates

Common Audit Findings

Finding	Prevention
Missing controls	Use complete Annex A checklist
Weak justifications	Link to specific risks/requirements
Status mismatch	Regular accuracy verification
No version control	Implement document control
Unsigned	Ensure formal approval

SoA Summary Statistics

Your SoA should include summary information:

Statement of Applicability Summary:

Total Annex A Controls: 93

Applicable Controls: 85 (91%)

• Implemented: 78 (92% of applicable)
• Partially Implemented: 5 (6%)
• Planned: 2 (2%)

Excluded Controls: 8 (9%)

By Theme:

• Theme 5 (Organizational): 35/37 applicable (95%)
• Theme 6 (People): 8/8 applicable (100%)
• Theme 7 (Physical): 8/14 applicable (57%)
• Theme 8 (Technological): 34/34 applicable (100%)

The Bastion Approach

Streamlined SoA Creation

Bastion simplifies SoA development:

Challenge	Bastion Solution
93 controls to evaluate	Pre-assessed templates by industry
Writing justifications	AI-assisted justification drafting
Linking to risks	Automatic risk-control mapping
Maintaining accuracy	Continuous status monitoring
Version control	Built-in document management

Expert Review

Your vCISO ensures:

• Appropriate control selection
• Defensible justifications
• Accurate implementation status
• Audit-ready documentation

---

Need help creating your Statement of Applicability? Talk to our team →