Understand what a Statement of Applicability is, how it is created, and how it connects your ISO 27001 risk assessment to the controls implemented by your organization.
The Statement of Applicability (SoA) is one of the most important documents in an ISO 27001 Information Security Management System (ISMS).
It explains which information security controls the organization has determined are applicable, why they are applicable or not applicable, and the implementation status of those controls.
For a startup, the SoA should not be treated as a simple checklist of ISO 27001 controls.
It should tell a logical story:
What are our risks? → How are we treating those risks? → Which controls are relevant? → How are those controls implemented?
1. What Is a Statement of Applicability?
The Statement of Applicability is a documented statement describing the organization’s decisions regarding the applicable information security controls.
It normally includes:
- The controls the organization has determined are necessary
- Justification for including controls
- Whether the necessary controls are implemented
- Justification for excluding controls from Annex A where applicable
The SoA therefore provides a bridge between the organization’s risk treatment process and its information security controls.
2. Why Is the SoA Important?
The SoA helps answer a fundamental question:
Why has this organization selected these security controls?
For example, an AWS SaaS company may identify:
Risk:
Unauthorized access to production AWS resources.
The organization may decide to implement controls relating to:
- Identity management
- Authentication
- Access rights
- Privileged access
- Logging
- Monitoring
- Cloud service security
The SoA records those decisions and provides a structured view of the organization’s control environment.
3. SoA Is Not “Implement Every Annex A Control”
One of the most common misunderstandings about ISO 27001 is:
“There are 93 Annex A controls, so we have to implement all of them.”
That is not the right way to approach the SoA.
ISO 27001 uses a risk-based approach.
The organization determines its applicable controls based on factors such as:
- Risk assessment results
- Risk treatment decisions
- Business requirements
- Legal and regulatory requirements
- Contractual requirements
- Customer requirements
- Organizational context
- Information security objectives
Annex A provides a reference set of controls that organizations should consider as part of their risk treatment process.
4. SoA and Risk Assessment
The relationship can be represented as:
Business Context
↓
Information Security Risks
↓
Risk Assessment
↓
Risk Treatment
↓
Control Selection
↓
Statement of Applicability
↓
Control Implementation
↓
Evidence & Monitoring
Therefore, the SoA should not exist independently from the risk assessment.
The risk assessment provides the business justification for many of the control decisions.
5. Example – AWS SaaS Startup
Consider the same example startup:
ABC SaaS Pvt. Ltd.
The company operates a B2B SaaS platform hosted on AWS.
Its environment includes:
- AWS
- Amazon RDS
- Amazon S3
- IAM
- CloudTrail
- CloudWatch
- GitHub
- Employee laptops
- Customer data
- SaaS application
- Third-party suppliers
The company performs an information security risk assessment.
One identified risk is:
Unauthorized access to AWS production resources.
Initial risk:
20 – Critical
Risk treatment:
Reduce
The startup decides to implement:
- MFA
- Least privilege
- Access reviews
- Privileged access controls
- Logging
- Monitoring
The SoA then documents the relevant control decisions.
6. Example SoA
A practical SoA can contain columns such as:
| Control | Applicable? | Justification | Implementation Status | Evidence |
|---|---|---|---|---|
| Information security policies | Yes | Required to establish security direction | Implemented | IS Policy |
| Roles and responsibilities | Yes | Security responsibilities must be defined | Implemented | RACI |
| Threat intelligence | Yes | Relevant cyber threats affect SaaS environment | Implemented | Threat reports |
| Information security awareness | Yes | Employees handle sensitive information | Implemented | Training records |
| Access control | Yes | Required to protect systems and data | Implemented | IAM policy |
| Identity management | Yes | Users require controlled identities | Implemented | IAM records |
| Authentication information | Yes | Authentication protects systems | Implemented | MFA configuration |
| Access rights | Yes | Access must follow business requirements | Implemented | Access review |
| Privileged access rights | Yes | Administrators can affect production | Implemented | Privileged access review |
| Information deletion | Yes | Customer and company information must be securely deleted | Partially implemented | Deletion procedure |
| Backup information | Yes | Customer data requires recovery capability | Implemented | AWS Backup |
| Logging | Yes | Security and operational activity must be monitored | Implemented | CloudTrail |
| Monitoring activities | Yes | Suspicious activity needs detection | Implemented | CloudWatch |
| Security of network services | Yes | SaaS application relies on network connectivity | Implemented | Network architecture |
| Secure coding | Yes | Company develops its own SaaS application | Implemented | SDLC |
| Supplier security | Yes | AWS and other suppliers support critical services | Implemented | Supplier assessments |
| Cloud services security | Yes | Core production environment is hosted on AWS | Implemented | AWS security configuration |
The exact control references should be maintained against the applicable edition of ISO/IEC 27001 being used for the certification.
7. What Should an SoA Contain?
A useful SoA normally contains at least four important pieces of information for each control.
1. Control
Which control is being considered?
2. Applicability
Has the organization determined that the control is applicable?
3. Justification
Why is the control applicable?
If a control is not applicable, why has the organization determined that it is not necessary?
4. Implementation status
Has the control been implemented?
For a more useful operational SoA, organizations may also include:
- Risk reference
- Risk treatment reference
- Control owner
- Implementation details
- Evidence location
- Related policy
- Review date
- Implementation status
8. Applicability Decision
The organization should make a deliberate decision for each relevant Annex A control.
For example:
Control
Access control.
Decision
Applicable – Yes
Reason
The organization processes customer information and operates cloud infrastructure requiring controlled access.
Status
Implemented
Evidence
- IAM configuration
- Access control policy
- Quarterly access review
9. Example of a Control Exclusion
Suppose the startup has no physical data center and all infrastructure is hosted through cloud service providers.
The organization evaluates a physical security control.
It may determine that a particular control is not necessary within the organization’s defined ISMS scope because the relevant physical infrastructure is operated by its cloud provider and the organization’s treatment of that risk is addressed through its supplier and cloud-service controls.
The important point is:
The organization should document the actual reason for its decision.
Do not simply write:
“Not applicable.”
A useful justification explains the organization’s context and how the relevant risk is addressed.
10. Applicability Does Not Mean Implementation
This distinction is important.
A control can be:
Applicable = Yes
while:
Implementation = Not yet complete
For example:
| Control | Applicable | Implementation |
|---|---|---|
| Access review | Yes | Implemented |
| Secure development | Yes | Partially implemented |
| Supplier security | Yes | In progress |
This allows the SoA to reflect the organization’s actual ISMS maturity.
An organization should not falsely mark a control as implemented simply because a policy has been written.
11. Policy vs Control Implementation
Consider:
Control
Access rights should be managed appropriately.
The startup creates:
Access Control Policy
But that alone does not prove that the control is operating.
The organization may also need evidence such as:
- User access list
- IAM roles
- Access approval records
- Periodic access reviews
- Termination records
- Privileged account reviews
Therefore:
Policy = documented requirement
Control implementation = requirement operating in practice
12. SoA Example – AWS Access Management
Let’s follow one risk through the entire process.
Risk
Compromised AWS administrator credentials.
Initial Risk
20 – Critical
Treatment
Reduce.
Treatment actions
- Enforce MFA
- Apply least privilege
- Remove unnecessary administrator access
- Perform access reviews
- Monitor privileged activity
Relevant controls
Controls relating to:
- Identity management
- Authentication
- Access rights
- Privileged access
- Logging
- Monitoring
SoA
The SoA records these controls as applicable.
Evidence
- IAM configuration
- MFA configuration
- Access review records
- CloudTrail logs
- Monitoring alerts
Residual Risk
10 – High
Management decision
Residual risk reviewed and accepted according to the organization’s defined criteria.
This is a complete risk-to-control chain.
13. SoA and Risk Register Should Be Connected
A mature ISMS should allow an auditor or management to trace:
Risk Register
↓
Risk Treatment Plan
↓
SoA
↓
Control
↓
Evidence
For example:
| Risk ID | Risk | Treatment | SoA Control | Evidence |
|---|---|---|---|---|
| R-001 | AWS unauthorized access | Reduce | Access / identity controls | IAM + MFA |
| R-002 | S3 data exposure | Reduce | Access / cloud controls | S3 configuration |
| R-003 | Database loss | Reduce | Backup controls | AWS Backup |
| R-004 | Application vulnerability | Reduce | Secure development controls | VAPT + SDLC |
| R-005 | Supplier compromise | Reduce | Supplier security controls | Vendor assessment |
This creates traceability.
14. What If a Control Comes From a Legal Requirement?
Not every control decision will necessarily originate only from the risk register.
Controls may also be driven by:
- Laws
- Regulations
- Contracts
- Customer requirements
- Industry obligations
- Internal security requirements
For example, a startup may have contractual requirements from an enterprise customer requiring specific security measures.
Those requirements should be considered within the organization’s ISMS and control-selection process.
15. What If a Control Is Not in Annex A?
An organization may identify additional controls outside Annex A.
For example:
- Specific AWS security configurations
- Custom monitoring
- Organization-specific security procedures
- Customer-specific contractual controls
- Internal technical safeguards
The SoA should focus on the applicable ISO 27001 control set, while the organization’s broader control framework can include additional controls where necessary.
16. SoA for a Startup
A startup should avoid creating an unnecessarily complicated SoA.
A practical structure might be:
| Control | Applicable? | Justification | Status | Owner | Evidence |
|---|---|---|---|---|---|
| Access control | Yes | Protect SaaS environment | Implemented | CTO | IAM |
| Authentication | Yes | Protect user identities | Implemented | IT | MFA |
| Backup | Yes | Protect customer data | Implemented | DevOps | AWS Backup |
| Logging | Yes | Detect security events | Implemented | Security | CloudTrail |
| Secure development | Yes | Company develops SaaS | In Progress | Engineering | SDLC |
| Supplier security | Yes | Uses AWS and SaaS suppliers | Implemented | Procurement | Vendor reviews |
This is often more useful than a spreadsheet containing hundreds of disconnected fields.
17. Common SoA Mistakes
Mistake 1 – Treating the SoA as a checklist
The SoA should demonstrate reasoned control decisions.
Mistake 2 – Marking everything “Applicable”
A blanket decision does not demonstrate a meaningful risk-based assessment.
Mistake 3 – Marking everything “Implemented”
Implementation must be supported by evidence.
Mistake 4 – Copying another company’s SoA
A SaaS startup, bank, hospital, and manufacturing company will have different risks and requirements.
Mistake 5 – Disconnecting the SoA from the risk assessment
The organization should be able to explain why controls were selected.
Mistake 6 – Using generic justifications
For example:
“Required for security.”
This provides very little useful information.
A stronger justification is:
“Applicable because the organization operates production AWS infrastructure and processes customer information requiring controlled access.”
Mistake 7 – Forgetting changes
The SoA should be maintained as the organization’s risks, technology, scope, and controls change.
18. What an Auditor May Ask
During an ISO 27001 audit, an auditor may ask:
“Why is this control applicable?”
The organization should be able to explain the reason.
“What risk does this control address?”
The organization should be able to trace the control to relevant risks or other requirements.
“How is this control implemented?”
The organization should demonstrate actual implementation.
“Show me the evidence.”
The organization should provide appropriate records or technical evidence.
“Why is this control not applicable?”
The organization should have a documented and defensible justification.
“Who owns this control?”
The organization should know who is responsible for maintaining it.
19. SoA Maintenance
The SoA should not be created once and forgotten.
Review it when there are significant changes such as:
- New AWS architecture
- New applications
- New customers
- New regulatory requirements
- New suppliers
- Major security incidents
- Business expansion
- New processing activities
- Significant changes to the ISMS scope
- Changes in risk assessment results
The SoA should remain aligned with the organization’s current ISMS.
20. Simple SoA Lifecycle
A practical lifecycle is:
Understand Organization
↓
Define ISMS Scope
↓
Identify Risks
↓
Assess Risks
↓
Treat Risks
↓
Determine Applicable Controls
↓
Prepare SoA
↓
Implement Controls
↓
Collect Evidence
↓
Monitor & Review
↓
Update Risk Assessment / SoA
21. Risk Assessment vs SoA
These two documents have different purposes.
| Risk Assessment | Statement of Applicability |
|---|---|
| Identifies and evaluates risks | Documents control applicability decisions |
| Focuses on what could go wrong | Focuses on how the organization addresses information security requirements |
| Produces risk ratings | Produces control decisions |
| Identifies risk treatment | Records applicable controls |
| Has risk owners | Can have control owners |
| Produces residual risk | Records implementation status |
| Business-risk focused | Control-framework focused |
They should work together.
22. The Complete AWS SaaS Example
For our fictional startup:
Risk
R-001 – Unauthorized AWS access
Initial risk:
20 – Critical
↓
Treatment
Reduce
↓
Controls
- Identity management
- Authentication
- Access rights
- Privileged access
- Logging
- Monitoring
↓
SoA
Controls marked:
Applicable – Yes
↓
Implementation
- MFA
- IAM roles
- Least privilege
- Access reviews
- CloudTrail
- CloudWatch
↓
Evidence
- IAM configuration
- MFA reports
- Access review records
- CloudTrail configuration
- Monitoring records
↓
Residual Risk
10 – High
↓
Management
Residual risk reviewed according to the organization’s risk acceptance criteria.
This is the relationship an auditor should be able to understand.
23. The Key Principle
The Statement of Applicability should answer three simple questions:
1. What controls are relevant to us?
Applicability
2. Why are they relevant?
Justification
3. Have we implemented them?
Implementation status and evidence
The SoA therefore becomes the control map of the organization’s ISMS.
It connects business risks and requirements with the security controls that the organization has chosen to implement.
Quick Summary for Startups
For an AWS SaaS startup:
Risk Assessment
“Our AWS production environment could be compromised.”
↓
Risk Treatment
“We will reduce the risk.”
↓
Control Selection
“We need appropriate identity, authentication, access, privileged access, logging and monitoring controls.”
↓
Statement of Applicability
“These controls are applicable because they address our identified risks and information security requirements.”
↓
Implementation
“MFA, IAM least privilege, access reviews, CloudTrail and monitoring are implemented.”
↓
Evidence
“Here is the technical and documentary evidence.”
↓
Residual Risk
“The remaining risk has been assessed and addressed according to our risk criteria.”
That is the practical purpose of an ISO 27001 Statement of Applicability.
How to Prepare an ISO 27001 Statement of Applicability — AWS SaaS Startup Example