Zum Hauptinhalt springen
Annex A · Organisational Control

A.5.23 — Information Security for Use of Cloud Services

Updated on 5 min Reviewed by: Cenedril Editorial
A.5.23 ISO 27001ISO 27002BSI OPS.2.2

An organisation stores customer data in a SaaS CRM. The provider’s terms of service allow data processing in any region. The organisation’s data protection policy requires EU-only hosting. Nobody noticed the mismatch until the data protection officer ran a routine check. A.5.23 demands that cloud service security is specified, agreed and actively managed — from selection through operation to exit.

Cloud services have become the default for most organisations, but the convenience comes with a specific set of security challenges: shared responsibility, limited visibility, vendor lock-in and regulatory complexity.

What does the standard require?

  • Define cloud security requirements. The organisation must establish requirements for the acquisition, use, management and exit from cloud services. These requirements must address confidentiality, integrity, availability and compliance.
  • Clarify the shared responsibility model. For each cloud service, the organisation must document which security controls are the provider’s responsibility, which are the organisation’s and where joint responsibilities exist.
  • Select providers based on security criteria. The selection process must evaluate the provider’s security capabilities, certifications, data location policies, incident response procedures and contractual terms.
  • Monitor cloud service security. The organisation must continuously or periodically verify that the cloud provider meets the agreed security requirements and that the organisation’s own responsibilities are fulfilled.
  • Plan for exit. The organisation must have a documented strategy for exiting each cloud service, including data retrieval, secure deletion and transition to an alternative.

In practice

Maintain a cloud service register. List every cloud service in use, including shadow IT discovered through procurement reviews. For each service, record: provider name, service model (IaaS/PaaS/SaaS), data classification level, data location, contract owner, last security review date and exit plan status.

Evaluate providers before onboarding. Check certifications (ISO 27001, SOC 2, BSI C5), data processing locations, encryption practices (at rest and in transit), incident notification commitments and sub-processor transparency. Use a standardised evaluation checklist to ensure consistency.

Document the shared responsibility model. For each critical cloud service, create a responsibility matrix that maps security controls to either the provider, the organisation or both. Review the matrix whenever the service scope or delivery model changes.

Enforce customer-side controls. The provider’s security is only half the picture. The organisation must configure access controls, enable audit logging, encrypt sensitive data before upload (where applicable), enable MFA for administrative accounts and regularly review configuration settings.

Prepare exit strategies. For every cloud service that stores organisational data, document: how to extract data in a usable format, how to verify complete deletion from the provider’s infrastructure, which alternative services or on-premises solutions could take over and what the estimated migration timeline is.

Typical audit evidence

Auditors typically expect the following evidence for A.5.23:

  • Cloud service register — inventory of all cloud services with classification, provider and review status
  • Provider evaluation records — documented security assessments performed before onboarding
  • Shared responsibility matrices — documented division of security responsibilities per service
  • Cloud security configuration records — evidence of customer-side controls (access policies, encryption settings, logging)
  • Review records — periodic security reviews of cloud services and their outcomes
  • Exit plans — documented exit strategies for critical cloud services

KPI

% of cloud services with documented security controls and review cycles

This KPI measures how many cloud services have both documented security controls (provider-side and customer-side) and a scheduled review cycle. Cloud services without documented controls represent unmanaged risk. Target: 100% for services processing confidential or restricted data.

Supplementary KPIs:

  • Percentage of cloud services with a documented shared responsibility matrix
  • Number of cloud misconfigurations detected and remediated per quarter
  • Percentage of critical cloud services with a tested exit plan

BSI IT-Grundschutz

A.5.23 maps directly to BSI’s dedicated cloud security module:

  • OPS.2.2 (Cloud usage) — the comprehensive BSI module for managing security when using cloud services. It covers provider selection, contractual requirements, data location, encryption, access management, monitoring, incident handling and exit planning. The module distinguishes requirements by cloud service model (IaaS, PaaS, SaaS) and addresses both public and private cloud deployments.

A.5.23 applies the supplier security framework specifically to cloud services:

Sources

Frequently asked questions

Does A.5.23 apply to every cloud service?

Yes. IaaS, PaaS, SaaS and any other cloud delivery model are in scope. The depth of security requirements and oversight should be proportional to the sensitivity of the data processed and the criticality of the service.

What is the shared responsibility model?

Cloud providers secure the infrastructure; the customer secures their own data, configurations and access management. The exact division depends on the service model: in IaaS the customer carries more responsibility, in SaaS the provider carries more. The organisation must understand and document where provider responsibility ends and customer responsibility begins.

Do I need a separate exit strategy for every cloud service?

Every cloud service that processes or stores organisational data should have a documented exit plan. For critical services, the plan should include data extraction procedures, format compatibility, migration timelines and alternative providers. For low-risk services, a high-level plan may suffice.