A.5.23 — Information security for use of cloud services

Specify, implement and manage information security controls for cloud service acquisition, use, management and exit.

Also written as A5.23, Annex A 5.23, ISO 27001:2022 A.5.23, ISO27001 A.5.23.

Written by Jett N. · Last reviewed 22 July 2026

What ISO 27001 A.5.23 requires

Information security for use of cloud services is one of 37 Organisational Controls in ISO/IEC 27001:2022 Annex A. Specify, implement and manage information security controls for cloud service acquisition, use, management and exit. Organisational controls are judged on governance rather than tooling: an auditor wants a named owner, an approval trail, and evidence the control is exercised on a defined cadence rather than written once and filed.

Audit evidence assessors look for

When preparing your Statement of Applicability (SoA) for A.5.23, gather artefacts such as:

How to implement A.5.23

1. Build a cloud services register firstYou cannot secure what you have not enumerated, and shadow SaaS is the norm rather than the exception. Start from expense records and SSO logs rather than asking teams what they use — the answers differ. The register is the artefact that makes every other part of this control possible.
2. Document the shared responsibility split per serviceThe split differs sharply between IaaS, PaaS and SaaS, and assuming the provider covers something they do not is the single most common cloud control failure. Write it down per service, not once for "the cloud", and have the service owner confirm it.
3. Assess before acquisition, not afterThe control covers acquisition explicitly. That means security assessment has to sit inside procurement, with a defined gate. Retrospective assessment of services already holding your data is remediation, not the control operating.
4. Write a real exit planExit is named in the control text and is the part almost everyone skips. For each significant service, record how you would get your data out, in what format, how long it would take, and what the provider is contractually obliged to do on termination. Test the extract on at least one critical service.
5. Address data residency explicitlyWhere the data physically sits drives regulatory exposure, and cloud regions change. Record the region per service and re-check it during review, because providers do move and replicate data in ways that are easy to miss.

Common audit findings for A.5.23

What actually gets raised against A.5.23, in rough order of how often it comes up:

• A cloud register that lists the three big platforms and none of the dozens of SaaS tools individual teams have bought.
• A shared-responsibility matrix copied from a provider marketing page without mapping it to how the organisation actually uses the service.
• No exit plan at all, or an exit plan that has never been tested against the provider actual export capability.
• Cloud services onboarded through expenses rather than procurement, bypassing the assessment gate entirely.

Scoping A.5.23

A.5.23 is new in ISO 27001:2022. Excluding it requires demonstrating you use no cloud services whatsoever, which is now rare enough that auditors treat the exclusion with scepticism. If you are cloud-hosted, expect this control to be sampled in depth, and expect it to be read alongside A.5.19 to A.5.22 on supplier relationships.

How A.5.23 maps to SOC 2 and NIST CSF

If you run more than one framework, the same evidence usually satisfies all of them. A.5.23 aligns with:

SOC 2: CC6.7 Protection of data in transmission and movement, CC9.2 Vendor and business partner risk

NIST CSF 2.0: GV.SC-05 Supply chain requirements in contracts, GV.SC-06 Due diligence before supplier relationships, ID.AM-04 Supplier-provided asset inventory

ISO 27001:2013 mapping

A.5.23 is a new control introduced in the 2022 revision with no direct 2013 equivalent. Treat it as a fresh requirement when transitioning from ISO 27001:2013.

Related Annex A controls

See all 37 Organisational Controls →