ISO 27001 A.5.23: Govern Cloud Services from Start to Exit

What A.5.23 requires in practice

Control A.5.23 asks the organisation to establish processes for acquiring, using, managing and exiting cloud services, in line with its own security requirements. The title of this page stresses the whole life of the service, and the control does the same: it is not satisfied by a good selection decision alone.

In practice the control spans four moments. Before acquisition, decide what security the service must provide. During use, be clear about which responsibilities sit with the provider and which stay with you, such as user access and configuration. During management, keep checking that the service continues to meet your needs. At exit, know how information will be returned or removed. The standard does not name a method; a responsibility split written for each service is one practical way to make the division visible.

Define the proposed use before selecting the service

Identify the information involved, intended users, integrations and business dependency. A service suitable for public marketing material may be unsuitable for sensitive customer records under the same default arrangement. Trials deserve attention when staff can upload real information or connect production systems before formal procurement begins.

Assess the offered service against those needs. Consider what evidence is available about provider controls, what terms apply and what limits affect your intended use. Standard cloud terms may not be negotiable. The organisation should make an informed decision about those terms and residual risk, rather than claim an individual commitment the provider has not made.

Assign a service owner before adoption. The person paying the subscription may not be responsible for access, configuration or continuity. A small subscription can become business-critical through daily use, so ownership should follow the service’s actual role rather than its original purchasing category.

Make shared responsibilities specific

Examine a concrete protection need, such as limiting access or recovering deleted information. Determine what the provider does, what settings the customer must choose and who operates them. “The cloud provider handles security” is too broad to guide implementation or incident response.

Responsibilities vary across service models and products. A customer may administer operating systems in one service and only configure users and data in another. Avoid importing a responsibility diagram from a different service without checking it. Connect identity and permission decisions with access rights.

Why cloud governance matters to the business

Cloud services are easy to start and hard to unwind. A team can sign up in minutes, load business data and create a dependency nobody has assessed. The common failures are not exotic: misconfigured sharing, unmanaged accounts and no route to retrieve data when a contract ends. Governing the full life of each service protects customers' information, avoids lock-in surprises and makes outages easier to handle. It also gives auditors and clients a straightforward story: you chose services deliberately, you know what you are responsible for and you can leave in an orderly way.

How to implement A.5.23

Start by finding out which cloud services are already in use, then bring them under a consistent route. A practical order is below. Cloud adoption often begins outside the IT team, which is why discovery comes first. Ask finance for recurring payments and ask team leaders what tools they use daily. Once you can see the services, you can bring them under one route without stopping the business. Keep the route light for low-risk tools and firmer for those holding client or personal information, so teams are not tempted to bypass it.

1. Discover current cloud services, including those adopted by individual teams.
2. Set the security requirements a service must meet before use.
3. Assess candidate services against those requirements and the risk of the data involved.
4. Document the split of responsibilities between provider and organisation.
5. Configure and manage access and settings, with an owner for each service.
6. Keep reviewing the service against your requirements.
7. Plan exit: how data returns, how copies are removed and how the business continues.

Illustrative software example: recovery is assumed

Illustrative construction example: project closure in a cloud portal

A hypothetical contractor manages a project in a subscription portal. At handover, the client needs a usable record of approved documents and revisions. The team discovers that ordinary downloads omit relationships needed to interpret the history.

The contractor tests export and handover during the project, clarifies provider support and decides how required records will remain usable after the subscription ends. Access removal and information disposition are planned alongside retention. The exit decision becomes part of service design rather than an emergency at renewal.

Manage changes and connected services

Cloud services change frequently. Identify which provider notices matter and how administrators evaluate them. A new integration, support arrangement or storage option can alter exposure. Use supplier change review to connect notices with decisions and implementation checks.

Consider the boundaries between multiple services. Data copied through a connector may receive different permissions or retention in the destination. An approved source application does not automatically make every connected tool acceptable. Follow representative information through the integrations that the business actually uses.

Prepare for incidents and exit

Know how to contact the provider, obtain relevant evidence and coordinate action during an incident. Clarify what logs or administrative capabilities are available under the agreed service. Discovering those limits during a serious event can delay decisions.

For exit, consider data return, usable formats, configuration information, continuity during transition and appropriate deletion or retention. The detail should fit the service and obligations. No universal multi-cloud architecture or backup product is mandated by A.5.23; the organisation must establish an approach that addresses its needs.

Evidence and common weak points

Common nonconformities with A.5.23

Cloud findings often come from services nobody formally owned. Cloud findings often come from services nobody formally owned. Auditors may ask a team lead which tools hold client data and then check whether the organisation knew about them and had assessed them.

• Cloud services in use by departments that were never assessed or recorded.
• No clarity on which security tasks the provider performs and which the organisation must do.
• Administrator accounts without ownership or review.
• No considered plan for retrieving data at the end of a contract.