ISO 27001:2022 Annex A 5.23 Information security for use of cloud services for AI Companies

ISO 27001 Annex A 5.23 Information security for use of cloud services is a security control that requires organizations to establish processes for the acquisition, use, management, and exit of cloud services. For AI companies, this control is essential to secure critical infrastructure like GPU clusters and model hosting environments, ensuring that cloud-based intellectual property is protected according to the shared responsibility model.

As an AI company, you operate at the cutting edge of technology, heavily relying on cloud services for everything from computationally intensive model training to real-time inference and data storage. The agility and scalability of the cloud are foundational to your innovation. Recognising this shift, the ISO 27001:2022 standard introduced ISO 27001 Annex A 5.23 Information security for use of cloud services, a crucial new control that directly addresses the security of cloud services.

This guide is designed to demystify this control, analyse the unique cloud security risks faced by AI companies, provide a clear and actionable plan for compliance, and present a practical solution to streamline the entire process.

The “No-BS” Translation: Decoding the Requirement

Let’s strip away the consultant-speak. Annex A 5.23 is about acknowledging that you don’t own your servers anymore. It requires you to act responsibly on rented land.

The Auditor’s View (ISO 27001)	The AI Company View (Reality)
“Processes for acquisition, use, management and exit from cloud services shall be established in accordance with the organisation’s information security requirements.”	Shared Responsibility is Key. 1. Don’t assume AWS backs up your data. They back up the infrastructure. You back up the data. 2. If you leave the Vector Database provider, how do you get your embeddings out? Do you have a script for that?
“Cloud service agreements should address… information security requirements.”	Read the small print. Does your “free tier” LLM provider have the right to train on your input data? If so, you just gave away your IP. Check the box “Do not train.”

The Business Case: Why This Actually Matters for AI Companies

Why should a founder care about “Cloud Security”? Because your entire business exists inside someone else’s computer.

The Sales Angle

Enterprise clients will ask: “Which regions do you process data in?” and “What is your exit strategy if Azure goes down?”. If your answer is “We rely 100% on us-east-1 and hope for the best,” you lose. If your answer is “We have a multi-region failover strategy documented in our Cloud Policy,” you win. A 5.23 proves resilience.

The Risk Angle

The “Vendor Lock-in” Ransom: You build your entire product on a proprietary AI platform (e.g., using only OpenAI’s specific Assistants API). If they double the price or change the terms, you are dead. A 5.23 forces you to have an “Exit Strategy” – effectively an insurance policy for your business continuity.

DORA, NIS2 and AI Regulation: Cloud is Critical

Regulators view cloud providers as critical infrastructure.

• DORA (Article 28): Requires a “Strategy for ICT Third-Party Risk.” You must have an exit strategy for critical cloud services. If you cannot migrate your data easily, you are non-compliant.
• NIS2 Directive: Mandates security in the supply chain. You must assess the security measures of your cloud providers. Using a cheap, unverified GPU cloud provider could be a violation.
• EU AI Act: High-risk systems require technical documentation. You must document the computational resources used. If your cloud provider cannot guarantee resource availability (compute), your system’s reliability is in question.

ISO 27001 Toolkit vs SaaS Platforms: The Cloud Trap

SaaS platforms monitor your cloud configuration (e.g., “S3 bucket open”), but they don’t manage the relationship or the contract. Here is why the ISO 27001 Toolkit is superior.

Feature	ISO 27001 Toolkit (Hightable.io)	Online SaaS Platform
Scope	Full Lifecycle. Covers Acquisition (Selection), Use, and Exit (Termination).	Use Only. Platforms check if you are using it securely now, but don’t help you select or exit a vendor.
Ownership	Your Strategy. You own the “Cloud Security Policy” and “Exit Strategy” documents.	Config Checks. Platforms provide a dashboard of pass/fail checks. If you cancel, you lose the record of your compliance posture.
Simplicity	Templates. “Here is what to put in your contract with a SaaS vendor.”	No Legal Help. Platforms tell you “MFA is off,” but don’t help you negotiate the Data Processing Agreement (DPA).
Cost	One-off fee. Pay once. Secure your cloud.	Usage-Based. Some platforms charge based on the number of cloud resources you connect. Scaling your infrastructure increases your compliance cost.

Understanding Control A.5.23: What It Means for Your AI Company

At its core, this control is about moving beyond ad-hoc cloud adoption and establishing a formal, lifecycle-based process for managing all your cloud services securely. The purpose is to ensure that information security risks are identified and managed throughout your entire relationship with the provider.

The High Stakes: Unique Cloud Security Risks in AI Workflows

While any company faces cloud security risks, for an AI business, these risks are existential.

Exposure of Sensitive Training Datasets

Your AI models are built on unique data assets. A failure to secure cloud services can lead to the catastrophic loss of proprietary labeled datasets. This extends beyond PII breaches to the theft of the core intellectual property that underpins your algorithms.

Disruption of Algorithmic Processes

Your business relies on continuous availability. A security incident can interrupt critical MLOps pipelines or cause model drift to go undetected. Such disruptions can halt operations and inflict significant reputational damage.

Vulnerabilities in the AI Supply Chain

The AI development lifecycle is a complex supply chain. Inheriting vulnerabilities from third-party model repositories underscores the importance of scrutinising the security of every cloud-based supplier.

Your Action Plan: A Step-by-Step Guide to Compliance

Compliance here is not about bureaucratic box-checking; it is about building a robust operational framework.

Acquisition: Selecting and Onboarding Cloud Providers

Establish a disciplined acquisition process. Perform AI-centric risk assessments and scrutinise agreements for data recovery and exit strategies.

Use: Implementing Policies and Controls

Establish topic-specific policies. Understand the Shared Responsibility Model and map every key security function to either you or the provider. Implement robust access controls and enforce the principle of least privilege.

Management: Monitoring and Review

Treat cloud security as a continuous discipline. Conduct continuous monitoring and manage service changes. Perform regular security assessments and maintain an up-to-date Cloud Security Register.

Exit: Securely Transitioning Away from a Service

Design a secure exit strategy. Proactively document the procedures for retrieving your data and ensure model and data portability.

The Evidence Locker: What the Auditor Needs to See

When the audit comes, prepare these artifacts:

• Cloud Security Policy (PDF): A document defining your rules for using cloud services.
• Cloud Services Register (Excel): A list of all SaaS/IaaS/PaaS providers, their owner, and their status.
• Shared Responsibility Matrix (Excel/PDF): A simple grid showing who does what (e.g., “AWS secures the data center, We secure the OS”).
• Exit Strategy Plans (PDF): A documented plan for leaving your most critical provider (e.g., “How to migrate from AWS to GCP”).

Common Pitfalls & Auditor Traps

Here are the top 3 ways AI companies fail this control:

• The “Free Tier” Trap: You use a free tool for production. Free tiers often have no SLA and no security guarantees. Auditor asks: “What happens if they delete your account?” You have no answer.
• The “Untracked” SaaS: Marketing signed up for an AI copywriter tool using a corporate card. It isn’t in the register. It has access to customer data. Non-conformity.
• The “Default” Config: You spun up an S3 bucket but left the default “Block Public Access” settings off (or changed them without knowing).

Handling Exceptions: The “Break Glass” Protocol

What if your cloud provider locks you out (e.g., billing dispute or 2FA failure)?

The Cloud Lockout Workflow:

• Preparation: Maintain a “Break Glass” account (root user) with credentials stored physically offline (safe) or in a separate system.
• Alternative Contact: Have the “Enterprise Support” phone number saved offline.
• Data Backup: Ensure critical data is backed up to a different cloud provider (Cross-Cloud Backup) so you aren’t held hostage.

The Process Layer: “The Standard Operating Procedure (SOP)”

How to operationalise A 5.23 using your existing stack (Linear, Notion).

• Step 1: Selection (Manual). Engineer creates a “New Tool Request” in Linear.
• Step 2: Review (Manual). Security Lead reviews the tool’s security page (SOC 2, ISO 27001) and Terms of Service (Data ownership).
• Step 3: Register (Manual). Add tool to “Cloud Register” in Notion. Assign an Owner.
• Step 4: Configure (Automated). Use Terraform to deploy infrastructure with standard security tags (Project, Owner, DataClass).
• Step 5: Monitor (Automated). CloudWatch/Datadog alerts on configuration drift (e.g., “Security Group changed to 0.0.0.0/0”).

By formalising how you acquire, use, manage, and exit cloud services, you build a resilient foundation for your technology. A structured approach, guided by a practical solution like the High Table ISO 27001 Toolkit, removes the guesswork.

ISO 27001 Annex A 5.23 for AI Companies FAQ

About the author