ISO 27001 A.5.23: Using Cloud Services Securely

TL;DR

A.5.23 is a new control in ISO 27001:2022 and requires organizations to define processes for the acquisition, use, management, and exit from cloud services.
The shared responsibility model determines who is responsible for which security aspects. Responsibility varies significantly depending on the service model (IaaS, PaaS, SaaS).
A cloud usage policy defines which services are permitted, which data may go to the cloud, and which security requirements cloud providers must meet.
Every cloud service requires a risk assessment that considers data location, compliance requirements, availability SLAs, and dependencies.
An exit strategy is not an optional luxury but a requirement. It describes how you retrieve data from the provider and replace the service without data loss.

Why Cloud Got Its Own Control

In the predecessor version ISO 27001:2013, the word "cloud" practically did not appear. Cloud services were subsumed under general controls such as supplier management or network security. That may have been justifiable in 2013, but by 2022 virtually every company uses cloud services, whether Microsoft 365, AWS infrastructure, a SaaS ERP, or a seemingly harmless project management app.

ISO 27001:2022 responded by introducing A.5.23 as a dedicated control for cloud services. The full title is "Information security for use of cloud services," and the requirement is clear: organizations must define processes covering the entire lifecycle of cloud services, from acquisition through use and ongoing management to exit.

For a company with around 100 employees, this is particularly relevant because cloud usage has often grown rather than been planned. Individual departments have introduced services — a typical shadow IT problem — and IT sometimes only learned about them when the first invoice arrived. The result: a tangled web of cloud services without uniform security standards.

What the Standard Specifically Requires

A.5.23 requires, according to ISO 27002:2022, that the organization develops a topic-specific approach for cloud services covering the following aspects:

Requirements definition: Before a cloud service is procured, the information security requirements must be defined. What data will flow into the service? What protection need does this data have? What regulatory requirements apply?

Provider selection and evaluation: Selection of a cloud provider must be based on defined criteria. These include certifications (ISO 27001, SOC 2), location of data processing, encryption mechanisms, availability SLAs, and fulfillment of contractual security requirements.

Definition of roles and responsibilities: The shared responsibility model must be clarified and documented for each cloud service. Who is responsible for which security aspects: the cloud provider or the organization itself?

Ongoing management: Cloud services must be continuously monitored. Security configurations, access rights, compliance status, and availability must be regularly reviewed.

Exit: A strategy must exist for how data can be retrieved from the provider and the service terminated without losing data or jeopardizing business continuity.

Understanding the Shared Responsibility Model

The shared responsibility model is the central concept when using cloud services. It describes how security responsibility is divided between cloud provider and customer. The exact division depends on the service model.

Infrastructure as a Service (IaaS)

With IaaS (e.g., AWS EC2, Azure Virtual Machines, Hetzner Cloud), the provider supplies the physical infrastructure: data center, server hardware, network, storage. Responsibility for everything above lies with the customer: operating system, middleware, applications, data, access rights, encryption, patch management, firewall rules.

For a company with around 100 employees, this means: if you run virtual servers in the cloud, you must patch, harden, and monitor them just as you would on-premises servers. The cloud only removes the physical infrastructure burden.

Platform as a Service (PaaS)

With PaaS (e.g., Azure App Service, AWS Elastic Beanstalk, Heroku), the provider additionally manages the operating system, runtime, and middleware. The customer is responsible for the application, data, access control, and platform configuration.

Software as a Service (SaaS)

With SaaS (e.g., Microsoft 365, Salesforce, Slack, HubSpot), the provider assumes nearly all technical responsibility. The customer is responsible for configuring the service, access control, classifying the data, and meeting regulatory requirements regarding the data entered into the service.

Documenting the Responsibility Division

For each cloud service, a responsibility matrix should exist, documenting who is responsible for the relevant security domains. ISMS Lite supports you with cloud-relevant controls and practical implementation guidance, so you know exactly which aspects to document per service. The domains typically cover: physical security, network security, operating system security, application security, data security, identity and access management, encryption, backup, incident response, compliance, and audit.

An auditor will ask: "Who is responsible for encryption of data at rest in your CRM system?" If you cannot answer this question, you have not sufficiently understood the shared responsibility model.

The Cloud Usage Policy

A cloud usage policy sets the framework for the company's entire cloud strategy. It should contain the following chapters:

Scope and Definitions

Define what constitutes a "cloud service." This sounds trivial but is not. Does the hosted website count? The online backup? The video conferencing software? The answer should be: yes, anything through which company data is processed, stored, or transmitted and that is provided by an external provider as a service.

Classification and Approval

Not every cloud service needs to go through the same review process. Define categories based on the protection need of the data:

Category 1 (Standard): Cloud services that only process public or internal data with normal protection needs. A simplified review with standard criteria is sufficient.

Category 2 (Extended): Cloud services that process confidential or personal data. A full risk assessment is required, including review of certifications, contracts, and technical security measures.

Category 3 (Critical): Cloud services that process strictly confidential data or support business-critical processes. Additionally, penetration tests, provider audits, or detailed security questionnaires are required.

Requirements for Cloud Providers

Define minimum requirements that every cloud provider must meet:

ISO 27001 certification or equivalent evidence (SOC 2 Type II)
Data processing within the EU or in countries with an adequate level of data protection
Encryption of data in transit (TLS 1.2+) and at rest (AES-256)
Availability SLA with defined values (at least 99.5% for business-critical services)
Ability to fully export data in a standardized format
Documented incident response process with defined notification timelines
Data processing agreement for processing of personal data

Prohibited Usage Forms

The policy should clearly state what is not permitted:

Use of personal cloud storage (private Dropbox account, Google Drive with personal email) for company data
Setting up cloud services without IT or CISO approval
Storing strictly confidential data in cloud services without authorization
Using cloud services that do not offer encryption

Risk Assessment for Cloud Services

Every cloud service in Category 2 or 3 requires an individual risk assessment. The following risk categories should be systematically reviewed.

Data Location and Jurisdiction

Where is the data physically stored? In which jurisdiction does the provider operate? Do authorities in the provider's country have access to the data (keyword: US CLOUD Act)? Is there an option to restrict data processing to the EU?

For a company with around 100 employees processing DSGVO (GDPR)-regulated data, data location is a critical factor. Using a US provider is not automatically excluded but requires additional protective measures (standard contractual clauses, Transfer Impact Assessment, encryption with own key custody).

Availability and Dependency

How dependent is your business operations on this cloud service? What happens if the service is unavailable for hours or days? Is there a workaround or an alternative service?

Calculate the impact of an outage on your business processes. If your ERP system runs as SaaS and goes down, no invoices can be written, no orders processed, and no shipments initiated. That is a very different risk than the outage of a project management tool.

Vendor Lock-in

How easily can you switch providers? Are there standardized export formats? Are the data structures proprietary? How high is the migration effort?

Vendor lock-in is one of the most commonly underestimated risks with cloud services. If you have accumulated a year's worth of data in a proprietary system and the provider doubles its prices, changes its terms, or discontinues the service, you need a realistic way to extract the data and switch services.

Data Integrity and Backup

Who is responsible for backing up data in the cloud service? Many companies assume the cloud provider automatically creates backups. This is fundamentally wrong for IaaS and often only partially true for SaaS. Microsoft 365, for example, does not offer long-term recovery of deleted data. If an employee deletes a file and you only notice 90 days later, the file may be irretrievably lost.

Clarify for each cloud service: Are backups created? By whom? How long are they retained? How does recovery work? Do you need an additional backup through a third-party provider?

Multi-Tenant Risks

Most cloud services are multi-tenant systems where multiple customers share the same infrastructure. This carries theoretical risks such as side-channel attacks, data leaks between tenants, or "noisy neighbors" that impact performance. With established providers holding ISO 27001 certification, these risks are generally adequately addressed but should be documented in the risk assessment.

Exit Strategy

The exit strategy is the part of A.5.23 that most companies neglect. It only becomes relevant when it is too late: when the provider discontinues the service, prices become intolerable, a security incident at the provider destroys trust, or regulatory requirements force a switch.

Components of an Exit Strategy

Data export plan: What data needs to be exported? In what format? How large is the data volume? How long does the export take? Does the provider offer an API or bulk export?

Target environment: Where will the data be migrated? To another cloud service? To own infrastructure? To a new system fulfilling the same function?

Timeline: How long does the migration realistically take? Consider not just the technical export but also the configuration of the new system, data migration, testing, and employee retraining.

Contractual provisions: What termination notice periods apply? Does the provider make the data available for a defined period after contract end? In what format? Is the data deleted at the provider after return?

Costs: What does the migration cost? Are there costs at the provider for data export (egress fees)?

Regular Testing

An exit strategy that exists only on paper helps little in an emergency. Test the data export regularly, at least once per year for business-critical cloud services. Verify that exported data is complete and usable. Document the test results.

Typical Audit Findings for A.5.23

Finding 1: No Cloud Service Inventory

The auditor asks for an overview of all cloud services and does not receive a complete list. Individual departments use services that IT is not aware of (shadow IT).

Prevention: Maintain a cloud service inventory that includes at minimum the service name, provider, service model, data type, responsible person, and contract end date. Review the inventory regularly, e.g., by analyzing payment flows.

Finding 2: Shared Responsibility Not Documented

No document exists describing the responsibility division between provider and organization. The IT department has an intuitive understanding but nothing in writing.

Prevention: Create a responsibility matrix for each cloud service in Category 2 and 3.

Finding 3: No Exit Strategy

The auditor asks: "What happens if provider X discontinues the service?" and receives no documented answer.

Prevention: Document an exit strategy for each business-critical cloud service with the components described above.

Finding 4: Cloud Services Without Risk Assessment

Cloud services were introduced without a risk assessment. The decision was based on functionality and price; security aspects were not systematically reviewed.

Prevention: Integrate the risk assessment into the procurement process. No cloud service in Category 2 or 3 may be activated without a completed risk assessment.

How ISMS Lite Supports Compliance

583 controls with implementation guidance: ISMS Lite includes 11 frameworks with a total of 583 controls — including all cloud-relevant controls such as A.5.23. Each control comes with practical implementation recommendations so you know exactly what needs to be done.

AI-assisted policy generation: The local AI helps you draft your cloud usage policy, exit strategy, and other documents — based on the requirements of the relevant controls.

Structured documentation: All assessments, policies, and evidence can be documented with versioning and approval workflows — ideal for audit evidence.

Related controls at a glance: Cloud security affects many controls simultaneously (supplier management, cryptography, business continuity). ISMS Lite shows you the connections and helps ensure nothing is overlooked.

Interaction with Other Controls

A.5.23 does not stand in isolation. It interacts closely with several other controls:

A.5.19-A.5.22 (Supplier management): Cloud providers are suppliers and must be evaluated and monitored accordingly.
A.5.1 (Policies): The cloud usage policy is one of the topic-specific policies required by A.5.1.
A.8.24 (Cryptography): Encryption requirements for cloud services derive from the cryptography policy.
A.5.29-A.5.30 (Business continuity): Availability of cloud services is part of business continuity planning.
A.8.10 (Information deletion): When a cloud service is terminated, it must be ensured that data is deleted at the provider.

If you implement A.5.23 properly, you significantly ease the work on all these related controls. And conversely: if you have gaps in A.5.23, they will also become apparent in the related controls.