Your cloud provider passed its own audit. Your data still leaked. The gap between assuming a provider handles security and actually governing how your organization uses cloud services is where breaches happen, and it’s exactly what ISO 27001 control 5.23 exists to close.
What 5.23 requires
ISO 27001 control 5.23 requires your organization to establish and enforce policies and procedures that govern the full lifecycle of cloud services — from acquisition and secure configuration through ongoing management to termination. This isn’t a control about whether your cloud provider is secure. It’s about whether you have a systematic approach to managing security across every cloud service you use.
The control covers four distinct phases. First, selection and onboarding: defining which cloud service models (IaaS, PaaS, SaaS) are approved, what security criteria providers must meet, and how new services get vetted before adoption. Second, configuration: ensuring services are deployed with encryption, access controls, and logging that meet your security requirements — not just the provider’s defaults. Third, ongoing governance: you continuously monitoring provider compliance, reviewing configuration drift, and tracking changes to service terms or sub-processors. Fourth, exit: retrieving your data, confirming secure deletion, and transitioning to alternative services when a relationship ends.
At the core of 5.23 is the shared responsibility model. Cloud providers secure their infrastructure, but you remain responsible for your data, your configurations, and your access controls. Without this control in place, cloud adoption outpaces security governance, and the organization ends up with services nobody vetted, configurations nobody reviewed, and data nobody can account for. The 2022 revision of ISO 27001 introduced 5.23 as a standalone control precisely because cloud services had become too critical and too widespread to be covered by general supplier management alone. It acknowledges that the security dynamics of cloud services require dedicated governance that addresses their unique risk profile.
Why 5.23 matters
An organization migrates workloads to the cloud under pressure to modernize. Teams spin up storage buckets, deploy applications, and onboard SaaS tools without a formal security review process. Six months later, a routine assessment reveals a storage bucket configured with public read access, three former employees with active cloud admin credentials, and a SaaS analytics tool processing customer data with no data processing agreement in place. No single failure caused this. The organization simply moved to cloud services without establishing the governance framework to manage them securely.
This isn’t a hypothetical edge case. It’s the predictable outcome when cloud adoption moves faster than governance. According to IBM’s 2024 Cost of a Data Breach Report, 40% of all data breaches involved data distributed across multiple environments, including public cloud, private cloud, and on-premises infrastructure. The average cost of a breach reached $4.88 million, with multi-environment breaches among the most expensive to contain.
The risks are compounding. Data exposure from misconfigured services creates regulatory liability. Unrevoked access credentials give attackers a persistent foothold. Absent exit procedures leave sensitive data stranded on provider systems long after a contract ends. And shadow cloud services, adopted by teams without security’s knowledge, create blind spots that no amount of perimeter security can cover.
What attackers exploit
When 5.23 controls are weak or missing, attackers target predictable failure modes that align with the CSA’s Top Threats to Cloud Computing:
- Misconfigured cloud storage with public access, exposing sensitive data to anyone with the URL
- Orphaned accounts from departed employees retaining administrative cloud access
- Missing encryption at rest or in transit because teams assumed provider defaults were sufficient
- Shadow cloud services adopted by business units without security vetting or visibility
- Absent exit procedures leaving data residuals on terminated provider systems
- Unmonitored sub-processor changes where a provider quietly shifts data processing to new third parties
Each of these failure modes maps directly to a gap that 5.23 is designed to close. The control doesn’t exist to slow down cloud adoption. It exists to make sure your security posture keeps pace with it.
How to implement 5.23
Implementation breaks into two tracks: what you do internally and how you assess your vendors. Both are necessary — first-party controls without vendor oversight leave you exposed to supply chain risk, while vendor assessments without internal governance leave you unable to enforce what you find.
For your organization (first-party)
1. Develop a cloud security policy. Define approved service models (IaaS, PaaS, SaaS), data classification requirements for each model, encryption standards, and access control baselines. The policy should specify which types of data can be processed in each service model, what encryption is required at rest and in transit, and what access control mechanisms must be in place before a cloud service goes live. This policy becomes the reference point for every decision downstream.
2. Establish a cloud service register. Inventory all cloud services in use across the organization, including who owns each service, what data it processes, its security classification, and the shared responsibility split. The register should capture both sanctioned services and any shadow IT discovered during the inventory process. Update it on a regular cadence and whenever a new service is adopted or decommissioned. This register is your single source of truth. If a service isn’t in it, it hasn’t been vetted.
3. Implement a vetting and onboarding process. Require a security assessment before any new cloud service is adopted. Review the provider’s SOC 2 Type II or ISO 27001 certification, evaluate their data processing agreement, and confirm their security controls align with your policy requirements. Centralize authentication through an identity provider such as Okta or Microsoft Entra ID so that access provisioning and deprovisioning follow a consistent process across all cloud services.
4. Document shared responsibility. For each cloud provider, map which security controls you own versus which the provider owns. This mapping should be specific — “provider manages physical security and hypervisor patching; we manage OS configuration, access management, and data encryption” — not a vague acknowledgment that responsibility is shared.
5. Set up continuous monitoring. Review cloud provider compliance reports on a defined cadence. Monitor for configuration drift using cloud security posture management (CSPM) tooling. Track changes to service terms, sub-processor lists, and incident disclosure timelines. Establish alerting for critical configuration changes, such as storage access controls being modified or encryption settings being downgraded, so that deviations from your security baseline are caught before they become exposure.
6. Plan for exit. Document data retrieval procedures, secure deletion confirmation requirements, and transition timelines for each critical cloud provider. Include specifics: what format the data will be exported in, how long the provider retains data after termination, and what confirmation of secure deletion you will receive. Exit planning is not something you do when a contract ends. It’s something you document when the relationship begins.
7. Produce evidence. Every step above should generate artifacts: policy documents, the cloud register, completed risk assessments, shared responsibility matrices, monitoring logs, and exit plans. These artifacts are what auditors review.
Common mistakes to avoid:
- Treating a cloud provider’s ISO 27001 certificate as proof your data is secure (they certify their controls, not yours)
- Not updating cloud inventories when teams adopt new SaaS tools
- Assuming default encryption settings meet your policy requirements
- Skipping exit planning until a contract is actually ending
For your vendors (third-party assessment)
When assessing vendors against 5.23, your security questionnaires should probe their cloud security posture directly. Ask about their cloud service policies, how they document shared responsibility, their incident response procedures for cloud-hosted data, their data residency controls, and their exit and termination procedures.
Evidence to request: ISO 27001 or SOC 2 Type II reports, cloud security policy documentation, data processing agreements, sub-processor lists, and penetration test summaries. These artifacts should corroborate their questionnaire responses — self-attestation alone is not verification. Effective third-party risk management requires corroborating what vendors claim with what evidence confirms.
Red flags to watch for:
- A vendor that cannot articulate shared responsibility boundaries
- No documented exit process for data retrieval and deletion
- Refusal to share third-party audit reports or penetration test summaries
- Significant gaps in encryption or access control evidence
- No formal sub-processor management process or incomplete sub-processor lists
- Incident response procedures that do not address cloud-specific scenarios
Any of these signals a maturity gap that puts your data at risk.
Don’t stop at the questionnaire. Compare vendor responses against external security ratings, request specific evidence artifacts, and check for recent disclosed incidents. A structured third-party risk assessment process ensures consistency across your vendor portfolio. The goal is a verified picture of vendor cloud security posture, not a completed checklist.
Audit evidence for 5.23
Auditors assess 5.23 by reviewing whether your cloud security governance is documented, operational, and producing evidence. The table below maps the evidence types they expect to the specific artifacts you should maintain.
| Evidence type | Example artifact |
|---|---|
| Cloud security policy | Topic-specific policy defining approved cloud service models, data classification requirements, encryption standards, and access control baselines |
| Cloud service register | Inventory listing all cloud services in use, data owners, data types processed, security classification, and shared responsibility assignments |
| Vendor security assessments | Completed risk assessments for each cloud provider, including review of SOC 2 Type II or ISO 27001 certificates and gap analysis |
| Shared responsibility matrix | Documented allocation of security controls between the organization and each cloud provider |
| Cloud service agreements | Executed contracts with data processing terms, SLAs, incident notification clauses, and termination/exit provisions |
| Monitoring evidence | Logs or reports from configuration monitoring tools showing regular review of cloud security posture and drift detection |
| Exit plan documentation | Documented procedures for data retrieval, secure deletion verification, and service transition for each critical cloud provider |
The key is traceability. Auditors want to see that your policy drives your processes, your processes produce records, and your records demonstrate consistent execution. Documents that exist in isolation without evidence of implementation will not satisfy an audit. Auditors will typically sample specific cloud services from your register, then trace the chain from policy to risk assessment to monitoring evidence for each one. Gaps in this chain, such as a cloud service in active use that does not appear in the register, or a register entry without a corresponding risk assessment, are the most common findings during 5.23 audits.
Cross-framework mapping
If your organization operates under multiple compliance frameworks, 5.23 maps to established controls across NIST, SOC 2, CIS, and NIST CSF. The table below uses NIST 800-53 mappings from the official OLIR crosswalk.
| Framework | Equivalent control(s) | Coverage |
|---|---|---|
| NIST 800-53 | SA-01 (System and Services Acquisition Policy and Procedures) | Full |
| NIST 800-53 | SA-04 (Acquisition Process) | Full |
| NIST 800-53 | SA-09 (External System Services) | Full |
| NIST 800-53 | SA-09(03) (Establish / Maintain Trust Relationship with Providers) | Full |
| NIST 800-53 | SR-05 (Acquisition Strategies, Tools, and Methods) | Full |
| SOC 2 | CC9.2 (Risk Mitigation for Third Parties) | Partial |
| CIS Controls v8.1 | 15.1–15.5 (Service Provider Management) | Partial |
| NIST CSF 2.0 | GV.SC (Supply Chain Risk Management) | Partial |
Organizations already compliant with NIST 800-53 SA-09 will find significant overlap with 5.23’s requirements for managing external cloud services. SA-09 specifically addresses the use of external information system services and requires organizations to establish trust relationships with external providers, which maps directly to 5.23’s shared responsibility documentation requirements. The SOC 2 and CIS mappings cover the vendor oversight dimension but don’t fully address 5.23’s lifecycle approach from acquisition through termination. If you’re building a multi-framework compliance program, mapping these controls reduces duplicate effort and helps demonstrate coverage to auditors working across standards.
Related ISO 27001 controls
Control 5.23 doesn’t operate in isolation. It connects to a cluster of supplier and data management controls that together form your cloud governance framework.
| Control ID | Control name | Relationship |
|---|---|---|
| 5.19 | Information security in supplier relationships | Governs the broader supplier relationship within which cloud services operate |
| 5.20 | Addressing information security within supplier agreements | Defines contractual security terms that apply to cloud service agreements |
| 5.21 | Managing information security in the ICT supply chain | Extends supply chain risk management to cloud service dependencies |
| 5.22 | Monitoring, review, and change management of supplier services | Covers ongoing monitoring of cloud provider performance and security changes |
| 5.10 | Acceptable use of information and other associated assets | Defines acceptable use policies that govern how cloud services may be used |
| 5.12 | Classification of information | Determines data classification that drives cloud security requirements |
| 8.10 | Information deletion | Applies to secure deletion of data when exiting cloud services |
| 8.11 | Data masking | Relevant when processing sensitive data in cloud environments |
Frequently asked questions
What is ISO 27001 5.23?
ISO 27001 control 5.23 requires organizations to establish policies and procedures for the secure acquisition, configuration, management, and termination of cloud services. It addresses the full cloud service lifecycle and ensures that cloud adoption aligns with the organization’s information security requirements, including clear documentation of shared responsibility between the organization and each cloud provider.
What happens if 5.23 is not implemented?
Without 5.23, organizations face uncontrolled cloud sprawl where services are adopted without security vetting, configurations go unreviewed, and access persists long after it should be revoked. This creates direct exposure to data breaches, regulatory non-compliance, and audit failure, particularly where sensitive data is processed in cloud environments without documented governance. During a certification audit, the absence of a cloud security policy and cloud service register is likely to result in a major nonconformity, which must be resolved before certification can be granted.
How do you audit 5.23?
Auditors look for a documented cloud security policy, a current cloud service register, completed vendor risk assessments, shared responsibility matrices, and evidence of ongoing monitoring. They verify that these artifacts reflect actual operational practice, not just that the documents exist. Expect auditors to sample specific cloud services from your register and trace the evidence chain from policy through risk assessment to monitoring logs. The audit evidence table above outlines the specific artifacts typically reviewed.
How UpGuard helps
UpGuard Vendor Risk gives your team the operational layer that makes ISO 27001 cloud service controls defensible. Continuously monitor your cloud providers’ security posture, send and track security questionnaires aligned to 5.23 requirements, and maintain a verified view of vendor risk that goes beyond self-attestation. See how UpGuard Vendor Risk works.