ISO 27001 Control 5.23: Information Security for Use of Cloud Services

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Control 5.23 was new in the 2022 edition, and it is the one I see bluffed more than any other in the supplier family. Most organisations I work with have a cloud services policy, certainly by the time I have finished coaching them. But when they first come to me, or when I am auditing them, cloud use is often the wild west.

Here is the pattern. The business has a sensible policy forbidding staff from installing software. It may even enforce it technically. Then somebody with a company credit card signs up to a cloud service in five minutes, invites half their team, and starts putting client data into it. No installation required, so the policy never noticed.

Shadow IT kills organisational effectiveness and quietly drives up costs, and it puts information into places nobody has assessed. This page covers what the control actually asks for, how shadow IT happens, what a proportionate approval process looks like, and how to get out of a cloud service safely when the time comes.

What control 5.23 actually asks for

The requirement is that processes for the acquisition, use, management and exit from cloud services are established in accordance with the organisation’s information security requirements. Four verbs, and each one matters:

• Acquisition: how a new cloud service gets chosen and approved, and who decides.
• Use: the rules for using it securely, including who may use it and for what kind of information.
• Management: who owns each service, how access and configuration are controlled, and how it is reviewed.
• Exit: how you get your data out and close it down when you stop using it.

In practice the evidence is a cloud services policy that covers those four stages, a list of the cloud services in use with an owner for each, and some way of showing that new services go through an approval step.

This control is new in the 2022 edition. There was no direct equivalent in 2013, which is partly why so many organisations still treat it as an afterthought.

Where 5.23 sits among the supplier controls

5.23 applies the supplier controls to cloud services specifically. For most small businesses, cloud providers make up most of their Tier 1 suppliers anyway.

5.23 adds the part the other supplier controls miss: acquisition by anyone with a card. Controls 5.19 to 5.22 assume somebody decided to engage a supplier. Cloud services break that assumption, because anyone can acquire one without procurement, IT or management knowing. That is why this control puts so much weight on how services are acquired in the first place.

Shadow IT and the company card

Shadow IT is any service your people use for work that the business has not approved. It is almost never malicious. It is people trying to get their job done with the tool they found, or the tool they used at their last company.

The company credit card is what makes it so easy. There is no purchase order to raise, no supplier to set up, nobody to ask. A monthly subscription small enough not to need sign-off is invisible until someone reviews the card statements, and by then the team has a year of work in it.

The security consequences are real:

• Data in unassessed places. Client information, employee records or source code ends up with a provider nobody has checked, possibly in a country your customers would object to.
• No control over access. Services outside single sign-on are the ones leavers keep access to, because nobody knew they existed.
• Weak configuration. Public sharing links, no multi-factor authentication, default settings, because the person who set it up was solving a work problem, not a security one.
• Obligations nobody understood. People will not understand the security risks and terms of the platforms they sign up to. That is not their job.

And a software installation ban does not help. It is a good control for what it covers, but cloud services circumvent it entirely, and they are frankly often overlooked when the policy is written.

The cost problem nobody budgeted for

Shadow IT is a security problem, but it is often the money that gets management’s attention first.

I have seen companies with a disproportionate variety of project management systems, simply because people signed up to things. Want to work with HR? They use Monday.com: licence, please. Want to work with Facilities? They use Asana: licence, please. Meanwhile the business is already paying for a perfectly good planning tool inside its Microsoft 365 subscription that nobody uses.

Each duplicate tool means duplicate licence costs, and every new person who needs to collaborate across teams needs a seat in each one. Costs spike, quietly, in places that never appear in a budget. Information gets split across several systems, so nobody has the full picture and nothing is in one place when you need it. And every extra tool is another supplier holding company data.

Funnelling requests through one route is how you stop it. Not to say no, but so that someone can ask the obvious question: do we already have something that does this?

A simple approval route

In a small business this does not need a committee. It needs a route that is easier to follow than to bypass:

1. All new cloud services go through IT, or whoever owns your IT, before anyone enters a card number. Say so in the policy, and say it again at induction.
2. A short request: what it is for, what data will go into it, how many people need it, and what it costs.
3. A quick check: do we already have something that does this? Will it hold personal or client data? Where is that data stored? Does it support single sign-on or multi-factor authentication?
4. A decision, recorded: approved, approved with conditions, or use the existing tool instead. Anything holding sensitive data also goes on the supplier register as Tier 1.
5. An owner for every approved service, who is responsible for its users, its configuration and its renewal.

Then make sure there is a backstop. Review card and expense statements for software subscriptions every quarter. Check which applications people have connected to your Microsoft 365 or Google Workspace accounts. Anything you find that has not been through the route is either approved retrospectively or replaced.

Shared responsibility

Every cloud service divides security between the provider and you. The provider secures the platform: the data centres, the infrastructure, the software. You are responsible for how you use it: who has accounts, how they sign in, what is shared publicly, how it is configured, and whether your data is backed up.

The split varies by service, and the provider will usually publish it. The point for 5.23 is that somebody in your business should know where the line falls for each service you depend on, and should own your side of it. The most common cloud breaches I see are not failures of the provider. They are a storage bucket or a sharing link left open by the customer.

Getting out: the exit plan

The fourth verb in the control is the one that is almost always missing. For each service that holds data you care about, you should be able to answer:

• How would we get our data out, in what format, and how long would it take?
• What happens to our data after we leave, and how would we know it had been deleted?
• Who has accounts, and how would we close them all?
• What would we move to, and is there anything that would make leaving difficult?

You do not need a detailed migration plan for every tool. You do need to have thought about it before the day the provider triples its price, gets acquired, or goes out of business.

What a cloud services policy should say

A cloud services policy for a small business can fit on two pages. It should cover:

• Approval: no cloud service is used for company information without approval, and how to ask.
• Selection criteria: what you check before approving, including data location, sign-in security and the provider’s assurance.
• Ownership: every approved service has a named owner.
• Use: which kinds of information may go into which services.
• Security settings: single sign-on or multi-factor authentication required; no public sharing by default.
• Review: how often the list of services is reviewed, and the card statement check.
• Exit: how data is retrieved and accounts closed when a service is retired.

The register below gives you the list that goes with it, with the approval status and the duplicates made visible.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call

What auditors will look for

As a Lead Auditor, this is broadly how I would work through 5.23.

1. Your cloud services policy, and whether it covers acquisition, use, management and exit, not just “cloud is allowed”.
2. Your list of cloud services. Who owns each one, and who approved it?
3. The approval route in practice. Show me the most recent new service and how it was approved.
4. Shadow IT. I may ask to see the applications connected to your Microsoft 365 or Google tenant, or the software lines on a card statement, and compare them with your list.
5. Shared responsibility. For your main platform, what are you responsible for, and who looks after it?
6. Exit. For a service you have stopped using, what happened to the data and the accounts?

Common issues

• A strong policy against installing software, and nothing at all about cloud services.
• Services bought on company cards that nobody in IT knows about, some holding client or employee data.
• Several tools doing the same job, each with its own licences and its own copy of company information.
• Services outside single sign-on, with accounts belonging to people who left long ago.
• Public sharing links and default settings nobody has reviewed.
• An assumption that the cloud provider is responsible for everything, including backups and access control.
• No exit plan. Data stranded in a service the business stopped paying for.
• A cloud services list built for the audit and never updated.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• How many cloud services does your business use, and how confident are you in that number?
• What would someone in your business do tomorrow if they wanted a new tool for their team?
• How many tools do you pay for that do the same job?
• Which cloud services hold personal or client data, and where is it stored?
• For your most important cloud service, how would you get your data out if you had to leave next month?

The first question is the honest one. If you check the card statements and the connected applications, the real number is almost always higher than the one people give me.

A worked example

The figures below are typical rather than drawn from a single engagement. This is a composite of what a first cloud services review turns up in a business of this size.

A 40-person professional services firm on Microsoft 365, with a written policy forbidding software installation, enforced through device management. No cloud services policy.

What the review found

• The IT list showed 9 cloud services. Card statements and the Microsoft 365 connected applications showed 31.
• Three separate project management tools across HR, facilities and operations, plus the planning tool already included in Microsoft 365 that nobody used. Around £4,000 a year in overlapping licences.
• HR was keeping employee records, including some health information, in a project tool on a free plan with no multi-factor authentication.
• Four services still had active accounts for people who had left.
• A file sharing service had a link to a folder of client proposals that was open to anyone with the address.

What changed

• A two-page cloud services policy, an approval route through the operations lead, and a line in the induction pack.
• The register built and owned: 31 services reviewed, 19 approved, 8 retired and their data recovered, 4 consolidated into tools the firm already had.
• HR records moved into a secured area of Microsoft 365, and the project tool closed with written confirmation of deletion.
• Leaver accounts closed, and cloud services added to the leaver checklist.
• A quarterly check of card statements and connected applications, with the first one finding two new services that went through the route retrospectively.

About three days of effort across the first month, and a saving on licences that more than paid for it. The HR finding alone would have been a serious problem if it had surfaced through a breach rather than a review.

How control 5.23 links to other clauses and controls

• Control 5.19, Information security in supplier relationships. Cloud providers holding your data are Tier 1 suppliers and need the same assessment.
• Control 5.20, Addressing information security within supplier agreements. Cloud terms are supplier agreements, and the data location, backup and exit questions apply.
• Control 5.9, Inventory of information and other associated assets. Cloud services and the information in them belong in your asset inventory.
• Control 5.15, Access control. Single sign-on and access rules for cloud services are part of your access control policy.
• Control 5.18, Access rights. Accounts in services outside single sign-on are where leaver revocation fails.
• Control 8.13, Information backup. The provider protects the platform; backing up your data is usually your side of the shared responsibility line.
• Control 5.34, Privacy and protection of PII. Personal data in an unapproved service is a GDPR problem as well as a security one.

Frequently asked questions

Is control 5.23 new in ISO 27001:2022?

Yes. It was introduced in the 2022 edition and has no direct equivalent in the 2013 version. Organisations transitioning from 2013 often find it is the control with the biggest gap.

Do we need a separate cloud services policy?

You need documented processes for acquiring, using, managing and exiting cloud services. Many small businesses put this in a short standalone policy; others include it in their supplier or acceptable use policy. Either is fine, as long as it covers all four stages and people know it exists.

How do we find shadow IT?

Look at card and expense statements for software subscriptions, review the applications connected to your Microsoft 365 or Google Workspace tenant, check browser extensions where you can, and ask each team what they log into. The answers rarely match the official list the first time.

Should we ban staff from signing up to cloud services?

Require approval rather than banning outright. A ban with no easy route to yes just drives the behaviour underground. A simple, quick approval process that checks whether you already have a suitable tool works better and saves money at the same time.

What is the shared responsibility model?

The division of security between a cloud provider and its customer. The provider secures the underlying platform; the customer is responsible for how it is used, including accounts, sign-in security, configuration, sharing settings and usually backup of its own data. The exact split varies by service and is normally published by the provider.

What should a cloud exit plan include?

How you would export your data and in what format, how long it would take, what happens to the provider’s copies and how deletion is confirmed, how all accounts would be closed, and what you would move to. It does not need to be long, but it needs to exist before you need it.