ISO 27001 Information Security for Use of Cloud Services | Annex A 5.23 | The Lead Auditor’s Implementation and Audit Guide

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.

In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.23 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Key Takeaways: ISO 27001 Annex A 5.23 Information Security for Use of Cloud Services

ISO 27001 Annex A 5.23 is a new control introduced in the 2022 update that specifically requires organizations 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.

Core requirements for compliance include:

• 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: Auditors will look for “The Shared Responsibility Gap”:

1. Cloud Register: “Show me your inventory of all cloud services (SaaS, IaaS, PaaS) currently in use. Who is the internal owner for each?”
2. Assurance Verification: “Pick your most critical SaaS provider. Show me their current security certification. When did you last verify it was still valid?”
3. Data Disposal: “If you stopped using this cloud tool tomorrow, how do you ensure 100% of your customer data is deleted from their servers?”

Shared Responsibility Matrix (Audit Prep):

Security Layer	Responsibility	SaaS (e.g., Salesforce)	IaaS (e.g., AWS EC2)	ISO 27001:2022 Control
Physical Security	Provider.	Provider Managed.	Provider Managed.	Annex A 5.23 / 7.1
OS Patching	Shared	Provider Managed.	You (Customer)	Annex A 5.23 / 8.8
Network Config	Shared	Provider Managed.	You (Firewall Rules)	Annex A 5.23 / 8.22
User Access (IAM)	YOU	You (MFA/SSO).	You (MFA/SSO).	Annex A 5.23 / 8.15
Data Encryption	YOU	You (Enable Key).	You (Manage Keys).	Annex A 5.23 / 8.24

What is ISO 27001 Annex A 5.23?

ISO 27001 Annex A 5.23 is information security in the use of cloud services means you must have a system to handle the information security risks of your third party cloud systems, products and 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.

ISO 27001 Annex A 5.23 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.

ISO 27001 Annex A 5.23 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

Watch the ISO 27001 Annex A 5.23 Tutorial

In the video ISO 27001 Information Security For Use Of Cloud Services Explained – ISO27001:2022 Annex A 5.23 I show you how to implement it and how to pass the audit.

ISO 27001 Annex A 5.23 Podcast

In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.23 Information Security For Use Of Cloud Services. The podcast explores what it is, why it is important and the path to compliance.

ISO 27001 Annex A 5.23 Implementation Guidance

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

Follow good third party supplier management as previously covered including risk management and if at any point you are worried seek additional guidance from the standard which will guide you and then say, but we appreciate this cannot be done.

Cloud Service Agreements

I am not even going to cover what the standard thinks should be in cloud service agreements as already stated, the standard acknowledges that these are non negotiable and you take what the cloud service providers gives you. If you are interested, refer to your copy of the ISO 27002 standard.

How to implement ISO 27001 Annex A 5.23

Responsibility Matrix

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 write a Cloud Security Policy

A step-by-step tutorial on how to create a cloud security policy for ISO 27001 in under 10 minutes. I walk you through the process of creating a policy, including what to include in the policy and how to comply with the ISO 27001 standard.

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

ISO 27001 Cloud Security Policy Template

The ultimate ISO 27001 Cloud Security Policy Template.

ISO 27001 Cloud Security Register Template

The ultimate ISO 27001 Supplier Register Template to record and manage your cloud suppliers.

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

How to pass the ISO 27001 Annex A 5.23 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 ISO 27001 Annex A 5.23 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 of ISO 27001 Annex A 5.23 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.

Fast Track ISO 27001 Annex A 5.23 Compliance with the ISO 27001 Toolkit

For ISO 27001 Annex A 5.23 (Information security for use of cloud services), the requirement is to establish processes for the acquisition, use, management, and exit from cloud services. Since cloud providers are typically non-negotiable in their terms, the focus is on managing the shared responsibility model and ensuring you have an exit strategy.

Compliance Factor	SaaS Compliance Platforms	High Table ISO 27001 Toolkit	Audit Evidence Example
Strategy Ownership	Rents access to your cloud rules; if you cancel the subscription, your documented exit plans and responsibility definitions vanish.	Permanent Assets: Fully editable Word/Excel Cloud Security Policies and Registers that you own forever.	A localized “Cloud Security Policy” defining your organization’s specific exit strategy for critical IaaS providers.
Governance Utility	Attempts to “automate” cloud security via APIs that cannot decide your risk appetite or verify internal IAM rule adherence.	Governance-First: Formalizes your existing use of AWS, Azure, or Google Cloud into an auditor-ready framework.	A completed “Cloud Responsibility Matrix” proving you have identified which security tasks are yours vs. the provider’s.
Cost Efficiency	Charges an “API Integration Tax” based on the number of connected cloud tools, creating perpetual overhead as your stack grows.	One-Off Fee: A single payment covers your cloud governance for 5 SaaS/IaaS tools or 50.	Allocating budget to advanced cloud encryption or redundant backup services rather than monthly dashboard fees.
Architectural Freedom	Mandates rigid reporting formats that often fail to account for serverless architectures or specialized multi-cloud setups.	100% Agnostic: Procedures adapt to any environment—pure SaaS, complex hybrid, or niche private cloud—without limits.	The ability to evolve your cloud strategy (e.g., migrating from Azure to AWS) without reconfiguring a rigid SaaS module.

Summary: For Annex A 5.23, the auditor wants to see that you are actively monitoring your suppliers and have a process for managing changes to their services. The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.

ISO 27001 Annex A 5.23 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.

ISO 27017 vs. Annex A 5.23: What You Actually Need to Know

If you want to do this properly, you need to understand that Annex A 5.23 is the “what” but ISO 27017 is the “how.” ISO 27017 is the code of practice for information security controls specifically for cloud services. While 5.23 tells you to manage cloud risk, ISO 27017 gives you the technical granular detail. For example, it includes specific requirements for how assets should be returned or deleted when you leave a cloud provider. If you are a high-growth tech company or a SaaS provider yourself, you should be looking at the 7 additional cloud-specific controls in ISO 27017 to truly satisfy a rigorous auditor.

The Cloud Exit Readiness Checklist

One of the biggest mistakes I see during audits is a “wishful thinking” exit strategy. Annex A 5.23 explicitly requires a process for exiting cloud services. You cannot just say “we will move to another provider.” You need evidence. Use this checklist to ensure your exit strategy actually works:

• Data Portability: Have you verified that your data can be exported in a non-proprietary format like CSV or JSON?
• Backup Independence: Do you have a copy of your cloud data stored outside of that provider’s specific ecosystem?
• Transition Assistance: Does your contract or legal agreement specify a period where the vendor must help you migrate data after termination?
• Secure Deletion: Do you have a way to verify that the provider has actually wiped your data once you have left?

How to Vet the “Big Three” Providers

You aren’t going to negotiate with Amazon or Microsoft. We know that. But you still have to prove you checked them. For AWS, you need to log into AWS Artifact to download their latest SOC 2 and ISO 27001 reports. For Azure, you go to the Microsoft Service Trust Portal. For Google Cloud, use their Cloud Risk Assessment Tool. An auditor will ask to see these reports, not just a link to their marketing page. Download them, review the “User Entity Controls,” and file them in your evidence folder.

The Shadow IT Discovery Workflow

You cannot secure what you do not know about. Most organizations have a massive “Shadow IT” problem where departments buy SaaS tools without telling IT. To comply with Annex A 5.23, you need a robust discovery process:

• Financial Audit: Review company credit card expenses for recurring payments to unknown software vendors.
• SSO Logs: Check your Okta or Azure AD logs for applications that users are logging into that aren’t on your official register.
• Browser Extensions: If you use a managed browser environment, audit the extensions and third-party apps that have been granted permissions to access corporate data.

10 Must-Ask Questions for Cloud Vendors

When you are onboarding a new cloud service, do not just send a 200-page spreadsheet they won’t fill in. Ask these 10 targeted questions to satisfy Annex A 5.23:

1. Can you provide a current ISO 27001 certificate or SOC 2 Type II report?
2. Which specific geographic regions will our data be stored in?
3. Do you use sub-processors, and can we see a list of them?
4. How do you notify customers of a data breach, and what is the timeframe?
5. Is data encrypted at rest and in transit using industry-standard protocols?
6. How is our data logically separated from your other customers?
7. What is your process for managing administrative access to your backend systems?
8. How often do you perform independent penetration testing?
9. What are the technical steps for us to retrieve our data if we cancel?
10. Can you provide a certificate of secure data destruction upon request?

ISO 27001:2013 vs. 2022 Mapping

If you are upgrading your ISMS, you need to know where the old controls went. Annex A 5.23 is a new, dedicated control that pulls the “Cloud” elements out of the old A.15 (Supplier Relationships) and makes them much more specific. In the 2013 version, cloud security was often buried in general supplier management. In the 2022 update, it is a standalone requirement that demands its own policy and its own set of lifecycle processes from acquisition to exit.

Measuring Success: Metrics and KPIs for Cloud Governance

An auditor does not just want to see a policy; they want to see that the policy is working. If you cannot measure it, you are not managing it. To truly satisfy Annex A 5.23, you should track these three Key Performance Indicators (KPIs) and report them in your Management Review:

• Percentage of “Shadow IT” Discovery: How many new cloud services were identified through discovery tools versus how many were officially onboarded through procurement? A high number of “found” services indicates your onboarding process is broken.
• Assurance Report Currency: What percentage of your critical cloud suppliers have an in-date SOC 2 or ISO 27001 certificate on file? If this is less than 100 percent, you are failing the “Continuous Monitoring” requirement.
• MFA Adoption Rate: For all cloud platforms identified in your register, what percentage have Multi-Factor Authentication enforced for all users? This is the single most important technical metric for cloud security.

Who Does What? The Cloud Security RACI

Confusion is the enemy of compliance. In small teams, one person might do everything, but as you grow, you need a RACI (Responsible, Accountable, Consulted, Informed) matrix to define who handles cloud security tasks. Here is how I expect to see it laid out during an audit:

Task	IT/DevOps	Procurement	CISO/Compliance
Maintaining the Cloud Register	Responsible	Consulted	Accountable
Pre-onboarding Security Vetting	Consulted	Informed	Responsible
Reviewing Cloud Audit Logs	Responsible	N/A	Accountable
Reviewing Provider Certifications	N/A	Informed	Responsible

The 2026 AI Cloud Risk Factor

It is 2026, and you cannot talk about cloud security without talking about AI. Most of your cloud providers have now integrated Large Language Models (LLMs) into their stacks. Under Annex A 5.23, you are responsible for knowing if your data is being used to train those models. You must update your vendor assessments to ask:

• Does the cloud provider use our data for model training?
• Is there an “Opt-Out” mechanism for AI data processing?
• Does the provider comply with ISO 42001 (Artificial Intelligence Management System)?

Audit Interview Prep: What They Will Ask Your Team

I have sat in the auditor’s chair hundreds of times. I don’t just talk to the CISO; I talk to the people doing the work. Here is how to prepare your team for the interview:

To the CTO/Lead Engineer: “Show me how you ensure that a developer doesn’t spin up a new AWS instance and leave an S3 bucket open to the public internet. Is this automated or manual?”

To the Procurement Manager: “If a department wants to buy a new SaaS tool tomorrow, what security questions are they required to ask before you release the funds?”

To the Office Manager: “How do you know when an employee has left the company so you can remove their access to the 50 different SaaS tools we use?”

Training and Awareness for Cloud Users

You can have the best Cloud Security Policy in the world, but if your employees are pasting sensitive customer data into an unapproved AI cloud tool, the policy is useless. You must evidence that you have trained staff on the “Acceptable Use of Cloud Services.” This doesn’t need to be a boring three hour slide deck. A simple ten minute briefing during onboarding that explains which cloud tools are “Approved” and how to request a new one is usually enough to satisfy an auditor.

The “Joint” Incident Response Plan

What happens when the cloud provider goes down? Most people have an Incident Response Plan that assumes they control the hardware. You don’t. Your plan must include specific “Cloud Playbooks” that define:

• Who is our technical contact at the cloud provider?
• Where do we check for their official status updates?
• At what point of a provider outage do we trigger our “Exit” or “Disaster Recovery” plan?

Compliance as Code: Moving Beyond Manual Checks

If you are still relying on manual screenshots to prove your cloud security, you are living in the past. In 2026, auditors expect to see automation. Annex A 5.23 requires you to “manage” cloud services, and the most effective way to do that is through Compliance as Code. This means using tools like Terraform or CloudFormation with built in security linting. If a developer tries to deploy an insecure database, the system should automatically block the pull request. Showing an auditor your “Guardrails” or Cloud Security Posture Management (CSPM) dashboard where these rules are enforced is worth more than a thousand spreadsheets. It proves that security is “Baked In” rather than “Bolted On.”

The Fourth Party Problem: Sub processor Transparency

One area where people consistently fail their audit is in “Fourth Party” risk. Your cloud provider (the Third Party) uses other companies (Sub processors) to deliver their service. Annex A 5.23 and 5.21 demand that you have visibility into this chain. You need to know if your primary SaaS provider has switched their backend from AWS to a smaller, less secure data center in a different jurisdiction. Your Cloud Register must include a link to the provider’s “Sub processor List.” You should review this list annually. If they add a new sub processor that doesn’t meet your risk appetite, that is a trigger for a formal risk review.

Sovereign Clouds and Regional Locking

With the full enforcement of NIS 2 and DORA in 2026, “Data Residency” has evolved into “Data Sovereignty.” It is no longer enough to just tick a box saying your data is in the UK or EU. Auditors now look for “Regional Locking” configurations. This is where you technically restrict your cloud tenant so that it is physically impossible to spin up resources outside of your approved region. If you are handling highly sensitive government or financial data, you might even need to evidence the use of a “Sovereign Cloud” where the provider’s support staff are also limited to specific jurisdictions. This is a level of technical depth that separates a “Pass” from a “Distinction” in an audit.

Proving Operating Effectiveness: The “Fail Test”

A “Design” check is Stage 1. An “Operating Effectiveness” check is Stage 2. An auditor will ask you to prove your cloud controls actually work. I recommend performing a “Fail Test” as part of your internal audit. Try to create a public S3 bucket or a user account without MFA. If your system blocks you and generates an alert in your SIEM or Slack, that is your “Golden Evidence.” Take a screenshot of the blocked action and the resulting alert. This proves to the auditor that your controls are active and self healing, which is exactly what Annex A 5.23 is looking for in a mature organization.

How to Write Your SoA Justification for 5.23

The Statement of Applicability (SoA) is the first thing I look at. For Annex A 5.23, your justification for inclusion needs to be specific. Do not just write “We use cloud services.” Instead, write something like: “Applicable. We utilize IaaS (AWS) for core infrastructure and multiple SaaS platforms for business operations. This control is implemented through our Cloud Security Policy, monthly CSPM reviews, and a formal vendor onboarding process that includes the review of SOC 2 reports.” This level of detail shows the auditor that you actually understand why the control is there and how it fits into your specific business model.

Budgeting for Compliance: The “Hidden” Costs

Compliance with Annex A 5.23 is not free. You need to budget for the tools and people required to manage it. This includes the cost of “Advanced” tiers of SaaS products that allow for SSO and MFA integration, the cost of CSPM tools, and the time required for your legal team to review Data Processing Agreements (DPAs). If your budget only covers the “Starter” tier of a software tool that doesn’t allow for centralized security management, you are going to have a very hard time passing your audit. I always tell my clients that “Cheap Cloud” is often “Expensive Compliance.”

The AI Shared Responsibility Gap: Who Owns the Model?

When you use a cloud AI service, the “Shared Responsibility Model” gets a lot more complicated. In a standard cloud audit, we look at the OS and the Data. In an AI audit, we have a third layer: the Model. Under Annex A 5.23, you must define who is responsible for model integrity. If you are using a “Model as a Service” (MaaS) provider like OpenAI or Anthropic, they secure the weights, but you are responsible for the system prompts and the output filtering. If you are fine-tuning a model on AWS SageMaker, the “Base Model” is their problem, but the “Tuned Weights” and the “Training Pipeline” are yours. Auditors in 2026 will check if your responsibility matrix explicitly separates “Infrastructure,” “Model Weights,” and “Inference Data.”

Vetting AI Cloud Providers: Beyond the SOC 2

A standard SOC 2 report tells me a provider has a firewall. It doesn’t tell me if they are using your prompts to train their next global model. To comply with Annex A 5.23 for AI, your vetting process must include “Data Opt-Out” verification. You need to evidence that you have toggled the specific API settings—or signed the specific Enterprise Agreement—that prevents your proprietary data from leaking into the provider’s public training set. In 2026, I look for the Zero Retention Policy in your vendor contracts as primary evidence of cloud security for AI.

Shadow AI: The New Frontier of Annex A 5.23

We have already talked about Shadow IT, but “Shadow AI” is more dangerous because it is invisible to network logs. Employees are often “pasting” confidential company data into unapproved, free-tier browser-based AI tools. Your discovery workflow must specifically look for these AI-specific leak points. I want to see that your web filtering blocks unapproved AI domains and that your “Acceptable Use Policy” has been updated to explicitly define which AI cloud services are authorized and which are banned. If your staff is using a free “PDF to AI Summary” tool that isn’t on your register, you have a massive Annex A 5.23 non-conformity waiting to happen.

The ISO 42001 “Handshake”: Security vs. Governance

By now, you have probably heard of ISO 42001 (the AI Management System). While Annex A 5.23 focuses on the security of the cloud service, ISO 42001 focuses on the trustworthiness of the AI. For a skyscraper-level ISMS, you need these two standards to “handshake.” Use Annex A 5.23 to secure the cloud pipeline (encryption, IAM, logging) and use ISO 42001 to govern the data quality and bias. If you can show an auditor that your cloud vetting includes an “AI System Impact Assessment” (from ISO 42001), you are demonstrating a level of maturity that puts you in the top 1 percent of certified organizations.

Mapping Annex A 5.23 to the EU AI Act 2026

As of 2026, the EU AI Act is fully applicable. If you are using “High-Risk” AI cloud services, Annex A 5.23 is your primary tool for legal compliance. The Act requires “Technical Documentation” and “Logging.” You satisfy this by using 5.23 to mandate that your cloud provider gives you access to Inference Logs and Model Cards. If your provider cannot provide the documentation required by the EU AI Act, they are a high-risk supplier, and your Annex A 5.23 risk assessment should reflect that. You cannot be “compliant” with the law if your cloud provider is a “black box.”

Adversarial Testing in the Cloud

Traditional vulnerability scanning doesn’t work on AI. You cannot “Nessus scan” an LLM. For Annex A 5.23, I expect to see that you have considered “Adversarial Risk.” This means testing your cloud AI implementation for Prompt Injection or Data Poisoning. If you are using a third-party AI API, show me the “System Prompt” hardening you have implemented. Evidence of a “Red Teaming” exercise on your cloud AI interface is the “Golden Evidence” for 2026 audits.

ISO 27001 Annex A 5.23 FAQ

Related ISO 27001 Controls and Further Reading

Related ISO 27001 Control	Audit Context and Relationship
ISO 27001 Annex A 5.19 Information Security in Supplier Relationships	Annex A 5.23 is a specific, high-risk subset of this control. While 5.19 sets the general policy for all vendors, 5.23 addresses the unique technical risks of cloud environments, such as multi-tenancy and the shared responsibility model.
ISO 27001 Annex A 5.20 Addressing Information Security within Supplier Agreements	You cannot secure a cloud service without a contract. This control provides the legal “Right to Audit” and the specific security clauses that must be present in your cloud Service Level Agreements to satisfy the requirements of 5.23.
ISO 27001 Annex A 5.21 Managing Information Security in the ICT Supply Chain	Cloud services often rely on complex sub-processors. This control focuses on the transparency of that chain, ensuring you understand where your data actually sits even if your primary cloud provider moves it between regions or vendors.
ISO 27001 Annex A 5.22 Monitor, Review and Change Management of Supplier Services	This is the operational governance for cloud security. It ensures that once a cloud service is onboarded under 5.23, you continue to monitor its performance, review its security certifications, and manage any technical changes to its configuration.
ISO 27001 Annex A Controls List	The master directory for all 93 controls in the 2022 standard. It provides the structural context for how cloud security integrates with other technical controls like logging, encryption, and network security.
ISO 27001 Toolkit	The practical implementation layer. This toolkit provides the specific Cloud Risk Assessment templates and Supplier Registers needed to document the due diligence required by auditors for Annex A 5.23.
ISO 27001 for AI Companies	AI models are almost exclusively cloud-hosted. This page bridges the gap between standard cloud governance and the specific compute and data privacy requirements found in high-performance AI environments.
ISO 27001 for Tech Startups	For SaaS-first startups, Annex A 5.23 is often the most critical control in the entire standard. This guide explains how to implement cloud security without the administrative overhead of a legacy enterprise.
ISO 27001 Annex A 8.15 Logging	Cloud security relies heavily on visibility. This technical control is the primary output of 5.23, ensuring that cloud activity logs are captured, protected, and monitored to detect unauthorised access to virtual resources.
Third Party Supplier Policy Template	The documentation evidence for cloud governance. This template defines the internal rules for how your staff select and use cloud services, which is the first thing an auditor will ask to see during a Stage 1 audit.

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