ISO Digital Solutions Get the ISMS Framework

SGRII Insights  ·  ISO 27001:2022  ·  2026

Your ISMS Has Seven Clauses and Ninety-Three Controls. Most Certified Systems Treat Them as Independent Components. They Are Not.

The structural connections between ISO 27001 clauses and Annex A controls are where implementation quality lives or dies. Most certified systems have never mapped them — and surveillance auditors are increasingly testing them.

The Dual-Layer Problem Nobody Discusses

ISO 27001 is structurally unique among Annex SL management system standards. It imposes two layers of obligation: the management system clauses (4–10), which define governance architecture, and Annex A, which defines control architecture. Both must exist. Both must connect. And the connection point — the Statement of Applicability, driven by the risk assessment — is supposed to be the bridge between them.

In most certified systems, it is not a bridge. It is a wall. The management system clauses are maintained by the ISMS Manager as governance documents. The Annex A controls are maintained by IT as technical configurations. The two teams rarely coordinate. The SoA sits between them as a static document that neither team actively uses as an operational reference. The result is a certified ISMS that has two architectures operating independently — and a certification body that audits them as though they were one.

This is the integration failure that surveillance audits increasingly expose. A Stage 2 audit can certify a system based on document review and sampling. A year-two surveillance audit tests whether the documented connections actually operate. When they do not, the finding is not on any single clause. It is on the architecture.

Chain 1: Context → Risk Assessment → Control Selection → SoA → Operational Evidence

Clause 4 → 6.1 → 6.1.3 → Annex A → 8

The entire ISMS chain runs from context through risk to controls to evidence. A static context analysis (Clause 4) produces a static risk assessment (Clause 6) that produces a static SoA that cannot demonstrate dynamic operational effectiveness (Clause 8). This chain is the most frequently broken in certified systems. The break point is almost always between Clause 4 and Clause 6 — context changes occur, but the risk register does not respond.

The audit test is direct: identify a significant change in the organisation’s operating environment since the last risk review. Ask whether the risk register reflects it. If it does not, the chain is broken at the first link.

Chain 2: Information Asset Register → Risk Assessment → Risk Treatment → SoA Justification

Asset Inventory → 6.1 → 6.1.3 → SoA

Without an information asset register, risk assessment is speculative. You are identifying risks against an undefined information landscape — guessing what assets exist, where they are, and what their CIA requirements are. Without asset-specific risk scenarios, SoA justifications are inevitably generic: ‘applicable to protect the confidentiality and integrity of information assets’ repeated beside sixty controls.

An asset register is not an ISO 27001 clause requirement in the management system body. It is an Annex A control (A.5.9: Inventory of information and other associated assets). But its absence collapses the entire risk-to-SoA chain. The standard does not require it as a clause. The system cannot function without it. This is one of the structural tensions that the standard leaves to implementers — and that most implementations resolve by skipping the asset inventory and building the SoA from the control list.

Chain 3: Risk Appetite → Treatment Decisions → Residual Risk Acceptance → Management Review

Clause 5 → 6.1 → 6.1.3 → 9.3

Leadership defines risk appetite. Risk treatment decisions reference it. Residual risks are accepted against it. Management review evaluates whether the appetite remains appropriate. If risk appetite is undocumented — and in most certified SME implementations, it is — every treatment decision is unjustified. Every residual risk acceptance is unauthorised in structural terms. And every management review that does not evaluate risk appetite is missing a governance input.

The uncomfortable reality: most organisations certified to ISO 27001 cannot produce a documented risk appetite statement that was reviewed and approved by top management. They can produce a risk assessment. They can produce a treatment plan. But the threshold against which treatment decisions were made — the appetite that determines whether a residual risk is acceptable — is implicit, undocumented, and therefore unauditable.

Chain 4: Incident Response → Lessons Learned → Risk Register Update → SoA Review → Continual Improvement

A.5.24–5.28 → A.5.27 → 6.1 → SoA → 10.1

Security incidents produce lessons learned. Lessons may identify new risks or control gaps. New risks require SoA updates. System-level improvements enter the Continual Improvement Register. This is the closed loop that most implementations never complete.

The break point is almost always between A.5.27 (learning from incidents) and Clause 6.1 (risk register update). Organisations document the incident. They document the response. They may even document lessons learned. But the lesson rarely generates a risk register entry. The risk register rarely triggers an SoA review. And the SoA rarely changes between certification cycles. The loop is documented but not closed.

Chain 5: Internal Audit → NC & CA → Effectiveness Verification → Management Review → System Changes

Clause 9.2 → 10.2 → 10.2 → 9.3 → 4/5/6

Audit findings produce corrective actions. Corrective actions require evidence-based verification. Verified results feed management review. Review decisions may change scope, policy, risk appetite, or control architecture. If audit findings are documentation-focused — missing signatures, outdated revision numbers, incomplete registers — the entire chain adds compliance value, not security value.

The structural question is whether internal audits test the system’s security effectiveness or its documentation quality. A documentation audit can pass a system that is not secure. A security audit cannot. The chain from audit to system change only delivers value if the audit inputs are operationally meaningful.

Chain 6: Competence Assessment → Control Effectiveness → Performance Measurement → Improvement

Clause 7.2 → 8 → 9.1 → 10

Role-based competence affects control operation. A firewall rule configured incorrectly due to insufficient network security competence is not a technology failure. It is a Clause 7.2 failure that manifests as a Clause 8 control implementation gap, which produces a Clause 9.1 performance measurement anomaly, which should generate a Clause 10 improvement action.

Most implementations do not trace this chain. The misconfigured firewall is treated as an IT issue, remediated as a technical fix, and never connected to the competence framework. The system fixes the symptom. It does not fix the cause. And the PDCA cycle — the fundamental mechanism of management system improvement — does not complete.

The SGRII Position

The SGRII thesis on integration is specific: an ISMS must demonstrate that its management system layer and its control layer are structurally connected through traceable, bidirectional linkages. These six chains are the minimum architecture for that connection. An ISMS that cannot trace them is an ISMS with two independent systems sharing a certificate.

The SGRII ISO 27001:2022 ISMS Framework builds these chains into the document architecture by design. The Risk Register references SoA controls. The SoA references risk scenarios. The Management Review Record receives context, risk, audit, and performance inputs as structured data. The Continual Improvement Register connects to management review outputs and incident lessons learned. The NC & CA Register connects to audit findings with effectiveness verification criteria defined at the planning stage. None of these connections are optional. All of them are structural.