A.5.23
Information security for use of cloud services
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Establish processes for the acquisition, use, management, and exit of cloud services consistent with the organization's information security requirements.
Points of focus
- Cloud and critical SaaS providers identified with a documented shared-responsibility understanding
- Data processing agreements or equivalent contracts are in place before customer or personal data flows to a provider
- An exit or migration plan exists for providers the business would struggle to replace quickly
- Sub-processor changes from vendors are monitored and assessed for material risk change
Implementation notes
List cloud infrastructure and critical SaaS providers with what they handle and where responsibility splits — compute patching, data encryption, backup ownership — since assuming the provider covers something it doesn't is a real operational failure mode, not just an audit gap. Get DPAs signed before data flows, and BAAs where PHI is involved, and track sub-processor list changes from key vendors as part of ongoing vendor risk rather than a one-time signature at onboarding. Write a short exit or degradation plan for the one or two providers that would be hardest to replace, usually the cloud provider and the IdP — it doesn't need to be exhaustive, but it needs to exist and name the first three steps.
Audit tip: Ask what happens if the primary IdP or cloud provider has a multi-day outage or the relationship ends. A real runbook or migration note beats a confident verbal answer every time.
Evidence auditors typically request:
- Cloud/SaaS vendor register noting the service, data handled, and shared-responsibility notes
- Signed DPAs, and BAAs where PHI applies, for providers processing customer or personal data
- A written exit or migration plan for at least the primary infrastructure or identity provider
- A record of reviewing a vendor's sub-processor list update or security notification
Common gaps
- No documented exit plan exists for the primary cloud provider or IdP — 'we'd figure it out' is the actual answer in interviews
- Shared-responsibility assumptions are wrong: a team believes the cloud provider patches the OS on their compute when the customer is responsible for it
- A vendor processing personal data has no DPA on file, or the DPA predates a since-changed sub-processor list
- Vendor security notifications, such as breach or deprecation notices, aren't routed anywhere, so the business misses them
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.5.23 | This control |
| SOC 2 | CC9.2 | CC9.2 covers vendor and business-partner risk management broadly; cloud infrastructure providers are typically the highest-risk subset worth documenting separately. |
| GDPR | Article 28 | Article 28 processor obligations apply directly when a cloud vendor processes personal data on your behalf — a signed DPA is the concrete artifact here, not just the SoA entry. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.5.23)