ISO 27001 Annex A 5.23: secure cloud use, from purchase to exit

The diligence questionnaire asks where your data lives, who your sub-processors are and how you would leave. You have a console login and a vague answer. This guide explains ISO 27001:2022 Annex A 5.23 information security for use of cloud services for UK firms of 25 to 250 staff. It runs from purchase to exit and shows which parts you can automate.

It is written for the information security manager, CTO or compliance lead at a firm that runs almost entirely on cloud services. The aim is evidence that an auditor and an enterprise buyer will both accept, without enterprise-sized paperwork.

What does ISO 27001 Annex A 5.23 require?

ISO 27001 Annex A 5.23 requires you to govern every cloud service across its whole life. That covers how services are chosen and approved, who secures what, how you use each platform's security features, how you review its terms, how you monitor it, and how you leave. It covers your use of cloud, not the provider's operations.

Read the control as six linked steps:

1. Choose. Approve services through a defined route, with vetting before purchase.
2. Split responsibility. Write down what the provider secures and what you must secure.
3. Use the platform's security features. Switch on the capabilities each platform already offers.
4. Review the terms. Check the standard contract against your own requirements.
5. Monitor. Watch the service while it runs.
6. Exit. Know how you would get your data out and confirm it is gone.

The control is new in the 2022 edition, and questionnaires cite it under several names. The Annex lists it as A.5.23 Information security for use of cloud services. The guidance standard calls it ISO/IEC 27002:2022 control 5.23 Information security for use of cloud services, often shortened to ISO 27002:2022 control 5.23 Information security for use of cloud services. Supplier forms use ISO 27001:2022 A.5.23 Information security for use of cloud services or ISO 27001:2022 control 5.23 Information security for use of cloud services. Whichever name appears, the evidence you owe is the same.

It is the customer-side view, and it adapts the general supplier controls for click-to-buy services.

It matters because a firm of this size usually runs on cloud. Product sits on AWS or Azure, operations on Microsoft 365 or Google Workspace, and a long tail of SaaS does the rest. Buyers ask about residency, sub-processors and exit, and for financial services firms within DORA's reach, its exit-planning rules sit behind the same questions. The sections below take each step in turn.

Why doesn't your cloud provider's certification cover you under the shared responsibility model?

Provider certification covers the provider's side of the split only. The NCSC states that cloud customers always stay responsible for three things: making sure the service meets their security needs, configuring it securely and deciding what data to store. Under UK GDPR, the controller also stays accountable when a processor holds the data.

The NCSC cloud security shared responsibility model guidance sets out those three standing duties. The ICO guidance on data controllers and processors under UK GDPR adds the legal layer: a controller must be able to show compliance and take appropriate technical and organisational measures. Passing personal data to a cloud processor does not pass on that duty.

The boundary moves with the service model. The NIST SP 800-145 definition of cloud computing separates SaaS, PaaS and IaaS, and each step down that stack hands you more to configure:

• SaaS: the provider runs the application. You own tenant settings, user access and the data you put in.
• PaaS: the provider runs the platform. You own the application, its configuration and its identities.
• IaaS: the provider runs hardware and virtualisation. You own operating systems, patching, network rules and storage settings.

Write the split down per significant service, and add the customer-side duties from any SOC 2 report, which the vetting section covers. A provider certificate is only half the map. The other half is your tenant, and that is where public buckets, missing MFA and unpatched customer-managed VMs appear when the two get confused.

How do you build a cloud asset register that catches shadow SaaS?

List every SaaS, PaaS and IaaS service with a business owner, the data it holds and where that data resides. Then test the list against single sign-on catalogues and expense data, which show the tools people actually use. Any service found outside the register is shadow SaaS, and it enters the approval route.

The register is the thing every other step hangs off. Give each row these fields:

• Service name and model (SaaS, PaaS or IaaS)
• Named business owner
• Data held, by classification
• Data residency
• Approval date and the link to the exit note

Set the approval route in a short cloud policy, or in a cloud section of your supplier policy. It covers four points:

• how services are approved;
• which data classes may live where;
• who owns each service;
• that every service needs an exit thought before go-live.

Pull your identity provider's app catalogue and your finance expense lines. Both name tools that never passed through IT.

A cloud inventory built from memory is a list of what IT remembers, not what the company runs.

Give everyone else one rule: new tools go through approval before company data goes in. Without the register, approval and vetting cannot reach half the estate, and shadow SaaS holds data nobody has checked.

What do you do about cloud contract terms you cannot negotiate?

Read the standard terms against your own requirements on data residency, breach-notification timing, sub-processor change notice, incident support and exit help. Where the terms fall short, record the residual risk with a named management owner and sign it off. Auditors credit that documented decision and penalise its absence.

Hyperscalers and commodity SaaS vendors will not rewrite their contracts for a 40-person customer. Advice to negotiate bespoke terms therefore leaves you stuck. The workable path is review, then decide:

1. Read the standard terms and the published sub-processor list.
2. Compare them with your needs on residency and jurisdiction, notification timing, sub-processor changes, incident support and exit help.
3. Decide whether to accept the gap, cover it with your own controls, or choose another provider.
4. Record the decision with a management owner and a date.

A click-through contract nobody read isn't accepted risk. It's unrecorded risk.

The signed acceptance is the artefact an auditor asks to see. If DORA-driven exit-planning obligations apply to you, check the exit-help clause first, because the terms either support your exit plan or they do not. The outcome to avoid is discovering the residency clause or a 30-day retention period after exit only when a client or regulator asks.

Do not spend effort demanding bespoke terms from commodity SaaS. Keep that effort for the services holding your crown-jewel data.

How do you vet a provider and review the CUECs in its SOC 2 report?

Collect independent assurance before you buy: an ISO 27001 certificate, a SOC 2 Type II report or a CSA STAR entry. In SOC 2 reports, read the Complementary User Entity Controls: the duties the provider's assurance assumes you carry out, such as access reviews, MFA and log monitoring. Map each one to an owner.

Scale the vetting to the data. A tool holding marketing copy needs a quick look. A platform holding client records needs a proportionate risk assessment and a full read of the assurance. When you read it, check four things:

• The dates: certificate expiry and the SOC 2 observation period.
• The scope: whether the reported services are the ones you actually use.
• The report type: Type II shows controls operating over time.
• The exceptions and qualifications the auditor recorded.

CUECs are where a SOC 2 report quietly hands work back to you. Record each one, who owns it and how it is met. That table is the evidence, and it also feeds the responsibility map for the service.

Ignoring the customer-side expectations is the common failure. The report reads as comfort, while its fine print lists jobs you have not been doing.

What cloud security settings must you configure on your side?

Enforce MFA on every admin and root account and apply least-privilege roles. Encrypt data at rest and in transit with deliberate key-management choices, and restore from backups to prove they work. Then send platform audit logs somewhere monitored. NCSC Principle 5 expects effective vulnerability management, protective monitoring, configuration and change management, and incident management.

The NCSC 14 Cloud Security Principles frame the aim as operating and managing the service securely enough to impede, detect or prevent attacks. In practice that becomes six workstreams:

• Identity: MFA on all admin and root accounts, with roles cut to least privilege.
• Data: encryption in storage and transit, with a documented choice between provider-managed and customer-managed keys.
• Resilience: backups you have restored from, with the test record kept.
• Visibility: audit logs flowing to a place someone watches, with alerts on public exposure, disabled MFA and unusual admin activity.
• Response: cloud scenarios in your incident exercises, including how you would engage the provider mid-incident.
• People: admins trained on the platforms they run.

The control is preventive: it aims to stop the leaky bucket and the admin account without MFA before they happen. Those are also the findings attackers and auditors reach first.

This is the real work of the control. Plan a few weeks, prioritised by criticality, with crown-jewel services first. Much of it is one-off configuration that tooling then keeps in place, which leaves your people free for judgement calls.

How much cloud exit planning is enough?

Enough means a short note per critical service stating the export format, the realistic migration path and how you will confirm deletion afterwards. Non-critical services need one line confirming you could walk away without losing anything important. Depth belongs on the services holding your crown-jewel data, not on commodity tools.

Write the note before go-live, while the relationship is good. For each critical service it answers three questions:

• In what format can you export your data, and has anyone tested it?
• Where would the data and workload go, and roughly how long would the move take?
• How will you verify that the provider has deleted what you left behind?

An exit plan written during the dispute is a negotiating position, not a plan.

Financial services firms within DORA's reach will want more depth on critical providers. At 40 people, though, a hyperscaler-grade multi-cloud framework is the opposite error. Having no exit thinking at all turns a price hike, an acquisition or an outage into a hostage situation.

How do auditors test ISO 27001:2022 Annex A 5.23 information security for use of cloud services?

Auditors take your two or three most critical cloud services. They trace each through inventory, vetting, responsibility map and live console configuration, checking MFA on admin accounts first. Then they probe one service for its exit answer and compare the inventory against SSO and finance records. Missing governance entirely grades major; isolated gaps grade minor.

Expect five questions in the room:

• Show me your list of cloud services. How would you know if a team started using one that is not on it?
• For your production platform, which controls are the provider's and which are yours? Where is that written down?
• What assurance do you hold for this provider, when did you last refresh it, and did you act on its customer-side expectations?
• Where does this data reside, and what would you do if the provider added a sub-processor or moved a region?
• If you had to leave this provider in ninety days, how would you do it?

In a certification audit, ISO/IEC 27001:2022 Annex A 5.23 Information security for use of cloud services is tested by tracing real services, not by reading the policy aloud. MFA on admin accounts is the single most-checked setting, so check it yourself first. Your Statement of Applicability entry for ISO 27001:2022 control A.5.23 Information security for use of cloud services should point to the artefacts. Those are the current inventory, vetting records and CUEC reviews, the responsibility matrix, signed terms acceptances, console evidence, monitoring records and exit notes.

Certification bodies grade gaps in this way:

• Major: no cloud governance at all (no inventory, no approval route, crown-jewel data in unassessed services), or open storage exposing sensitive data.
• Minor: a stale inventory entry, an unreviewed SOC 2 report, or a missing exit note on a non-critical service.

Minor findings of the same kind can add up to a major when they form a pattern.

How can you automate cloud evidence instead of maintaining spreadsheets?

Connect discovery, posture and evidence collection to the platforms themselves. SSO logs and expense feeds keep the inventory current. Posture tooling such as AWS Config or Microsoft Defender for Cloud checks settings against baseline, and provider APIs collect configuration exports on schedule. The auditor's sample becomes a folder that already exists.

Cloud platforms expose almost everything through APIs, so this control automates better than most. The table below sets out six feeds that do the work: what each catches, how often it runs and the evidence it leaves. Shadow IT then arrives as a diff, not a surprise, and drift raises a ticket instead of waiting for the audit.

This also closes the gap of vetting a provider once and never looking again, while it changes sub-processors, regions and terms. A spreadsheet cannot notice that change, but a watcher can.

The next diligence questionnaire becomes a link to evidence, not a week of chasing.

Frequently asked questions