The most common supplier-control nonconformity in an ISO 27001 audit is not a missing control, it is a control marked Applicable in the Statement of Applicability with nothing operating behind it. A.5.19 through A.5.23 are almost always in scope, because almost every organisation uses suppliers and cloud, and the certification auditor knows exactly where to pull the thread: from the SoA, to the supplier register, to a sampled agreement, to the monitoring record that should exist and often does not.
The five supplier controls in ISO/IEC 27001:2022 form a lifecycle, not a checklist: decide the security you need from suppliers, write it into agreements, manage it down the ICT supply chain, monitor it, and handle cloud specifically. This is how to make each one demonstrably operate, and what the auditor samples for each.
Scope. For organisations running an ISMS certified to, or transitioning to, ISO/IEC 27001:2022, the transition window from the 2013 version closed at the end of October 2025, so the 2022 Annex A is now the only game. Audience: ISMS managers, security leads, and internal auditors preparing for Stage 2 or a surveillance visit. Annex A control text belongs to ISO; this is implementation guidance, not a reproduction.
The five controls as one lifecycle
| Control | Intent | The 2022 change |
|---|---|---|
| A.5.19 Information security in supplier relationships | Define the process and requirements for managing supplier-related risk | Consolidated from 2013 A.15.1.1 |
| A.5.20 Addressing information security within supplier agreements | Put the requirements into the contract | From A.15.1.2 |
| A.5.21 Managing information security in the ICT supply chain | Propagate requirements down the ICT product/service chain | From A.15.1.3, sharpened toward ICT |
| A.5.22 Monitoring, review and change management of supplier services | Keep assurance current as services change | From A.15.2.1/.2 |
| A.5.23 Information security for use of cloud services | Manage cloud acquisition, use, and exit specifically | New in 2022 |
A.5.23 is the one people miss in a transition, because there was no direct 2013 equivalent. If your supplier programme predates the 2022 move, cloud is almost certainly under-treated in it.
The SoA is a promise the auditor collects on. Marking A.5.19–A.5.23 Applicable commits you to demonstrating each one operates. The fastest nonconformity in the supplier domain is an SoA that says "Applicable, implemented" against a control for which you cannot produce the register, the agreement clause, or the monitoring record. Either operate the control or justify its exclusion, never leave it applicable-on-paper only.
The supplier register the controls imply
ISO does not prescribe a register format, but A.5.19 requires a process to identify and manage supplier risk, which in practice means a register. Anchor it in your risk assessment, and classify suppliers by their access to information and assets, because the classification is what makes A.5.20's requirements proportionate.
| Field | Control it serves | Evidence value |
|---|---|---|
| Supplier + service | A.5.19 | Scope of the relationship |
| Classification (access to info/assets) | A.5.19 / A.5.20 | Justifies the requirement level |
| Agreement + security clauses reference | A.5.20 | Traceable to the signed contract |
| ICT supply-chain considerations | A.5.21 | Sub-supplier / component propagation |
| Cloud flag + shared-responsibility notes | A.5.23 | Triggers the cloud-specific treatment |
| Last review + service reports | A.5.22 | Proof the control keeps operating |
Implementation, control by control
A.5.19 — the process and the register
Write a supplier security process that ties into your risk assessment, and populate the register from more than procurement. Enumerate cloud and SaaS actually in use (the Entra ID enterprise-application inventory surfaces OAuth-connected apps that never went through purchasing) and reconcile. Classify each supplier by the information and assets it can reach; that classification drives everything downstream.
A.5.20 — requirements in the agreement
The security requirements have to live in the contract, not in an email. For higher-classification suppliers, the agreement should name the security standards to be met, access and handling rules, incident-notification obligations and timeframes, sub-processing and audit/evidence rights, return/deletion of data on exit, and personnel-security expectations. The register points to the clause; the auditor follows the pointer.
A.5.21 — the ICT supply chain
This control is about propagation: requiring your ICT suppliers to pass relevant security requirements down to their suppliers and to be transparent about components and sub-suppliers that materially affect your security. You will not get full depth from everyone; the deliverable is evidence that you require it where it matters and understand the chain beneath critical ICT services.
A.5.22 — monitoring and change
Assurance decays. A.5.22 asks you to monitor and review supplier service delivery against the agreement, react to changes (new sub-processors, service changes, incidents), and keep the assurance current. In practice: service reports and SLAs reviewed on a cadence, refreshed certifications or SOC 2 reports on file, and a re-review triggered by change. The single most common gap in the whole domain is a signed agreement with no evidence anyone reviewed the supplier afterward.
A.5.23 — cloud services
Treat cloud acquisition, use, and exit as a distinct discipline: understand the shared-responsibility split for each service, set security expectations before onboarding, use the provider's own attestations (ISO 27001, SOC 2, CSA STAR) as assurance evidence rather than re-auditing a hyperscaler, and, critically, define an exit and data-return path. For Microsoft 365 and Azure this means recording which responsibilities are yours versus Microsoft's per service, holding Microsoft's certifications as the assurance artefact, and documenting how you would extract and delete data on termination.
Common mistakes
- A.5.19–A.5.23 marked Applicable in the SoA with no supplier register behind them.
- A.5.23 forgotten in a 2013→2022 transition, because cloud had no direct predecessor control.
- Security clauses in agreements but zero A.5.22 monitoring evidence, the control that "operates once."
- Every supplier treated identically, with no classification driving proportionate requirements.
- Re-auditing hyperscalers instead of accepting their attestations, wasting effort A.5.23 lets you avoid.
- No exit/data-return provision, so cloud lock-in becomes a security and continuity finding.
What the certification auditor samples
The supplier domain is audited by tracing, and the trace is always the same shape. Expect the auditor to:
- Start at the SoA and confirm A.5.19–A.5.23 are Applicable with a rationale.
- Ask for the supplier register and check it is risk-driven and classified, not just a vendor list.
- Sample two or three suppliers and trace each from register → risk assessment → agreement clauses (A.5.20) → monitoring record (A.5.22).
- Probe cloud (A.5.23) specifically: shared responsibility understood, provider assurance held, exit defined.
- Test change management: what happened when a supplier changed a sub-processor or had an incident?
A missing register is a major nonconformity (a whole control not operating); a register that exists but shows no monitoring is typically a minor, still a corrective-action commitment you will carry to the next surveillance visit.
Evidence and documentation to keep
- The SoA showing A.5.19–A.5.23 status and justification.
- The supplier register with classifications and review dates.
- The supplier security process/policy (A.5.19).
- Sampled agreements with security clauses highlighted (A.5.20), and ICT supply-chain requirements (A.5.21).
- Monitoring records, service reports, refreshed attestations (A.5.22), and cloud shared-responsibility + exit documentation (A.5.23).
The same discipline across frameworks
ISO 27001's supplier controls are the certifiable posture of a discipline shared by every major framework: know your third parties, classify them, put requirements in agreements, assess, monitor, and exit. The supplier register you build for A.5.19 maps across all five. Mappings are approximate and directional.
| Framework | Control | Posture |
|---|---|---|
| DORA | Art 28(3) + ITS (EU) 2024/2956 | Prescriptive, machine-validated register (financial entities) |
| NIS2 | Art 21(2)(d) | Outcome-based directive; direct suppliers; no format |
| ISO/IEC 27001:2022 (this article) | A.5.19–A.5.23 | Certifiable; justified in the Statement of Applicability |
| NIST CSF 2.0 | GV.SC | Outcome-based; profiles and tiers |
| CIS Controls v8.1 | Control 15 | Prescriptive safeguards, IG1→IG3 |
Key takeaways
- Applicable in the SoA is a commitment to evidence, treat every applicable supplier control as auditable now.
- Classify suppliers by access to information and assets; classification makes A.5.20 proportionate.
- A.5.22 monitoring is where the domain fails, agreements get signed and suppliers never get reviewed again.
- A.5.23 is new in 2022 and routinely under-treated after a transition; give cloud its own path including exit.
- Accept hyperscaler attestations as assurance rather than re-auditing them, that is exactly what A.5.23 intends.
References and further reading
- ISO/IEC 27001:2022 and ISO/IEC 27002:2022 (the implementation guidance for the Annex A controls), purchase from ISO; the standard text is theirs.
- Your certification body's transition and audit guidance for the 2022 revision.
- Cloud provider trust portals for the attestations you rely on under A.5.23 (ISO 27001, SOC 2, CSA STAR).
Frequently Asked Questions
Are A.5.19 to A.5.23 mandatory?
Annex A controls are not mandatory in the abstract; you include or exclude each in your Statement of Applicability based on your risk assessment. In practice the supplier controls are almost always Applicable because nearly every organisation uses suppliers and cloud, and excluding them requires a defensible justification an auditor will challenge.
Do we need to audit Microsoft or AWS for A.5.23?
No. A.5.23 expects you to understand the shared-responsibility model, set expectations, and use the provider's own attestations (ISO 27001, SOC 2, CSA STAR) as assurance rather than re-auditing a hyperscaler. Your effort goes into the responsibilities that are yours, configuration, access, data handling, and into defining a cloud exit and data-return path.
Does ISO 27001 require a supplier register?
It does not prescribe a register by name, but A.5.19 requires a process to identify and manage supplier risk, which you evidence with a risk-driven, classified supplier register. The auditor uses it as the entry point for sampling, so its absence reads as the control not operating.
We are still on ISO 27001:2013. What changes for suppliers?
The 2013 supplier controls (A.15.x) consolidate into A.5.19–A.5.22, and A.5.23 for cloud is entirely new. The transition period from 2013 to 2022 ended in October 2025, so a certified ISMS must already be on the 2022 controls; the practical delta is giving cloud its own treatment under A.5.23.