ISO 27001 Information Security for Use of Cloud Services
ISO 27001 Annex A 5.23 Information security for use of cloud services is an ISO 27001 control that requires an organisation to specify and manage information security for the use of cloud services.
It means you must have a system to handle the information security risks of your third party cloud systems, products and services.
Table of contents
- ISO 27001 Information Security for Use of Cloud Services
- Key Takeaways
- Purpose
- Definition
- Requirement
- Audit Focus
- FREE Training Video
- Implementation Guide
- Cloud Services Security Policy Template
- How to write a Cloud Security Policy
- How to implement ISO 27001 Annex A 5.23
- Responsibility Matrix Example
- How to comply
- How to Audit ISO 27001 Annex A 5.23
- ISO 27001 Templates
- How to pass the audit
- What the auditor will check
- Top 3 Mistakes People Make and How to Avoid Them
- Applicability across different business models
- Applicable Laws and Related Standards
- FAQ
- Related ISO 27001 Controls and Further Reading
- ISO 27001 Controls and Attribute Values
- About the author
Key Takeaways
ISO 27001 Annex A 5.23 is a new control introduced in the 2022 update that specifically requires organisations to manage the information security risks of third-party cloud systems, products, and services. The core objective is to move beyond generic supplier management and address the unique nature of the cloud, where agreements are often non-negotiable and security responsibilities are shared between the provider and the customer. This “preventive” control ensures you have a structured approach for the Acquisition, Use, Management, and Exit of cloud services.
Purpose
The purpose of ISO 27001 Annex A 5.23 is a preventive control that ensures you specify and manage information security for the use of cloud services.
Definition
The ISO 27001 standard defines ISO 27001 Annex A 5.23 as:
Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organisation’s information security requirements.
ISO27001:2022 Annex A 5.23 Information security for use of cloud services
ISO 27001 Annex A 5.23 Information Security for Use of Cloud Services is a security control that mandates managing third-party cloud risks throughout their lifecycle. Organizations must define security requirements to ensure shared responsibility governance, providing the business benefit of continuous data protection and regulatory compliance across virtualized environments.
Requirement
- Cloud Security Policy: You must implement a topic-specific policy that defines your organization’s requirements for cloud security, including data residency, encryption, and access controls.
- Shared Responsibility Awareness: Compliance requires a clear understanding of the “Shared Responsibility Model.” You must document which security tasks the provider handles (e.g., physical data center security) and which tasks you remain accountable for (e.g., IAM, data encryption).
- Vetting & Onboarding: Cloud providers must be vetted before use. Since most cloud contracts (AWS, Google, Microsoft) are non-negotiable, you must review their third-party assurance reports (e.g., SOC 2 Type II or ISO 27001 certificates) to ensure they meet your risk appetite.
- Exit Strategy: You must have a defined process for “exiting” a cloud service. This includes how you will retrieve your data and ensure it is securely deleted from the provider’s systems at the end of the contract.
- Continuous Monitoring: Cloud security is not static. You must regularly monitor your cloud suppliers for changes in their service, sub-processors, or jurisdictional compliance.
Audit Focus
- Cloud Register: “Show me your inventory of all cloud services (SaaS, IaaS, PaaS) currently in use. Who is the internal owner for each?”
- Assurance Verification: “Pick your most critical SaaS provider. Show me their current security certification. When did you last verify it was still valid?”
- Data Disposal: “If you stopped using this cloud tool tomorrow, how do you ensure 100% of your customer data is deleted from their servers?”
FREE Training Video
In this free training video you will learn How to implement ISO 27001 Information Security Of Cloud Services (Annex A 5.23) & Pass Your Audit.
Implementation Guide
Cloud services can be treated to all intents and purposes like any supplier. The standard calls them out, because, in some ways it feels like they felt they had to. It gives a list of requirements that are unrealistic and then acknowledges it is unlikely you can meet them.
Before we look at what you can do let us paraphrase what the standard thinks as the get out.
It absolutely acknowledges that yes, cloud service agreements are pre defined and not open to negotiation on the whole. So why give a list of requirements? Who knows. This is about basic good practice of supplier management. They could have said that. But they did not.
You will ensure
- ISO 27001 Annex A 5.21 Managing Information Security In The ICT Supply Chain
- ISO 27001 Annex A 5.22 Monitor, Review And Change Management Of Supplier Services
Cloud Services Security Policy Template
The cloud services security policy sets out your approach to cloud supplier security.

How to write a Cloud Security Policy
For a deeper understanding of the ISO 27001 Cloud Security Policy see the ultimate guide: Cloud Security Policy: Ultimate Guide (+ template)

How to implement ISO 27001 Annex A 5.23
Implementing ISO 27001 Annex A 5.23 requires a strategic shift from managing physical infrastructure to governing virtualised environments and shared responsibility models. As a Lead Auditor, I look for evidence that you have defined clear security requirements for your cloud providers and that those requirements are consistently monitored throughout the service lifecycle. Follow these ten steps to secure your use of cloud services and satisfy the requirements of the 2022 standard update.
1. Establish a Cloud Security Policy
- Define the organisational rules for the acquisition, use, and management of cloud services to ensure a consistent security posture.
- Specify the types of data permitted in different cloud environments, such as Public, Private, or Hybrid, based on data classification levels.
- Document the roles and responsibilities for both the organisation and the cloud service provider within a formal policy framework.
2. Build a Comprehensive Cloud Asset Register
- Identify and record every SaaS, PaaS, and IaaS solution used across the business to eliminate “Shadow IT” risks.
- Link each cloud service to an internal Service Owner who is accountable for the security and performance of that specific platform.
- Include technical metadata such as data residency locations, primary IAM administrators, and the criticality of the service to business operations.
3. Conduct Pre-Onboarding Security Risk Assessments
- Evaluate the security capabilities of prospective cloud providers against organisational requirements before any contracts are signed.
- Review independent assurance reports, such as SOC 2 Type II or ISO 27001 certificates, to verify the provider’s claims of security effectiveness.
- Identify potential security gaps in the provider’s infrastructure and document how these will be mitigated through internal controls.
4. Formalise Cloud Service Agreements
- Provision specific information security requirements into contractual agreements to ensure the provider is legally bound to your standards.
- Include clauses regarding data breach notification timelines, the “Right to Audit”, and the return or destruction of data upon termination.
- Ensure the shared responsibility model is explicitly documented, defining exactly where the provider’s security duties end and yours begin.
5. Provision Identity and Access Management (IAM) Roles
- Configure granular IAM roles based on the principle of least privilege to ensure users only access the specific resources required for their job.
- Enforce Multi-Factor Authentication (MFA) for all administrative and privileged accounts to prevent unauthorised access to cloud consoles.
- Review access logs and user permissions quarterly to identify and revoke dormant or over-privileged accounts.
6. Enforce Data Encryption and Protection
- Authorise the use of industry-standard encryption protocols for data at rest and data in transit within the cloud environment.
- Establish secure key management procedures, ensuring that the organisation maintains control over encryption keys where technically feasible.
- Verify that cloud-native backup solutions are configured and tested periodically to ensure data availability and resilience.
7. Implement Cloud Monitoring and Alerting
- Set up automated monitoring for security-relevant events, such as changes to firewall rules, bucket permissions, or administrative logins.
- Ingest cloud audit logs into a central Security Information and Event Management (SIEM) tool for real-time analysis and alerting.
- Define technical thresholds for security alerts to ensure the incident response team is notified of potential threats immediately.
8. Authorise Cloud Service Change Management
- Formalise a process to monitor and assess changes made by the cloud provider, such as updates to their software or changes in data hosting locations.
- Evaluate the impact of provider-side changes on your existing security controls and update your internal configurations accordingly.
- Document any significant changes in your internal Change Management system to maintain a clear audit trail of the cloud environment’s evolution.
9. Standardise Joint Incident Response Procedures
- Establish clear communication channels and Rules of Engagement (ROE) for managing security incidents that involve the cloud provider’s infrastructure.
- Identify the specific technical triggers that require the provider to notify you of a potential compromise.
- Integrate cloud-specific recovery steps into your Business Continuity and Disaster Recovery (BCDR) plans to ensure rapid restoration of services.
10. Validate Cloud Exit and Transition Plans
- Develop a formal exit strategy for critical cloud services to prevent vendor lock-in and ensure business continuity during provider failure.
- Define the technical requirements for data portability, ensuring that data can be extracted and migrated to an alternative provider securely.
- Verify that the provider issues a certificate of destruction for organisational data once the contract has been terminated and the transition is complete.
Hello. I am Stuart Barker.
CEO here at High Table: The Compliance Agency
If you want help by the hour, internal audit or consulting support …

Responsibility Matrix Example
| Layer | Responsibility | SaaS (e.g., Salesforce) | IaaS (e.g., AWS EC2) |
| Physical Data Center | Provider | Salesforce | AWS |
| OS Patching | Provider | Salesforce | You (Customer) |
| Network Security | Shared | Salesforce | You (Firewall Rules) |
| User Access (IAM) | You | You (MFA/SSO) | You (MFA/SSO) |
| Data Encryption | You | You (Enable Key) | You (Manage Keys) |
How to comply
To comply with ISO 27001 Annex A 5.23 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to include Cloud Services in supplier management and:
- Implement a topic specific policy
- Implement a supplier management process
- Include in your supplier management process supplier acquisition and supplier transfer
- Implement an ISO 27001 supplier register
- Have agreements with all suppliers that cover information security requirements
- Have information security assurances for critical suppliers as a minimum and ideally all relevant suppliers
- Monitor those suppliers
- Respond to adverse incidents in a structured way
How to Audit ISO 27001 Annex A 5.23
Auditing the security of cloud services requires a shift from physical perimeter checks to logical governance and shared responsibility verification. As a Lead Auditor, I expect to see that you have not simply outsourced your risk to the provider, but have actively managed the lifecycle of every SaaS, PaaS, and IaaS solution. Use these ten steps to audit your compliance with ISO 27001 Annex A 5.23.
1. Examine the Cloud Security Policy
- Verify that a specific policy exists for the acquisition, use, and management of cloud services.
- Confirm the policy defines clear security requirements based on the classification of data being hosted.
- Ensure the policy has been approved by management and communicated to all relevant stakeholders.
2. Validate Cloud Selection and Risk Assessments
- Inspect the Risk Register to confirm that a formal risk assessment was conducted prior to onboarding each cloud provider.
- Check the selection criteria to ensure that security capabilities were a weighted factor in the procurement process.
- Review evidence of due diligence, such as a completed Consensus Assessments Initiative Questionnaire (CAIQ) or CSA STAR entry.
3. Scrutinise Cloud Service Agreements
- Review contracts to ensure they include specific information security requirements, such as data residency and sub-processor transparency.
- Confirm the presence of a “Right to Audit” clause or a commitment to provide independent assurance reports.
- Verify that Service Level Agreements (SLAs) include security-related KPIs, such as incident notification timelines.
4. Audit IAM Roles and Access Configuration
- Inspect Identity and Access Management (IAM) configurations to verify the implementation of the principle of least privilege.
- Confirm that Multi-Factor Authentication (MFA) is enforced for all administrative and privileged cloud accounts.
- Review the process for revoking access, ensuring that leavers are removed from cloud platforms immediately.
5. Verify Encryption and Key Management
- Check that data is encrypted at rest and in transit using industry-standard protocols.
- Inspect the Key Management Service (KMS) logs to ensure that organisational encryption keys are managed securely.
- Validate that the organisation maintains control over its own keys where a “Bring Your Own Key” (BYOK) model is used.
6. Evaluate Monitoring and Incident Response
- Verify that cloud logs, such as AWS CloudTrail or Azure Activity Logs, are being ingested into a central monitoring system.
- Confirm that specific alerts are configured for high-risk activities, such as changes to bucket permissions or firewall rules.
- Review evidence of a joint incident response test conducted with the cloud provider or involving cloud-hosted assets.
7. Confirm Shared Responsibility Alignment
- Inspect the documented Shared Responsibility Model for each primary cloud service provider.
- Confirm that the organisation has identified and implemented the security controls for which it is responsible.
- Verify that there are no “control gaps” where neither the provider nor the organisation has taken ownership of a security task.
8. Assess Technical Vulnerability Management
- Verify that regular vulnerability scans are performed on cloud-hosted infrastructure and applications.
- Review Rules of Engagement (ROE) documents for any penetration tests performed on cloud environments.
- Confirm that identified vulnerabilities are patched within the timeframes defined in the organisational policy.
9. Test Cloud Exit and Data Portability
- Inspect the documented exit strategy for critical cloud services to ensure business continuity.
- Confirm that the plan includes procedures for the secure return or certified destruction of organisational data.
- Verify that data portability has been considered to prevent vendor lock-in during a migration or service failure.
10. Validate Third-Party Compliance Reports
- Scrutinise the latest independent audit reports, such as SOC 2 Type II or ISO 27001 certificates, for all critical providers.
- Check that the scope of these reports covers the specific regions and services used by your organisation.
- Verify that any “Complementary User Entity Controls” (CUECs) mentioned in SOC reports have been implemented internally.
ISO 27001 Templates

How to pass the audit
To pass an audit of ISO 27001 Annex A 5.23 Information security for use of cloud services you are going to make sure that you have supplier management that also covers cloud services and that you have followed the steps above in how to comply.
What the auditor will check
The audit is going to check a number of areas. Lets go through the most common
1. That you have a cloud supplier agreements in place
The auditor is going to check that you have agreements in place with cloud suppliers that cover the information security requirements. It will check that those agreements are in date and cover the products and / or services acquired.
2. That you have an ISO 27001 Cloud Supplier Register
You will need an ISO 27001 Supplier Register to record and manage your cloud suppliers. Make sure it is up to date and reflects your reality.
3. Documentation
They are going to look at audit trails and all your documentation and see that is classified and labelled. All the documents that you show them, as a minimum if they are confidential should be labelled as such. Is the document up to date. Has it been reviewed in the last 12 months. Does the version control match.
Top 3 Mistakes People Make and How to Avoid Them
The top 3 Mistakes People Make For ISO 27001 Annex A 5.23 are
1. You have do not monitor cloud suppliers
Make sure that there are reviews and monitors in place. Perhaps meetings. Perhaps reports. Perhaps dashboards. Be sure to be able to evidence that you review and monitor those suppliers. You will have processes for adverse advents so do not be surprised if you are asked to evidence an adverse event, problem or issue and that you followed your process.
2. You have no assurance they are doing the right thing for information security
Make sure you have done your security assessment and can place your hands on an in date certificate such as an ISO 27001 Certification for assurance they are doing the right thing. It needs to be in date a cover the products and / or services you have acquired and are using form the supplier.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
Applicability across different business models
| Business Type | Applicability & Interpretation | Examples of Control |
|---|---|---|
| Small Businesses |
Configuring SaaS Correctly. You cannot audit giants like Microsoft or Google. Compliance focuses on selecting reputable providers and configuring the security settings (Shared Responsibility) you control. |
• MFA Enforcement: Turning on Multi-Factor Authentication for all Office 365/Google Workspace users. • Offboarding: Removing access to cloud CRM/Accounting tools immediately when staff leave. |
| Tech Startups |
Managing the IaaS Gap. While AWS/Azure secure the physical data center, you are responsible for everything “in” the cloud (OS, Data, Firewall). Auditors check if you understand this boundary. |
• Cloud Register: Maintaining an inventory of all cloud services (IaaS, PaaS) with assigned internal owners. • Security Groups: Reviewing AWS/Azure firewall rules to ensure databases are not exposed to the public internet. |
| AI Companies |
API & Data Sovereignty. Critical focus on where training data flows. Ensuring third-party AI APIs (e.g., OpenAI, Anthropic) do not retain your data for their own model training. |
• Zero-Retention Agreements: configuring API settings to “Opt-Out” of model training on your inputs. • Regional Locking: Ensuring GPU cloud providers process data only within agreed jurisdictions (e.g., EU-only) to satisfy GDPR. |
Applicable Laws and Related Standards
| Standard / Law | Regulatory Requirement and Control Relationship |
|---|---|
| UK Data (Use and Access) Act 2025 | The UK’s evolution of GDPR. Annex A 5.23 is critical for ensuring that “reduced administrative burdens” do not compromise data residency requirements or the security of automated data processing in the cloud. |
| Cyber Security and Resilience Bill (UK) | The UK’s answer to NIS2. This bill expands mandatory reporting for Managed Service Providers (MSPs). 5.23 ensures you have the contractual hooks to force cloud providers to report incidents to you so you can meet the regulator’s window. |
| DORA (Digital Operational Resilience Act) | DORA mandates strict “ICT Third-Party Risk” management for the financial sector. 5.23 satisfies the requirements for cloud service registers, termination rights, and the monitoring of “critical” third-party providers. |
| NIST Cybersecurity Framework (CSF) 2.0 | Maps directly to GV.SC (Supply Chain Risk Management) and PR.DS (Data Security). Annex A 5.23 provides the operational controls to implement NIST’s requirements for protecting data throughout the cloud lifecycle. |
| SOC2 (Trust Services Criteria) | Relates specifically to the Common Criteria (CC series) for Availability and Processing Integrity. 5.23 provides the audit evidence (Cloud Risk Assessments, SLAs) that SOC2 auditors require to verify “System and Organization Controls.” |
| CIRCIA (USA) | Mandatory 72-hour reporting for critical sectors. Annex A 5.23 ensures that your cloud incident response protocols are aligned with the provider, allowing for the rapid data collection needed for CISA reporting. |
| EU AI Act / ISO 42001 | As AI models are almost exclusively cloud-hosted, 5.23 is the primary control for auditing the “Compute” layer. It ensures that the cloud infrastructure supporting AI meets high-risk system thresholds for robustness and data governance. |
| ECCF (European Cybersecurity Certification Framework) | This framework moves toward harmonised security labels. 5.23 is used to verify and monitor that your cloud provider maintains their EUCS (EU Cybersecurity Certification Scheme for Cloud Services) status. |
| EU Product Liability Directive (PLD) Update | Extends strict liability to software/cloud providers. 5.23 acts as your “due diligence” shield, proving you conducted regular security reviews and patched vulnerabilities within the cloud shared responsibility model. |
| HIPAA (Health Insurance Portability and Accountability Act) | Requires a Business Associate Agreement (BAA) with cloud providers. 5.23 provides the mechanism for auditing the provider’s technical safeguards for protected health information (PHI). |
| CCPA / CPRA (California Data Laws) | These laws require “reasonable security procedures.” 5.23 formalises the monitoring of cloud “Service Providers” to ensure they do not “sell” or “share” personal information outside of contractual instructions. |
| GDPR (General Data Protection Regulation) | Focuses on Article 28 (Processor requirements) and Article 32 (Security of processing). 5.23 is the operational control that ensures cloud processors maintain adequate security and handle data transfer (SCCs/IDTA) correctly. |
FAQ
To comply with Annex A 5.23, organisations must formalise security requirements within their contracts and maintain a “Topic-Specific Policy on Cloud Services.”
Perform a risk assessment on every cloud service provider (CSP).
Define and agree upon the Shared Responsibility Model.
Implement monitoring for service changes or security incidents within the cloud.
Establish technical requirements for data residency and encryption.
The Shared Responsibility Model is the framework that defines which security controls are managed by the cloud provider (e.g., physical security) and which are the responsibility of the organisation (e.g., IAM).
Provider: Responsible for the security of the cloud (Infrastructure, Hardware).
Customer: Responsible for security in the cloud (Data, Identity, Configurations).
Audit Requirement: You must document this split to prove you aren’t neglecting “customer-side” configurations.
A Cloud Service Agreement must explicitly state security obligations, right-to-audit clauses, and data handling requirements to meet ISO 27001 standards.
Service Level Agreements (SLAs) for availability and performance.
Specific incident notification timeframes in the event of a breach.
Transparency regarding sub-contractors and secondary processors.
Security measures for data at rest and data in transit.
Yes, Annex A 5.23 requires organisations to have a formalised exit strategy to ensure data can be migrated or deleted securely when a service is terminated.
Definition of data portability and transfer formats.
Verification processes for the secure deletion of data from provider systems.
Business continuity planning for service transition.
Return of intellectual property and assets.
Monitoring is achieved through regular reviews of provider audit reports (such as SOC 2 or ISO 27001 certificates) and continuous tracking of service changes.
Annual review of the provider’s independent security certifications.
Monitoring for changes in data hosting locations or jurisdictions.
Tracking of administrative access and privileged user logs.
Reviewing vulnerability disclosure reports from the provider.
Yes, while major providers like AWS and Azure are ISO 27001 certified, your organisation is still responsible for securing the specific configurations and data you host on their platforms.
Infrastructure is covered by the provider’s certification.
Virtual network, OS hardening, and app security are your responsibility.
Auditors will check your “Security Groups” and “IAM Roles” regardless of the provider’s status.
Related ISO 27001 Controls and Further Reading
ISO 27001 Cloud Security Policy: Explained + Template
ISO 27001 Controls and Attribute Values
| Control type | Information security properties | Operational capabilities | Security domains |
|---|---|---|---|
| Preventive | Confidentiality | Supplier relationships security | Protection |
| Integrity | Governance and ecosystem | ||
| Availability |
About the author

