Information Security Management
Cloud Security Policy: What ISO 27001 Control 5.23 Expects and How to Write One
Most small businesses run almost entirely on cloud services: Microsoft 365 or Google Workspace, a CRM, an accounting platform, a dozen SaaS tools that somebody signed up for with a company card, and for software companies, AWS or Azure underneath the product. ISO 27001:2022 added a control specifically for this, 5.23, because the previous edition treated cloud providers as just another supplier and that was not working. The cloud security policy is how you meet it.
The complete toolkit, every policy, template and record you need. Free, no commitment
This guide covers what the control asks for, the shared responsibility problem the policy has to solve, what to put in it, a worked example of a service being approved, and the template from our toolkit.
Free cloud services policy template (Word)
The template is the cloud services policy from our toolkit. It sets out the approval process in three steps (business request, IT assessment and risk review, management approval), with the evaluation criteria for data security, authentication, platform, service and administration, and points to the supplier review record and the cloud service catalogue that complete the set.
It is one of 18 policy templates in the free ISO 27001 toolkit, which also has the cloud service catalogue and the SaaS vendor evaluation sheet.
What control 5.23 requires
Control 5.23, information security for use of cloud services, says that processes for the acquisition, use, management and exit from cloud services shall be established in accordance with the organisation’s information security requirements. Four stages, and the policy needs to cover each:
- Acquisition. How a new cloud service is proposed, assessed and approved before anyone puts company data in it.
- Use. The rules for configuring and operating it securely once it is in: who administers it, how access works, what data may go in it.
- Management. Keeping track of what you have (a cloud service register), reviewing providers, monitoring for changes to their terms or security.
- Exit. Getting your data out, and making sure the provider deletes it, when you stop using the service.
The control sits next to the supplier controls (5.19 to 5.22), and the guidance expects you to treat cloud providers as suppliers with some extra questions: where the data is, who can access it, what the provider’s own security looks like, and what happens when the relationship ends.
The shared responsibility problem
The reason cloud gets its own control is that responsibility for security is split between you and the provider, and the split is different for every service. The provider secures the platform; you secure what you put on it and how you configure it. Microsoft will not stop your staff sharing a SharePoint folder with “anyone with the link”. AWS will not stop you leaving a storage bucket public. Your accounting SaaS will not turn on multi-factor authentication for you.
The policy’s job is to make that split explicit for each service, so that nobody assumes “it’s in the cloud, so it’s backed up” or “it’s Microsoft, so it’s secure”. Both are the beginning of a sentence, not the end of one.
What to put in the policy
- Scope. Every cloud service that holds or processes company information, including the ones individuals sign up for. Say explicitly that personal sign-ups for work purposes are in scope; that is where the shadow IT lives.
- Approval process. Nobody introduces a cloud service without a request, an assessment and an approval. Keep the process proportionate: a free note-taking app and a new payroll platform do not need the same depth, but both need to be recorded.
- Assessment criteria. What you check before approving: the provider’s security credentials (ISO 27001, SOC 2, Cyber Essentials), data location and transfers, backup and recovery responsibility, authentication (single sign-on and MFA), administration and privileged access, export formats and lock-in, SLAs and support, contract terms including data deletion on exit.
- Cloud service register. The list of approved services with owner, data classification, provider assurance, renewal date and exit arrangements. This is the evidence the auditor asks for first.
- Secure configuration. MFA on for all users; single sign-on where available; least privilege; sharing settings locked down by default; logging enabled; the vendor’s own security baseline applied.
- Access management. Joiners, movers and leavers applied to every service, not just the main ones. The leaver who still has the CRM login six months later is the classic finding.
- Data handling. Which classifications of data may go in which services; what must be encrypted; the retention rules that apply (see the data retention policy).
- Monitoring and review. Annual review of each provider’s assurance, terms and performance; watching for breach notifications and material changes to the service.
- Exit. Before signing: how you get your data out and in what format. On leaving: export, verify, confirm deletion with the provider, remove from the register, revoke integrations.
- Responsibilities and exceptions. Who approves, who owns each service, how to request an exception.
Worked example: approving a new service
A 25-person consultancy wants to adopt a new project management SaaS. Here is how the policy plays out.
| Stage | What happens |
|---|---|
| Request | The operations lead raises a request stating the business need and the data that will go in it (client names, project plans, some contract documents: classified Internal and Confidential) |
| Existing options | IT checks whether Microsoft Planner, already licensed, meets the need. It does not, for stated reasons |
| Assessment | The provider holds ISO 27001 and SOC 2 Type II; data is hosted in the EU with no transfers outside; SSO via Microsoft Entra and MFA are supported; backups are the provider’s responsibility with 30-day point-in-time restore; full export to CSV and JSON; contract includes deletion within 30 days of termination; two named admins |
| Supplier review | Recorded on the supplier review form; overall risk assessed as low with MFA and SSO enforced |
| Approval | Approved by the Information Security Manager; added to the cloud service register with the operations lead as owner and a 12-month review date |
| Configuration | SSO enforced, MFA required, guest sharing disabled, audit logging on, integration with Microsoft 365 reviewed and approved |
| Exit plan | Noted in the register: quarterly export to SharePoint as a safeguard; on exit, final export, deletion confirmation requested in writing |
The whole thing takes a couple of hours. Without the policy it takes five minutes and a credit card, and the auditor finds it in the expenses.
For software companies: your own cloud
If you build on AWS, Azure or Google Cloud, control 5.23 covers that too, and the auditor will spend more time on it than on your SaaS tools. The policy (or a separate cloud platform standard it points to) needs to cover: identity and access to the cloud console, with MFA and no shared root accounts; a secure baseline for the services you use; infrastructure as code or at least change control; logging and monitoring; backup and recovery you have tested; and the provider’s shared responsibility model written down for your architecture. This is where small software businesses most often have strong engineering practice and no documentation of it. The engineering is the control; the documentation is what gets you through the audit.
Mistakes I see most at audit
- No register. The business cannot say how many cloud services it uses. The auditor asks finance for the subscription list and the number is always larger.
- Approval process on paper only. The policy describes a process; the last three services were adopted without it.
- MFA not enforced. Available, recommended, not on for everyone. Since Cyber Essentials v3.3 this is also a Cyber Essentials failure.
- Backups assumed. Nobody has checked what the provider restores, or tested it.
- Exit not considered. Data stuck in a service that is being cancelled, with no export and no deletion confirmation.
- Leavers. Removed from Microsoft 365, still in six other tools.
Where to go next
Cloud services are suppliers, so the policy works alongside your supplier security controls (5.19 to 5.22). The acceptable use policy tells staff not to sign up for tools on their own; the data retention policy says how long data lives in them. For the full control set see the Annex A guide and the controls list, for the other policy guides the ISO 27001 policies hub, and for help building the ISMS our ISO 27001 consultancy service covers cloud and supplier controls with you.
Frequently asked questions
Does ISO 27001 require a cloud security policy?
Control 5.23 of ISO 27001:2022 requires processes for acquiring, using, managing and exiting cloud services in line with your security requirements. A cloud security (or cloud services) policy with an approval process and a register of services is the normal way to meet it, and it was added in the 2022 edition precisely because cloud use needed its own control.
What should a cloud security policy include?
Scope covering every cloud service including personal sign-ups for work; an approval process with assessment criteria (provider assurance, data location, backup responsibility, SSO and MFA, administration, export and exit terms); a register of approved services with owners; secure configuration and access management rules; data handling and retention; periodic review; and an exit process.
What is the shared responsibility model?
The split between what the cloud provider secures (the platform, the data centres, the underlying service) and what the customer secures (their data, their users, their configuration, their access settings). It differs by service and by provider, and the policy’s job is to make the customer’s side explicit for each service you use.
Do I need a register of cloud services?
Yes, in practice. It is the first thing an auditor asks for under control 5.23 and the one most small businesses do not have. It lists each approved service, its owner, the data it holds, the provider’s assurance, the review date and the exit arrangements.
Does control 5.23 apply to AWS or Azure as well as SaaS tools?
Yes. If you build your own product or infrastructure on a cloud platform, the control covers that too, and the auditor will spend more time on it: console access with MFA, secure baselines, change control, logging, tested backups and a documented shared responsibility model for your architecture.
ISO 27001 Online Course + Full Toolkit
Stop guessing. Follow a proven step-by-step process.
“Highly recommended for anyone looking to understand ISO 27001, whether attempting it on your own or even using a consultant.“
Verified customer review
£285
Instant access
✓ Full toolkit included ✓ Learn as you build ✓ 12-month access ✓ 6 hours of video ✓ Call + email support
Author Background
This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.
With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.
Qualifications: Certified ISO/IEC 27001:2022 Lead Auditor,
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.
Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.
