SGRII Insights  ·  ISO 27001:2022  ·  2026

Your Statement of Applicability Listed Controls. Your Risk Register Should Have Selected Them. For Most Certified Systems, That Process Ran in Reverse.

The SoA is the most audited document in a Stage 2 assessment and the one most commonly produced backwards. Understanding why — and what a correctly constructed SoA actually requires — is the difference between certification and genuine information security risk management.

Take the Statement of Applicability out of a typical ISO 27001:2022 implementation. Count the controls marked as applicable. In most cases: all ninety-three, or ninety-one, or eighty-eight — with a small number of exclusions justified by short phrases like ‘not applicable to our business model’ or ‘addressed at group level.’ Then go to the risk register. Find the information security risk that justifies each applicable control. In most implementations, you cannot. The SoA was built as a checklist. The risk register was built separately. The connection between them was described, not demonstrated.

This is not a documentation problem. It is a system design problem. And it is the most common finding in Stage 2 ISO 27001 audits conducted by technically proficient Lead Auditors.

What Clause 6 Actually Requires

Clause 6.1.2 requires the organisation to apply an information security risk assessment process that identifies risks associated with the loss of confidentiality, integrity, and availability of information. The risk assessment must produce comparable and reproducible results, which the standard requires to be documented. Clause 6.1.3 requires the organisation to determine appropriate risk treatment options, select controls, produce a Statement of Applicability, formulate a risk treatment plan, and obtain risk owner approval of the residual risk.

The SoA is the output of a risk-driven control selection process. It must contain every Annex A control, indicate whether each is applicable, provide justification for inclusions — based on risk assessment outcomes, legal or regulatory requirements, or contractual obligations — and justify exclusions. The standard requires that exclusions do not result in failure to achieve information security objectives. Exclusion without justification is not exclusion — it is omission.

Clause 6.2 requires that information security objectives are established, consistent with the information security policy, measurable where practicable, communicated, and updated as appropriate. Objectives must have associated plans specifying what will be done, what resources are required, who is responsible, when it will be completed, and how results will be evaluated. Not all of these elements are present in most ISMS objective registers.

The Four SoA Construction Failures That Define Most Implementations

All ninety-three controls applicable, no exclusions. This is the most widely recurring SoA pattern. It signals one of two things: either the organisation genuinely has information security risks requiring every Annex A control — which is conceivable but requires a risk register of corresponding depth — or the SoA was completed as a checklist with all boxes marked applicable to avoid the work of exclusion justification. Auditors know which is more likely. When an SoA with no exclusions is accompanied by a risk register that does not justify every control, the SoA is a compliance document, not a risk management output.

Controls without traceable risk register entries. Select any five SoA controls marked applicable. Go to the risk register and find the risk that justifies each one. In most implementations, the link does not exist as a traceable reference — it is implied by the general nature of the control. Implication is not traceability. Annex A.8.8 (Management of Technical Vulnerabilities) is applicable because it is good practice — not because the risk register identifies a specific vulnerability management gap and traces the control selection to that identification. The former is a checklist. The latter is a risk management output.

Risk assessment methodology without CIA framing. ISO 27001:2022 is explicit: risk assessment must identify risks associated with the loss of confidentiality, integrity, and availability of information. A risk register that contains general business risks, operational risks, or hybrid enterprise risk management entries does not satisfy Clause 6.1.2. Information security risk is specific: it relates to specific information assets, specific threats to those assets, and specific vulnerabilities that those threats could exploit. The methodology must produce this specificity. Generic risk scoring without asset-threat-vulnerability analysis is not an ISO 27001 risk assessment.

Residual risk acceptance without documented authority. Clause 6.1.3(e) requires that risk treatment plans are approved by risk owners, and that residual risks are accepted. Risk acceptance is a documented decision by an identified authority. In most implementations, residual risk acceptance is implicit — the risk treatment plan is completed, residual risk is scored, and the register is considered closed. No authority is documented. No formal acceptance decision is recorded. This means the organisation’s risk acceptance process is not an ISMS-governed process — it is an assumption.

The Evidence Standard a Stage 2 Auditor Will Apply

A technically proficient Stage 2 auditor will conduct a traceability test. They will select five to eight SoA controls — typically including several newly introduced in the 2022 revision (A.5.7 Threat intelligence, A.5.23 Information security for use of cloud services, A.8.8 Management of technical vulnerabilities, A.8.12 Data leakage prevention) — and ask the organisation to demonstrate the risk register entry that justifies each one.

They will then select five to eight risks from the risk register and ask which SoA controls address each risk, and where the implementation evidence for those controls exists. This is the bidirectional traceability test: SoA to risk register, and risk register to SoA. Most implementations pass one direction. Few pass both.

Why the Inversion Persists Across Certified Systems

SoA-first construction — selecting controls and then building a risk register to justify them — persists because it is faster, more predictable, and produces a cleaner document. Starting from a genuine information asset register and conducting a threat and vulnerability analysis per asset requires domain knowledge, time, and a methodology that the implementation team needs to design and validate. Building an SoA from Annex A and adding supporting rationale afterwards requires neither.

The result is an ISMS where the control architecture is inherited from the standard rather than derived from the organisation’s risk landscape. The controls are not wrong — Annex A represents a comprehensive information security control set. But they are not selected. They are adopted. And adoption without selection is compliance without risk management.

The SGRII Position

The Risk pillar in the SGRII framework is precise: risk assessment drives control selection, not the reverse. THE SGRII ISO 27001:2022 ISMS FRAMEWORK is built around this sequence. The Information Asset Register provides the foundation for risk identification. The Risk Assessment Methodology is CIA-framed and produces asset-specific, threat-specific, vulnerability-specific risk scenarios. The Risk Register is structured to support bidirectional SoA traceability — every risk references the controls that treat it; every SoA control references the risks that justify it.

The Statement of Applicability template includes both inclusion and exclusion justification fields with risk register reference fields built in — not as optional fields, but as mandatory completion requirements. The Residual Risk Acceptance Log captures authority, date, and review cycle for every formally accepted risk. And the information security objectives register includes all five Clause 6.2 plan elements as mandatory fields. The system is designed so that the SoA cannot be completed without a risk register that justifies it.