The cloud shared responsibility model

For cloud services, your organisation is always responsible for making sure all five Cyber Essentials controls are in place. Some of them can be carried out by the cloud provider, and which ones depends on the type of service. Where you rely on the provider for a control, it must have committed to it in its contract or in documents the contract refers to. User access control is always yours.

The three service types

Requirements v3.3 describes three types of cloud service:

• Infrastructure as a Service (IaaS). The provider gives you virtual servers and networking, and you configure and manage them much as you would physical kit. Examples include Amazon EC2, Google Compute Engine and Rackspace.
• Platform as a Service (PaaS). The provider runs the underlying infrastructure and you supply and manage the applications. Examples include Azure Web Apps and AWS Lambda.
• Software as a Service (SaaS). The provider delivers the application and you configure it. You must still make sure it is configured securely. Examples include Microsoft 365, Dropbox and Gmail.

Who typically does what

This summary follows Table 1 in version 3.3. It shows who might typically implement each control. The real split depends on how a particular service is designed.

Two points stand out. First, user access control is your job on every type of service: accounts, admin separation, leavers and MFA. Second, secure configuration is shared even for SaaS. A provider can ship a secure platform, but you choose the sharing settings, guest access, unused features and default options in your tenant.

In practice

• SaaS, such as Microsoft 365 or Google Workspace. The provider patches the application and runs its network defences. You manage users and admins, turn on MFA for every account, remove unused accounts and integrations, and review settings such as external sharing.
• PaaS. The provider patches the platform. You manage your application code and dependencies, access to the management console, and any network rules the platform exposes to you.
• IaaS, such as virtual machines. You treat each virtual server much like a physical one: patch the operating system and software within 14 days for critical and high fixes, run malware protection, disable auto-run, set security groups to deny inbound traffic by default, and protect admin access. The provider looks after the physical hosts and hypervisor.

The provider-commitment point

Version 3.3 says that where the provider implements a control on your behalf, you must make sure it has committed to doing so through contract clauses or documents referenced by the contract, such as security or privacy statements. Providers usually describe this in a trust centre page about their shared responsibility model.

You do not need a bespoke contract. You need to know where the commitment is written down, and to be able to point to it if your assessor asks.

What to do

1. List each cloud service and label it IaaS, PaaS or SaaS. Some products mix types, so label what you actually use.
2. For each service, note which controls you carry out and which the provider carries out.
3. Find and save the link to each provider's shared responsibility or security documentation.
4. Do your part: accounts and MFA everywhere, secure tenant settings, and for virtual servers the full set of device controls.
5. Review the list at renewal, since new services and features change the split.

See also cloud services in scope and MFA for cloud services.