ISO Compliance Insights & Best Practices

Shared Responsibility Matrix: A Clear Guide for ISO 27017

A shared responsibility matrix is the document that decides who patches the operating system, who configures the encryption and who notices the failed backup. ISO 27017 exists largely because those questions have two possible answers in cloud computing, and the standard’s most-cited control asks the provider and the customer to agree and document the split.

This guide covers what belongs in the matrix, how to build one that survives an audit, and the failure that turns a signed contract into an unprotected system.

Shared responsibility matrix: how responsibility divides across IaaS, PaaS and SaaS — The same control sits with a different party depending on the service model.

Why the matrix exists

In an on-premises system one organization owns every layer. In cloud computing the layers are split between a provider and a customer, and the split moves with the service model. Nobody disputes this in principle; the trouble is that both parties often assume the other holds a given control, and neither holds it.

ISO 27017 addresses that directly. The extension exists because responsibility in cloud computing is divided, and divided responsibility is where things get dropped — its cloud-specific controls include one asking that shared roles and responsibilities be allocated and documented, and another extending that allocation to the wider chain of cloud partners rather than just the two names on the contract.

What goes in a shared responsibility matrix

Layer	IaaS	PaaS	SaaS
Physical and facility	Provider	Provider	Provider
Hypervisor and host	Provider	Provider	Provider
Guest OS and patching	Customer	Provider	Provider
Application configuration	Customer	Customer	Customer
Identity and access	Customer	Customer	Customer
Data and classification	Customer	Customer	Customer
Backup and recovery	Customer	Shared	Shared — read the terms
Logging and monitoring	Shared	Shared	Shared — depends on what is exposed

Treat that shared responsibility matrix as a starting shape, not an answer. The genuinely load-bearing rows are the ones marked shared, because “shared” is where both parties do part of the work and each assumes the other does the rest. Every shared row needs a sentence saying exactly which part belongs to whom.

The rows people get wrong

Backup in SaaS. The provider backs up its platform to recover from its own failures. That is not the same as being able to restore your data after a user deletes it or a synchronization error propagates, and the retention period in the terms is usually shorter than anyone assumes.

Logging. The provider may generate the logs and still not retain them for as long as you need, or expose them in a form your monitoring can consume. Availability, retention and export are three separate questions.

Identity. Almost always the customer’s, almost always under-resourced. Provider-side identity features exist, but configuring them, reviewing access and removing leavers is customer work in every service model.

Building a shared responsibility matrix that survives an audit

Do it per service, not per provider. One vendor may supply you with IaaS, PaaS and SaaS, with a different split in each. A single matrix headed with the vendor’s name is a fiction.
Anchor rows to your control set. Whether that is ISO 27002, the Cloud Controls Matrix or an internal library, each row should name the control so the matrix and the Statement of Applicability agree.
Record the evidence source for provider rows. A certificate, an assurance report or a contractual commitment — something you could produce when an auditor asks how you know the provider does it.
Extend it down the chain. If your provider subcontracts, the allocation reaches the subcontractor, and ISO 27017’s guidance is explicit that responsibility is allocated across everyone in the chain rather than just the two contracting parties.
Review it on change. A new service tier, a migration or a provider’s own change to defaults can move a row without anyone telling you.

The test of a good shared responsibility matrix is simple: hand it to somebody on call and ask who fixes a named failure. If they have to interpret it, it is not finished.

Where this connects

The matrix is the artefact several regimes ask for in different words. ISO 27017 asks for the roles and responsibilities to be agreed and documented per service. CSA STAR’s questionnaire asks which actor implements each control, so a completed matrix substantially populates a CAIQ — see our guide to the Cloud Controls Matrix. Assurance reports carry the same idea as complementary user entity controls: the things the report’s readers must do for the provider’s controls to work.

Note the edition position on the standard itself: ISO/IEC 27017:2026 replaced the 2015 edition in July 2026, and the old CLD control identifiers no longer exist — the cloud controls now sit inside the ISO 27002:2022 numbering. Documentation citing CLD numbers is describing a withdrawn edition. Our guide to ISO 27017 and what the 2026 edition changes has the mapping.

Frequently asked questions

Does the provider supply the shared responsibility matrix?
Most publish a model, and it is a useful starting point. It is not your matrix: it describes their general position, not your service, your configuration or your data.

Is it a contractual document?
It should be traceable to contractual commitments, but the matrix itself is usually an operational artefact. Where a row matters commercially, get the commitment into the agreement rather than the diagram.

What about multi-cloud?
One matrix per service, and a register listing them. Averaging across providers hides exactly the differences that cause incidents.

Who owns it internally?
Whoever owns the service relationship, reviewed by security. A matrix owned only by security tends to describe intentions rather than operations.

How often should it be reviewed?
On change, and at least annually alongside the supplier review. Provider defaults move quietly.

Where this leaves you

Build a shared responsibility matrix per cloud service, anchored to your control set, with a named evidence source behind every provider row and a sentence of detail behind every shared one. Extend it to subcontractors, review it when the service changes, and test it by asking somebody on call who fixes what. The controls nobody owns are the ones that fail, and this is the only document whose job is to find them before an incident does.

References

ISO/IEC 27017:2026 — cloud services information security controls, including shared roles and responsibilities.
CSA — Cloud Controls Matrix — the framework that asks which actor implements each control.