SGRII Insights · ISO 27001:2022 · 2026
Thirty-Seven Organisational Controls. Three New Since 2022. Most Implementations Treat Them as Policies. The Standard Treats Them as Operational Obligations.
Annex A.5 contains the largest control theme in ISO 27001:2022 — and the one most frequently reduced to a policy library. Policies are not controls. Controls require implementation evidence. Here is where most ISMS programmes have a documentation system instead of a security system.
SGRII Performance & Digital Solutions
ISMS Practice · April 2026 · 14 min read
SGRII Pillar Lens
Governance
Governance in the SGRII framework means embedded accountability — roles, controls, and decisions built directly into the organisation’s workflows. Annex A.5 is the governance backbone of the ISMS: it defines how policies are structured, how roles are assigned, how suppliers are managed, how incidents are handled, and how legal obligations are met. When these controls exist only as policy documents, governance is aspirational. When they exist as operational evidence, governance is demonstrable.
The Policy-to-Control Confusion
Open any ISMS document pack and look at how Annex A.5 controls are addressed. What you will find, in the majority of certified implementations, is a collection of policy documents: Information Security Policy, Acceptable Use Policy, Access Control Policy, Supplier Security Policy, Incident Management Policy. Each policy covers multiple A.5 controls. Each policy is approved, version-controlled, and distributed.
And each policy, by itself, satisfies nothing.
A policy is a statement of intent. A control is an implemented mechanism that reduces risk. ISO 27001 Annex A requires controls, not policies. A.5.1 (Policies for information security) requires policies to be defined — but every subsequent A.5 control requires the policy to be implemented with operational evidence. An access control policy that says ‘access shall be granted on the principle of least privilege’ is a policy statement. Evidence of a quarterly access review that revoked 23 excessive permissions in Q1 2026 is an operational control. The standard requires both. Most implementations deliver only the first.
The Three New Controls: A.5.7, A.5.23, A.5.30
A.5.7 — Threat intelligence. This is not a nice-to-have awareness activity. It is a control that requires the organisation to collect, analyse, and act on information about threats relevant to its information security. The implementation evidence includes: threat intelligence sources identified, analysis methodology documented, outputs feeding into risk assessment and control selection. An organisation that cannot demonstrate how threat intelligence informs its risk register has an A.5.7 gap — regardless of whether it subscribes to threat feeds.
A.5.23 — Information security for use of cloud services. The 2013 edition did not contain a cloud-specific control. The 2022 edition does — reflecting the reality that most organisations process information in cloud environments. Implementation evidence includes: cloud service inventory, security responsibility matrix (shared responsibility model per provider), data residency controls, and cloud-specific risk assessment. A general cloud policy is not A.5.23 compliance.
A.5.30 — ICT readiness for business continuity. Distinct from A.5.29 (Information security during disruption), A.5.30 specifically addresses whether ICT services can be maintained or restored following a disruption. Implementation evidence includes: ICT continuity plans, recovery time and recovery point objectives for critical systems, test results, and lessons learned from tests or actual disruptions. This is where BIA meets ISMS — and where most implementations have a business continuity plan that has never been tested against ICT recovery requirements.
Supplier Security: A.5.19–A.5.22
Four controls dedicated to supplier information security: A.5.19 (Supplier relationships), A.5.20 (Addressing information security within supplier agreements), A.5.21 (Managing information security in the ICT supply chain), A.5.22 (Monitoring, review, and change management of supplier services). This cluster is where the ISMS meets the organisation’s actual data processing landscape — because in most modern organisations, more data is processed by suppliers than by internal systems.
The audit test is specific: select a critical supplier. Request the contractual information security requirements. Request evidence of monitoring and review. Request evidence of change management when the supplier changed their service. If the organisation has a supplier register with annual review dates but no evidence of what the review assessed, the controls are documented but not operating.
The supply chain attack vector — SolarWinds, MOVEit, 3CX — has made A.5.21 the most consequential of the four controls. It requires the organisation to address information security in the ICT supply chain specifically, including risks from the supplier’s own suppliers. An organisation that evaluates its Tier 1 suppliers but has no visibility into Tier 2 has an A.5.21 gap that represents real operational risk.
Incident Management: A.5.24–A.5.28
Five controls define the incident management lifecycle: planning and preparation (A.5.24), assessment and decision (A.5.25), response (A.5.26), learning (A.5.27), and evidence collection (A.5.28). These are Annex A controls — operational security mechanisms — not Clause 10.1 continual improvement. The distinction matters structurally, as we addressed in the first post in this series.
The implementation evidence for this cluster is operational: an incident classification framework that has been applied to real events, response procedures that have been tested (tabletop exercises count), evidence collection procedures that meet forensic standards where required, and — critically — post-incident review records that demonstrate learning was captured and fed into the risk register and continual improvement register.
An incident management procedure that exists as a document but has never been activated — either through a real incident or a test — is an unverified control. The standard does not require incidents to occur. It requires the response capability to be demonstrable.
The SGRII Position
The SGRII view on Annex A.5 is that every organisational control has two components: a documented requirement (the policy) and an operational obligation (the evidence). The SGRII ISMS Framework separates these explicitly. Each A.5 control has a procedure that defines the operational requirement and an evidence requirements section that specifies what records must exist to demonstrate implementation.
The Annex A Implementation Guide maps all 37 organisational controls with: control objective, implementation methodology, evidence requirements, Clause 8 operational linkage, and common audit findings. This is the reference that converts policies into controls — because policies without evidence are statements. Controls with evidence are security.
THE SGRII ISO 27001:2022 ISMS FRAMEWORK
The SGRII ISMS Framework treats every Annex A control as a two-component obligation: documented requirement and operational evidence. The Annex A Implementation Guide maps all 93 controls with evidence requirements.
Includes: A.5 Organisational Control Procedures (supplier security, incident management, cloud security, threat intelligence), Annex A Implementation Guide with evidence requirements per control, and the Annex A Map with implementation status tracking.
GET THE ISMS FRAMEWORK — FROM $149 ›Join the Conversation
For any A.5 control marked as implemented in your SoA, can you produce operational evidence — not the policy, but the evidence that the policy is operating? Start with A.5.23 (cloud security) and A.5.7 (threat intelligence) — the two new controls that most implementations have addressed with a policy and nothing else.
Practitioner perspectives that challenge or extend this analysis are particularly welcome. Leave your comment below — the SGRII team responds to every substantive contribution.