Creating a Statement of Applicability (SoA): Selecting and Justifying Controls

TL;DR

The SoA documents all 93 Annex A controls and justifies for each one whether it is applicable or not.
Every excluded control requires a traceable justification that withstands audit scrutiny.
The implementation status (implemented, partially implemented, planned, not applicable) shows the maturity of your ISMS at a glance.
Cross-mappings to NIS2, DSGVO (GDPR), or TISAX save duplicate work and turn the SoA into a central compliance document.
Regular snapshots make progress visible and provide audit evidence over time.

What Is the Statement of Applicability?

The Statement of Applicability, or SoA for short, is one of the most important documents in your ISMS. It lists all security controls from Annex A of ISO 27001 and records for each one whether it is relevant to your organization or not. Anyone pursuing ISO 27001 certification cannot avoid the SoA: the standard explicitly requires it in clause 6.1.3.

But the SoA is far more than a mandatory exercise. It is the bridge between your risk analysis and the concrete measures you implement. While the risk register shows which threats exist — built through a thorough risk assessment — the SoA documents which controls you use to address those threats. This makes it the central management tool for your entire information security program.

For auditors, the SoA is the first document they look at. It shows at a glance how mature your ISMS is, what decisions you have made, and whether those decisions are traceably justified. A well-maintained SoA significantly accelerates every audit, while a patchy one immediately triggers follow-up questions.

Understanding the 93 Annex A Controls

With ISO 27001:2022, Annex A was completely revised. Instead of the previous 114 controls in 14 categories, there are now 93 controls in four clear thematic areas:

Organizational Controls (37): These address policies, roles, responsibilities, and processes. Examples include the information security policy (A.5.1), segregation of duties (A.5.3), or supplier security (A.5.19 to A.5.23). This area applies to every organization, regardless of size or industry.

People Controls (8): Pre-employment screening (A.6.1), awareness and training (A.6.3), security incident reporting processes (A.6.8). These controls are almost always applicable as soon as you employ staff.

Physical Controls (14): Access controls, equipment protection, security zones. This is where applicability decisions first become interesting: a purely cloud-based company without its own data center will assess some physical controls differently than a manufacturing company with a server room.

Technological Controls (34): Access rights, cryptography, network security, secure development, logging. This is the area where the IT department faces the greatest demands and where technical debt shows most clearly.

Each of these 93 controls has a detailed description with implementation guidance in ISO 27002:2022. While ISO 27002 is not certification-relevant, it provides you with the understanding needed to make informed applicability decisions.

Deciding Control by Control: Applicable or Not

The core of SoA creation is the systematic assessment of each individual control. For each of the 93 Annex A controls, you make a binary decision: applicable or not applicable. What sounds simple requires careful consideration and clean documentation in practice.

When Is a Control Applicable?

A control is applicable when at least one of the following conditions is met:

It addresses a risk identified in your risk analysis. This is the most common and strongest reason. If your risk analysis includes the risk "Unauthorized access to customer data by former employees," then control A.5.11 (Return of assets) is directly applicable.

It is required by legal or contractual obligations. The DSGVO (GDPR), for example, requires encryption of personal data, making A.8.24 (Use of cryptography) applicable even if your risk analysis has not explicitly rated this topic as a high risk.

It represents a best practice relevant to your business model. You will find it hard to justify backup processes (A.8.13) as not applicable, even if no specific risk appears in the register.

When Can a Control Be Excluded?

Exclusions are possible, but they need a solid justification. Typical legitimate reasons:

Technological context does not apply. If your organization does not perform in-house software development, you can mark the secure development controls (A.8.25 to A.8.28) as not applicable. The justification is clear and traceable.

No relevant assets present. A.7.3 (Securing offices, rooms, and facilities) may be of limited applicability for a fully remote company without physical office space. But caution: even home office workstations constitute physical assets.

Risk has been addressed otherwise. If a risk is fully covered by another control, you could theoretically exclude the redundant control. In practice, however, it is usually wiser to mark both as applicable and reference the shared implementation.

The Justification Is What Matters

For every excluded control, you must document why it is not applicable. Auditors specifically review these justifications. A good justification is specific, traceable, and refers to the concrete context of your organization.

Weak justification: "Not relevant to our organization."

Strong justification: "A.8.28 (Secure coding) is not applicable because we do not perform in-house software development. All applications in use are procured as SaaS solutions. The security of our providers' development processes is ensured through A.5.21 (Information security in the ICT supply chain) and contractual SLAs."

Note the difference: the strong justification explains not only the why, but also references how the underlying risk is still addressed. That is exactly what auditors expect.

Documenting Implementation Status

For every applicable control, you document how far the implementation has progressed. The four standard levels are:

Fully implemented: The control is in place, actively practiced, and there is evidence to prove it. Example: A password policy exists, is technically enforced through minimum length requirements in Active Directory, and employees have been trained.

Partially implemented: The measure exists but has gaps. Example: Access rights are assigned, but there is no regular recertification process. Or: Backups are created but have never been verified through a restore test.

Planned: The control has been identified as a measure, but implementation has not yet begun. A specific target date is required here. "Planned" without a timeframe looks like an excuse in an audit.

Not applicable: The control has been deliberately excluded, with a documented justification (see above).

Honestly Assessing Maturity

The biggest trap in status documentation is overestimation. Many organizations rate controls as "fully implemented" that are at best "partially implemented" on closer inspection. A control is only fully implemented when three conditions are met:

The measure is defined and documented. There is a policy, a work instruction, or a technical configuration that demonstrably exists.

The measure is operationally practiced. It exists not only on paper but is actually applied in day-to-day operations. Employees know about it and act accordingly.

Effectiveness is verified. There is some form of monitoring whether the measure fulfills its purpose. This can be a regular review, technical monitoring, or an internal audit.

If any of these three conditions is missing, the status is "partially implemented." This is not a problem and is perfectly normal, especially during the initial ISMS build-up. It only becomes problematic if you embellish the status and the auditor discovers the gap.

Supplementary Information per Control

In addition to the pure status, it is worthwhile to document further information in the SoA:

Responsible person: Who is responsible for the implementation and ongoing operation of this control? This creates accountability and simplifies communication during audits.

Evidence document: Where can the proof of implementation be found? References to policies, configurations, screenshots, or test reports.

Measure ID: If you maintain a measures register, link each control to the associated measures. This creates end-to-end traceability from risk through control to the concrete measure.

Target date: For partially implemented or planned controls, the date by which full implementation should be achieved.

In ISMS Lite, all 93 controls come pre-structured with justification fields, responsibilities, and cross-mappings, so you don't have to build the SoA from scratch in Excel.

Cross-Mappings: One Control, Many Frameworks

The SoA unfolds its full value when you don't view it in isolation for ISO 27001 but use it as a central compliance document. Many Annex A controls simultaneously satisfy requirements from other regulatory frameworks. Explicitly documenting these connections saves enormous amounts of duplicate work.

Typical Mappings

ISO 27001 to NIS2: The NIS2 directive requires, among other things, risk management, incident response, business continuity, and supply chain security. All of this is already found in the Annex A controls. When you implement A.5.24 (Information security incident management planning and preparation), you simultaneously fulfill the NIS2 requirement for incident management.

ISO 27001 to GDPR: Technical and organizational measures (TOMs) under Art. 32 GDPR can be mapped directly to Annex A controls. A.8.24 (Cryptography) corresponds to the GDPR encryption requirement, A.5.12 (Classification of information) supports GDPR-compliant data classification.

ISO 27001 to TISAX: For automotive suppliers that need to demonstrate TISAX conformity, the SoA provides an excellent foundation. Many TISAX requirements have direct equivalents in Annex A, supplemented by industry-specific additional requirements for prototype protection.

ISO 27001 to BSI IT-Grundschutz: The building blocks of the IT-Grundschutz Compendium can also be mapped to Annex A controls. This is particularly relevant if you work in the public sector or have clients that require IT-Grundschutz.

Why Cross-Mappings Pay Off

The obvious advantage: you avoid duplication of effort. Once you have cleanly documented that your backup process covers A.8.13 (Information backup), the NIS2 business continuity requirement, and Art. 32 GDPR, you don't have to start from scratch for the next compliance review.

The less obvious advantage: cross-mappings reveal gaps. If a NIS2 requirement cannot be mapped to any Annex A control, either you have overlooked a control or there is a requirement that goes beyond Annex A and needs to be addressed separately.

In practice, an additional column or field per control where you list the associated framework references is recommended. For example: "A.8.13 → ISO 27001 Annex A, NIS2 Art. 21(2)(c), GDPR Art. 32(1)(c)."

Snapshots: Freezing the Current State

Your SoA is a living document. Controls are implemented, risks change, new requirements emerge. That is precisely why it is important to regularly freeze the current state as a snapshot.

Why Snapshots Matter

Progress measurement: When you compare the snapshot from six months ago with today's state, you can immediately see how many controls have moved from "planned" to "implemented." This is not only motivating but also provides management with measurable KPIs for information security.

Audit evidence: Certification audits take place at a specific point in time. The snapshot shows the status at exactly that point. During surveillance audits in subsequent years, the auditor will want to compare the progression. Without snapshots, this historical dimension is missing.

Regulatory requirements: Both ISO 27001 and NIS2 require the regular review and updating of security measures. Snapshots document that this review is taking place.

Change evidence: When a control changes its status — for example because a new threat appears and a previously excluded control now becomes relevant — the snapshot history shows this deliberate decision. This is invaluable in an audit.

Recommended Cadence

Create snapshots at least in these situations:

Before every certification audit or surveillance audit. This is the minimum standard every auditor expects.

After completing a major implementation project. For example, if you have overhauled the entire access rights management, capture the new state.

Quarterly as a regular cadence. This is the most pragmatic solution and provides regular data points for trend analysis.

After significant organizational changes. A merger, a new business unit, or the introduction of a new technology platform can change the applicability of multiple controls.

Practical Example: SoA Excerpt for a 100-Employee Company

Let's take a mid-market IT services company with 100 employees as an example. The company does not develop its own software, does not operate its own data centers, and works in a hybrid mode (office plus home office). The infrastructure runs predominantly in the cloud (Microsoft 365, Azure). Here is an excerpt from the SoA:

Organizational Controls (Excerpt)

A.5.1 Policies for information security Status: Fully implemented. Justification: A central information security policy is in place, approved by the managing director, and accessible to all employees. Annual review is scheduled. Cross-mapping: NIS2 Art. 21(2)(a), GDPR Art. 24.

A.5.3 Segregation of duties Status: Partially implemented. Justification: Critical functions (e.g., accounting/approval) are separated. For IT administrators, there is still a need to improve separation of admin and user accounts. Measure planned by Q3 2026.

A.5.23 Information security for use of cloud services Status: Partially implemented. Justification: Contractual information security clauses are included in the most important cloud contracts. A systematic cloud security review process for new services is still missing. Implementation planned by Q2 2026. Cross-mapping: NIS2 Art. 21(2)(d).

People Controls (Excerpt)

A.6.1 Screening Status: Fully implemented. Justification: Reference checks and qualification verifications are conducted for all new hires before employment begins. The process is documented in the onboarding checklist.

A.6.3 Information security awareness, education and training Status: Partially implemented. Justification: Annual online training for all employees has been introduced. Role-specific training for IT admins and managers is still in planning (target: Q4 2026). Cross-mapping: NIS2 Art. 21(2)(g).

Physical Controls (Excerpt)

A.7.1 Physical security perimeters Status: Fully implemented. Justification: Office building with access control system (key card), reception area with visitor registration. Server room separately secured.

A.7.4 Physical security monitoring Status: Not applicable. Justification: No in-house video surveillance. The office building is equipped with camera surveillance in the entrance area by the landlord. Responsibility lies with building management; contractual agreements for security monitoring are covered in the lease.

Technological Controls (Excerpt)

A.8.1 User endpoint devices Status: Fully implemented. Justification: All laptops with disk encryption (BitLocker), MDM solution (Intune) for policy enforcement, automatic updates. Bring-Your-Own-Device is not permitted. Cross-mapping: GDPR Art. 32(1)(a).

A.8.9 Configuration management Status: Planned. Justification: No systematic configuration management currently in place. The introduction of a configuration management process including baseline documentation for servers and network devices is scheduled as a project for Q2 to Q3 2026.

A.8.25 Secure development lifecycle Status: Not applicable. Justification: The company does not perform in-house software development. All business applications are procured as SaaS solutions or deployed as standard software. The security of suppliers' development processes is ensured through A.5.21 (Information security in the ICT supply chain) and contractual agreements.

A.8.28 Secure coding Status: Not applicable. Justification: No internal software development (see A.8.25). For configurations and scripts, internal secure configuration guidelines apply under A.8.9.

This example illustrates several important patterns: Most controls are applicable, even if not all are fully implemented. Exclusions primarily concern areas that do not fit the business model (no in-house software development). And for every exclusion, an explanation is provided of how the underlying risk is addressed otherwise.

Common Mistakes When Creating the SoA

To conclude, here are the most common mistakes you should avoid:

Too many exclusions without substance. If more than 15 to 20 of the 93 controls are marked as not applicable, every auditor will ask critical questions. Most controls are relevant for most organizations.

Copy-paste justifications. Every exclusion needs an individual justification that fits the specific context of your organization. Generic texts like "Not relevant" or "Not needed" are insufficient.

Missing connection to the risk analysis. The SoA does not exist in a vacuum. Every applicable control should be traceable back to one or more risks in your risk register. Without this connection, the auditor lacks the logic behind your decisions.

One-time creation without maintenance. The SoA is not a document you create once and then let gather dust. At least annually — for example as part of the internal audit — and preferably quarterly, you should review and update it as needed.

Embellishing implementation status. "Partially implemented" is not a blemish but a sign of honesty and maturity. Auditors quickly recognize when the documented status does not match reality. This damages trust in the entire ISMS.

Thinking of the SoA only as a spreadsheet. A spreadsheet is a good start, but the SoA only becomes valuable when it is linked with the risk register, the action plan, and compliance requirements. Isolated Excel spreadsheets without cross-references are hard to maintain and quickly become outdated.

The Path to a Finished SoA

Creating the SoA is not rocket science, but it requires diligence, contextual knowledge, and a willingness to document every decision properly. Start with the complete list of all 93 controls, work through them systematically, and take sufficient time for the justifications. Involve subject-matter departments, because whether a control is applicable often cannot be determined from a desk alone.

Remember: the SoA is a living document. It will evolve alongside your ISMS, and that is precisely where its value lies. Each snapshot documents the maturity of your information security at a specific point in time. Over time, this creates a traceable history of your security development that convinces auditors, management reviews, and regulatory examinations alike.