ISO 27001 Annex A Control 5.23: Information Security for Cloud Services

One of the most common questions we get at Agency from companies pursuing ISO 27001 is how to handle their growing dependence on cloud services. Nearly every organization we work with runs on AWS, Azure, or GCP — often all three — plus dozens of SaaS tools. Control 5.23 is the ISO 27001 Annex A control that addresses this reality head-on, and in our experience, it is one of the controls that auditors examine most carefully because of how much organizational risk now lives in the cloud.

This guide walks through exactly what Control 5.23 requires, how to implement it across the full cloud service lifecycle, what evidence auditors expect, and the common gaps we see during certification audits. Whether you are building your ISMS from scratch or tightening an existing program, understanding this control is essential for any organization that depends on cloud infrastructure or SaaS platforms.

What Control 5.23 Requires

Control 5.23 was introduced in the 2022 revision of ISO 27001 Annex A. It consolidates and expands on several controls from the previous version that touched on supplier relationships and cloud computing. The control states that processes for the acquisition, use, management, and exit from cloud services shall be established in accordance with the organization's information security requirements.

What we tell clients is that this control is not asking you to audit AWS's data centers. It is asking you to demonstrate that you have a structured, risk-based approach to every phase of your cloud service relationships — from the moment you evaluate a new provider through the day you migrate away from them.

The control applies to all cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In our experience, companies often focus their cloud security efforts on IaaS providers like AWS and Azure while overlooking the dozens of SaaS applications that also process, store, or transmit sensitive data. What we recommend is treating every cloud service that handles your data as in scope for this control.

The Four Phases of Cloud Service Governance

Control 5.23 is structured around four lifecycle phases. Each phase has specific expectations, and auditors evaluate whether you have documented processes and evidence for all four.

Phase 1: Acquisition

Before onboarding any cloud service, you need a defined evaluation process. What we recommend is a supplier assessment that covers the following areas:

• Security posture evaluation: Review the provider's SOC 2 report, ISO 27001 certificate, or equivalent attestation. In our experience, requiring at least one independent security attestation is a reasonable baseline for any cloud service that will handle your data.
• Data classification alignment: Confirm that the provider's security controls are appropriate for the classification level of the data you intend to process. A provider that is adequate for internal operational data may not meet your requirements for customer PII or regulated data.
• Contractual security requirements: Ensure your agreements include data processing terms, breach notification obligations, audit rights, and data return or deletion provisions.
• Shared responsibility mapping: Document which security controls are the provider's responsibility and which are yours. This is particularly important for IaaS and PaaS services where the shared responsibility model creates significant customer-side obligations.

What we tell clients is that the acquisition phase is where most organizations create the documentation that auditors will reference for every other phase. A thorough supplier assessment at onboarding saves significant rework later.

Phase 2: Use

Once a cloud service is operational, you need ongoing processes to ensure it remains securely configured and appropriately used. Key elements include:

• Configuration management: Document and enforce secure configuration baselines for each cloud service. For IaaS providers, this includes network security groups, identity and access management policies, encryption settings, and logging configuration.
• Access control: Implement role-based access with least-privilege principles. In our experience, excessive permissions in cloud environments are the single most common finding during ISO 27001 audits related to this control.
• Monitoring and logging: Enable audit logging for cloud services and integrate logs into your centralized monitoring platform. Auditors expect to see that you are actively monitoring cloud service usage, not just configuring services and walking away.
• Data protection: Ensure encryption at rest and in transit meets your information security policy requirements. Verify that data residency requirements are satisfied.

Phase 3: Management

Ongoing management means you are continuously assessing and responding to changes in your cloud service environment. This includes:

• Periodic supplier reviews: What we recommend is conducting formal reviews of each cloud service provider at least annually, or whenever there is a material change in the service. These reviews should reassess the provider's security posture, evaluate any incidents or outages that occurred, and confirm that contractual obligations are being met.
• Change management: When a cloud provider announces changes to their service — new features, deprecated capabilities, modified shared responsibility boundaries — you need a process to assess the security impact and update your controls accordingly.
• Incident management integration: Your incident response plan should account for cloud service incidents. In our experience, organizations that do not have pre-defined escalation paths for cloud provider incidents waste critical time during actual events.
• Performance and SLA monitoring: Track service availability, performance, and compliance with agreed-upon service levels. Document any breaches of SLA terms and the provider's response.

Phase 4: Exit

The exit phase is the one that most organizations neglect entirely, and auditors know it. What we tell clients is that you need a documented exit strategy for every cloud service before you need one. Exit planning should address:

• Data retrieval: Document the process and format for extracting your data from the service. Test the extraction process periodically — do not discover that your data export is broken on the day you need to leave.
• Data deletion confirmation: Define how you will verify that the provider has deleted your data after the relationship ends. This is especially important for services that handle regulated data.
• Service continuity: Identify alternative providers or interim solutions that could maintain operations during a transition. In our experience, the organizations that handle exits smoothly are the ones that avoided single-provider lock-in from the beginning.
• Knowledge transfer: Document any provider-specific configurations, integrations, or customizations that would need to be replicated in an alternative environment.

Building Your Cloud Service Register

What we recommend is maintaining a cloud service register — a centralized inventory of every cloud service your organization uses, along with key metadata. This register becomes the foundation for demonstrating compliance with Control 5.23.

Field	Description	Example
Service name	Cloud service or platform	AWS, Salesforce, Slack
Service model	IaaS, PaaS, or SaaS	IaaS
Data classification	Highest classification of data processed	Confidential
Business owner	Person responsible for the service relationship	VP Engineering
Last security assessment	Date of most recent supplier evaluation	2023-07-15
Security attestation	SOC 2, ISO 27001, or equivalent	SOC 2 Type II (2023)
Contract renewal date	When the agreement expires or renews	2024-06-30
Exit plan documented	Whether an exit strategy exists	Yes / No

In our experience, the cloud service register is the first document auditors request when evaluating this control. Organizations that maintain a current, comprehensive register set the tone for the entire audit conversation.

Supplier Assessment Process

The supplier assessment process is where Control 5.23 intersects with your broader vendor management program. What we recommend is a tiered approach based on risk:

Tier 1 — Critical cloud services (infrastructure providers, services processing regulated data): Full security assessment including SOC 2 or ISO 27001 report review, detailed questionnaire, contractual security terms verification, and shared responsibility model documentation. Reassess annually.

Tier 2 — Important cloud services (business applications processing internal sensitive data): Security attestation review, abbreviated questionnaire focused on data protection and access controls, and contractual review. Reassess every 18 months.

Tier 3 — Standard cloud services (tools processing non-sensitive data): Security attestation or self-assessment review, standard terms verification. Reassess every 24 months or at contract renewal.

This tiered approach lets you allocate assessment resources proportionally to risk, which is exactly what auditors want to see. What we tell clients is that trying to conduct the same depth of assessment for every cloud service leads to assessment fatigue and ultimately less effective oversight of the services that matter most.

Evidence Auditors Expect

Based on hundreds of ISO 27001 audits we have supported, here is the evidence auditors typically request for Control 5.23:

• Cloud service register: The complete, current inventory described above.
• Supplier assessment records: Completed assessments for each cloud service, organized by tier.
• Risk assessment entries: Risk register entries for cloud-specific risks, with treatment plans.
• Cloud security policy: A policy or policy section that specifically addresses cloud service security requirements, roles, and responsibilities.
• Contractual documentation: Key security clauses from agreements with critical cloud providers.
• Configuration evidence: Screenshots, exports, or automated compliance reports showing secure configuration of major cloud services.
• Access review records: Evidence of periodic access reviews for cloud service accounts.
• Exit plans: Documented exit strategies for at least critical and important cloud services.

In our experience, the organizations that struggle most with this control are those that treated cloud services as purely an IT procurement function. Control 5.23 requires security involvement throughout the lifecycle, and auditors verify this by looking for security team participation in assessment records, risk registers, and ongoing review documentation.

Common Gaps We See

After working with dozens of organizations on their ISO 27001 certification, these are the Control 5.23 gaps we encounter most frequently:

Incomplete cloud service inventory. Organizations undercount their SaaS applications. What we recommend is using a SaaS discovery tool or conducting a thorough review of SSO logs and expense reports to identify every cloud service in use. Shadow IT is not an excuse auditors accept.

Missing exit strategies. Even organizations with strong acquisition and management processes rarely document exit plans until prompted. Auditors flag this consistently.

Stale supplier assessments. Initial assessments are completed during onboarding, but periodic reassessments do not happen. What we tell clients is to build assessment due dates into your compliance calendar so they become routine operational tasks.

No shared responsibility documentation. Organizations assume cloud providers handle security without mapping exactly what the provider covers and what remains their responsibility. This gap is particularly common with PaaS and SaaS services.

Configuration drift. Secure configurations are established at deployment but are not monitored for drift over time. In our experience, implementing automated cloud security posture management (CSPM) tools addresses this gap effectively for IaaS environments.

How Control 5.23 Connects to Your Broader ISMS

Control 5.23 does not exist in isolation. It feeds into and draws from several other areas of your information security management system:

• Risk assessment (Clause 6.1.2): Cloud-specific risks identified through supplier assessments should be recorded in your risk register and treated through your standard risk management process.
• Supplier relationships (Control 5.19-5.22): Control 5.23 is part of the broader supplier management control family. Your cloud service governance should align with your general supplier management framework.
• Statement of Applicability: Your SoA should reference Control 5.23 and describe how it is implemented, linking to the cloud security policy and supplier assessment process.
• Internal audit: Include cloud service governance in your internal audit program to verify ongoing compliance and identify improvement opportunities before the certification audit.

Key Takeaways

• Control 5.23 requires a structured approach across four phases — acquisition, use, management, and exit — for every cloud service your organization relies on.
• What we recommend is maintaining a cloud service register as your central compliance artifact, because it is the first document auditors request and it anchors every other piece of evidence.
• In our experience, the most common gaps are incomplete cloud inventories, missing exit plans, and stale supplier assessments — all of which are preventable with calendar-driven processes.
• A tiered supplier assessment approach lets you allocate effort proportionally to risk, which is both operationally efficient and exactly what auditors expect.
• Cloud service governance connects directly to your risk register, Statement of Applicability, and broader supplier management program — treat it as integrated, not standalone.
• What we tell clients is that getting this control right is not just about passing an audit; it is about building genuine visibility into where your data lives and how it is protected across your entire cloud ecosystem.