Cloud security responsibility is shared. The provider handles the underlying facilities and platform. You handle what you put on it and how you configure it. How the line falls depends on the service type. Write it down per service, give each line a named owner inside your company, and review it when you adopt something new.
Where does the line fall?
The UK NCSC's guidance describes a joint responsibility for the security and availability of data and workloads in a cloud service, shared between provider and customer. The share each party owns depends on the type of service and how the provider has chosen to implement it. When you run in your own data centers you are entirely responsible. In the cloud, you delegate parts of the service and some of that responsibility.
The guidance gives examples. The provider will almost always be responsible for the availability and physical protection of its servers. For the application running on them, it depends on the service used. The NCSC advises you to cede as much responsibility as you can to a trusted provider, for instance making the provider responsible for applying security updates to all software your organisation did not write. And you will always be responsible for ensuring the service can meet your security needs and for configuring it securely.
NIST SP 800-144, on security and privacy in public cloud computing, supplies a list of considerations when outsourcing data, applications and infrastructure, which is a useful prompt list when you build the matrix.
How does it differ by service type?
Virtual machines. You patch the operating system, secure the software and manage network rules.
Managed databases and platforms. The provider patches the engine. You manage who can access it, what data it holds and how it is encrypted and backed up.
Software as a service. The provider runs almost everything. You still manage users, roles, sharing settings and the data you put in.
In each case, identity and data stay with you.
What goes wrong?
Assumption. The customer thinks the provider backs up their data, and the provider's terms say otherwise. Or the customer thinks the provider scans for public storage buckets, when the provider offers the setting and expects the customer to use it.
Gaps between teams are as common as gaps between companies. Security thinks engineering owns the cloud account roles. Engineering thinks security does.
What does a constructed matrix look like?
A company uses a cloud virtual machine service, a managed database and a SaaS ticketing tool. For each service it lists these controls: patching, network rules, user accounts, data backup, encryption keys, logging, and incident contact. Each row gets three entries: provider, customer and the named internal owner. Writing it exposes that nobody owns logging for the SaaS tool. The ticket tool holds customer support data, so that gap goes to the top of the list.
How do you keep it from going stale?
A matrix written once and filed away stops being true within months. Tie it to events you already run. Review it at each new service approval. Check it during annual contract renewals. Revisit it after each incident, asking whether a row was wrong. Keep it in the same place as your other operating documents, so people find it. When a provider changes its terms, the review gets triggered by the notice, not by chance.
How to check or apply this
- List your cloud and SaaS services, with an owner for each.
- For each service, read the provider's shared responsibility documentation.
- Build a matrix: control, provider, customer, internal owner, evidence.
- Fill every blank. A blank is an unowned risk.
- Check that your contracts and the provider's terms match the matrix, especially on backup and logging.
- Put identity and data protection at the top of your internal owner list.
- Review the matrix when you add a service, change a plan or after an incident.
- Use it for questionnaires and audits, so answers come from one source.
Quick check
Does the provider secure my data?
The provider secures its platform. You remain responsible for your data, who can access it and how the service is configured.
Who should own the matrix?
One named person, usually in security or IT, who keeps it current, with each service owner supplying their lines.
Sources
- NCSC, Cloud security shared responsibility model
- NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
Last reviewed: 18 October 2026.
