ISO Digital Solutions Get the ISMS Framework

SGRII Insights  ·  ISO 27001:2022  ·  2026

Your Statement of Applicability Was Built from Annex A. It Should Have Been Built from Your Risk Register. Here Is the Correct Construction Sequence.

The SoA is the most audited document in a Stage 2 assessment. It is also the document most commonly produced in reverse — starting from controls and working backward to justifications. This is the methodology that builds it correctly.

The Correct Construction Sequence

There is one correct sequence for SoA construction under ISO/IEC 27001:2022. It is not debatable. It is not a matter of implementation style. It is a structural requirement that follows from Clause 6.1.3, which requires the organisation to determine controls necessary to implement the risk treatment options, compare them with Annex A, and produce a Statement of Applicability.

The sequence: Information assets → Threat and vulnerability identification → Risk assessment (CIA-framed) → Risk treatment decisions → Control selection → Statement of Applicability. Each step produces the input for the next. Skip a step, and the output of every subsequent step is unjustified.

The inversion — listing all 93 Annex A controls, marking most as applicable, and writing justification text afterward — is not SoA construction. It is control-list adoption with retrospective rationalisation. The SoA exists. The risk-driven process that should have produced it does not. And a Stage 2 auditor conducting the bidirectional traceability test will find this in the first twenty minutes.

Step 1: The Information Asset Foundation

Risk assessment without an information asset inventory is risk identification by imagination. You are guessing what assets exist, where they are processed, who has access, and what their confidentiality, integrity, and availability requirements are. The guesses may be accurate. They cannot be demonstrated to be systematic.

The asset register should capture: asset name, asset type (data, system, infrastructure, people, process), asset owner, location (physical and logical), classification level, CIA impact rating, and the processes that depend on it. This is not a comprehensive IT asset management exercise. It is a targeted identification of information assets whose compromise would affect the organisation’s information security objectives.

Every risk scenario in the subsequent assessment should reference a specific asset or asset category. ‘Risk of unauthorised access to customer data’ is a risk statement. ‘Risk of unauthorised access to customer PII stored in the CRM platform (Asset A-012) via compromised administrator credentials (Threat T-003, Vulnerability V-007)’ is an assessable risk scenario. The SoA justifications that flow from the second are specific. The justifications that flow from the first are generic.

Step 2: Threat and Vulnerability Identification

Threats are external agents or events that could exploit vulnerabilities. Vulnerabilities are weaknesses in assets, processes, or controls that threats could exploit. The identification should be systematic — not brainstormed in a workshop and never revisited.

Threat categories for ISO 27001 risk assessment typically include: deliberate human threats (external attackers, malicious insiders, social engineering), accidental human threats (misconfiguration, data handling errors, improper disposal), environmental threats (power failure, flooding, fire), and technical threats (system failure, software bugs, capacity exhaustion). Each threat category maps to specific Annex A control themes.

Vulnerability identification should reference the information asset register: which assets have known weaknesses? Which processes lack controls? Which access points are inadequately protected? A vulnerability without a corresponding asset is academic. A vulnerability attached to a critical information asset with high CIA impact is a risk that demands treatment.

Step 3: CIA-Framed Risk Assessment

ISO 27001 risk assessment must consider impacts across the confidentiality, integrity, and availability triad. A risk that threatens only availability requires different controls from one that threatens confidentiality. A single threat scenario may produce three separate risk ratings — one per CIA dimension — that justify different control selections.

The SGRII methodology structures risk assessment at the intersection of asset, threat, and vulnerability — producing scenarios that are specific enough to drive traceable control selection. Each scenario receives a likelihood rating and a CIA-differentiated impact rating. The product determines risk significance. Risk significance determines treatment priority. Treatment priority determines control selection. Control selection populates the SoA.

A risk assessment that does not differentiate CIA impacts will produce generic control selections. An assessment that cannot trace from risk scenario to control selection will produce an SoA that fails the bidirectional traceability test.

Step 4: Control Selection and SoA Population

For each risk that exceeds the risk appetite threshold, the organisation selects controls from Annex A (or identifies additional controls not in Annex A) that treat the risk to an acceptable residual level. The SoA records this selection.

Each SoA entry requires: control reference (A.x.x), applicability status (applicable/not applicable), justification for inclusion or exclusion, implementation status, and — critically — the risk reference(s) that drove the selection. This last field is where bidirectional traceability lives. Without it, the SoA is a list. With it, the SoA is a risk treatment output.

Exclusions require equal rigour. ‘Not applicable — the organisation does not perform this activity’ is insufficient unless the organisation has verified that the activity does not occur within its operations, outsourced services, or supply chain. Every exclusion must survive the auditor’s question: how do you know this does not apply?

Writing Risk-Driven Justifications

Generic justification: ‘Applicable — to protect the confidentiality and integrity of information assets.’ This applies to the entire standard. It justifies nothing.

Risk-driven justification: ‘Applicable — treats Risk R-017 (unauthorised access to customer PII via compromised credentials, Asset A-012, Likelihood 4, Confidentiality Impact 5). Selected in conjunction with A.8.5 (Secure authentication) and A.5.15 (Access control) to reduce residual risk to within appetite.’ This justification is specific, traceable, and audit-defensible.

The effort difference is not significant once the risk assessment is properly structured. If the risk assessment produces asset-specific, threat-specific scenarios with CIA impact ratings, the justification text writes itself — because the justification IS the risk scenario. If the risk assessment is generic, the justification will be generic. The SoA quality is a direct reflection of the risk assessment quality.

The SGRII Position

The SGRII ISMS Framework is built so the SoA cannot be completed without a risk register that justifies it. The risk-to-control evidential chain is structural, not optional. The SoA template includes mandatory risk reference fields for every applicable control. The Risk Register includes SoA control reference fields for every treated risk. Bidirectional traceability is enforced by the template architecture — not by implementer discipline.

This is not a design preference. It is what the standard requires. And it is what Stage 2 auditors who conduct the traceability test will find — or will find missing.