Provider shared responsibility diagrams show layers, not controls, so when an auditor asks who patches, who reviews access or who keeps the logs for a specific service, the answer is often a guess. This template turns the shared responsibility model into a control by control matrix for each cloud service, SaaS application and managed service provider (MSP) arrangement, using the customer responsibility format familiar from FedRAMP: for each control, who implements it, how, and what the customer must do. It is for cloud security, GRC, procurement and vendor management teams. The concepts and the differences between providers' models are covered in the Shared Responsibility Models Guide; this page is the working document.
How to use this template
- One matrix per service: complete a copy for each IaaS account or subscription model, each PaaS service family, each critical SaaS application and each MSP contract. Responsibilities differ even within one provider: the AWS model notes that for Amazon EC2 the customer manages the guest operating system and patches, while for abstracted services such as Amazon S3 the provider runs the operating system and platform.
- Replace placeholders: [Organisation], [Provider], [Service], [MSP] and role titles in square brackets.
- Use the responsibility codes in section 3 for every row. A row with no code or "TBC" is an open risk, not a completed row.
- Fill the customer action column in plain words: "enable MFA for all admin accounts in the tenant" is useful; "customer responsible" is not.
- Attach evidence: the provider's attestation (SOC 2 report, ISO/IEC 27001 certificate, FedRAMP package where relevant) for rows the provider owns, and your own configuration evidence for the rest.
- Review annually and whenever the service tier, deployment model or MSP scope changes.
1. Purpose and scope
1.1 This matrix records, for each security control, whether [Provider] or [MSP], [Organisation], or both implement it for [Service], and what [Organisation] must do to meet its share.
1.2 It supports NIST SP 800-53 Rev. 5 SA-9 External System Services and NIST CSF 2.0 GV.SC-02 (cybersecurity roles and responsibilities for suppliers, customers and partners are established, communicated and coordinated) and ID.AM-04 (inventories of services provided by suppliers are maintained).
1.3 Service details: [Service name] · Service model: [IaaS / PaaS / SaaS / MSP] · Data classification: [ ] · Business owner: [ ] · Contract reference: [ ] · Provider assurance: [report type and period].
2. Roles
| Role | Responsibility |
|---|---|
| [Service Owner] | Accountable for the matrix being complete and for customer-side controls being operated |
| [Cloud Security Lead] | Interprets provider documentation, fills technical rows and verifies configuration |
| [Vendor Manager] | Obtains provider assurance reports and ensures contract terms match the matrix |
| [MSP Account Manager] (where used) | Confirms rows the MSP performs and signs the matrix on behalf of the MSP |
| [GRC Lead] | Maps rows to the control framework and tracks gaps |
3. Responsibility codes
3.1 Codes are adapted from the control origination values used in FedRAMP system security plans, as reproduced in GSA's OSCAL generator tool, so that matrices from FedRAMP providers can be read across directly.
| Code | Meaning | FedRAMP origination equivalent |
|---|---|---|
| P | Provider implements fully; customer inherits and relies on provider assurance | Service Provider Corporate, Service Provider System Specific or Service Provider Hybrid |
| S | Shared: provider and customer each implement part; both parts are described | Shared (Service Provider and Customer Responsibility) |
| CC | Customer configures a capability the provider supplies | Configured by Customer (Customer System Specific) |
| C | Customer provides the control entirely | Provided by Customer (Customer System Specific) |
| I | Inherited from another authorised or assured service the provider builds on | Inherited from pre-existing FedRAMP Authorization |
| M | MSP implements on the customer's behalf under contract | No direct equivalent; record the contract clause |
4. Default split by service model
4.1 Start from this baseline and adjust per service. It follows the Microsoft Azure responsibility table, which shows customer data, configurations and settings, and identities and users as the customer's responsibility in every model, and is consistent with the AWS and Google Cloud descriptions, which say the customer always remains responsible for data and access. Providers are listed alphabetically.
| Layer | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Data, classification and retention | C | C | C | C |
| Identities, users and access policies | C | C | C | C |
| Configurations and settings | C | C | C | C |
| Client devices | C | C | C | S |
| Applications | C | C | S | S |
| Network controls | C | C | S | P |
| Operating system | C | C | P | P |
| Physical hosts, network and datacentre | C | P | P | P |
| Provider | How its model is framed |
|---|---|
| Amazon Web Services | Security "of" the cloud (provider) versus security "in" the cloud (customer); control types described as inherited, shared and customer-specific, with patch management, configuration management and awareness and training as shared examples. |
| Google Cloud | Responsibility shifts towards the provider from IaaS to PaaS to SaaS, with the customer always responsible for access policies and data; "shared fate" adds secure blueprints, landing zone guidance and posture tooling to help customers with their share. |
| Microsoft Azure | A ten-row table across on-premises, IaaS, PaaS and SaaS, with customer data, configurations and settings, and identities and users always the customer's, and applications and network controls shared in PaaS. |
5. Control matrix
5.1 Complete one row per control. Control IDs are from NIST SP 800-53 Rev. 5; replace or add columns for ISO/IEC 27001:2022 Annex A or your internal framework.
| Control | Code | Provider or MSP implementation | Customer action required | Evidence |
|---|---|---|---|---|
| AC-2 Account management | [CC] | [Provider supplies identity service and admin roles] | [Federate to corporate IdP; joiner-mover-leaver; quarterly admin review] | [Review records] |
| IA-2 Identification and authentication (MFA) | [CC] | [MFA capability available] | [Enforce phishing-resistant MFA for all privileged users] | [Policy export] |
| AC-6 Least privilege, including service accounts and API keys | [C] | [Role model and scoped credentials available] | [Scope roles, inventory and rotate non-human credentials] | [Role assignments, key inventory] |
| AU-2, AU-6 Event logging and review | [S] | [Generates platform audit logs; retention [n] days on current tier] | [Export to SIEM; retain [n] months; review alerts] | [SIEM source list] |
| CM-6 Configuration settings | [CC] | [Secure defaults where documented] | [Apply baseline; scan for drift] | [Baseline report] |
| SI-2 Flaw remediation (patching) | [S / P] | [Patches infrastructure and managed platform] | [Patch guest OS, images, containers and application code] | [Patch reports] |
| SC-8, SC-28 Encryption in transit and at rest | [S] | [Encryption by default with provider-managed keys] | [Choose key option; manage customer-managed keys if required] | [Key configuration] |
| SC-7 Boundary protection | [S] | [Network isolation of the platform] | [Configure security groups, private endpoints, IP allow lists] | [Network config] |
| CP-9 System backup | [S] | [Platform resilience; provider backup scope: ...] | [Back up customer data to meet RPO; test restore] | [Restore test] |
| IR-6 Incident reporting | [S] | [Notifies customer of provider incidents within [n] hours per contract] | [Detect and respond to incidents in tenant; maintain contacts] | [Contract clause, playbook] |
| PE-3 Physical access control | [P / I] | [Datacentre physical security] | [Review provider assurance report annually] | [SOC 2 / ISO certificate] |
| PS-7 External personnel security | [P / M] | [Provider or MSP staff vetting and access controls] | [Confirm in contract; review MSP staff with access] | [Contract, access list] |
| CA-3 Information exchange (integrations) | [C] | [Integration and API capability] | [Approve and register each integration; least-privilege scopes] | [Integration register] |
| [Add rows] |
6. MSP arrangements
6.1 Where an MSP operates a service, record each row's code as M only where the contract names the activity. Activities the MSP performs informally remain the customer's responsibility.
6.2 For each MSP record: privileged access the MSP holds in [Organisation]'s tenants, how that access is granted and reviewed, the identities and credentials the MSP uses (named accounts, delegated admin relationships, API keys), logging of MSP actions, and the exit procedure that removes all MSP access. See the GDAP and MSP Delegated Admin Access Guide.
| Activity | Code | MSP obligation (contract clause) | [Organisation] retains |
|---|---|---|---|
| Patch servers and endpoints | [M] | [Clause ref, SLA] | [Approve exceptions; verify monthly report] |
| Monitor alerts 24x7 | [M / S] | [Clause ref, escalation times] | [Incident decisions; regulator notification] |
| Administer identity provider | [M / S] | [Clause ref] | [Approval of privileged role grants; access reviews] |
| Backups and restore tests | [M] | [Clause ref, test frequency] | [Define RPO and RTO; witness restore test] |
| MSP's own access security | [M] | [MFA, named accounts, logging of MSP actions] | [Review MSP access quarterly; revoke at exit] |
7. Gaps, sign-off and review
7.1 Any row where neither party clearly owns the control is recorded as a gap with an owner and a target date.
7.2 Sign-off: [Service Owner] and [Provider or MSP representative, where the contract allows] · Date: [ ] · Next review: [ ].
7.3 The matrix is reviewed annually, on contract renewal, on change of service tier, and after any incident involving the service.
Implementation guidance
- Start with the provider's own material. Many providers publish a customer responsibility matrix, a control implementation summary or a responsibility table in their compliance documentation; FedRAMP authorised services document customer requirements in a customer responsibility matrix (CRM). Copy their split into section 5 rather than guessing.
- Prioritise the always-customer rows. Data, identities and configuration are yours in every model, and most cloud and SaaS incidents start there. Complete AC-2, IA-2, AC-6, CM-6 and AU-6 first.
- Check the tier. Log retention, customer-managed keys and some security features depend on licence or service tier. Record the current tier in section 1.3 and recheck rows when it changes.
- Verify, then sign. For CC and C rows, collect configuration evidence before marking complete; for P rows, read the relevant section of the provider's assurance report, including its complementary user entity controls, which are customer obligations.
- Align the contract. Every M row and every provider notification commitment should match a clause. Raise mismatches with procurement before renewal.
- Exercise it. Run a tabletop for a tenant compromise and a provider outage; note every decision where the matrix did not answer who acts.
Common failure patterns
- Diagram used as the matrix: a layer diagram is filed as evidence, and nobody owns log export, key management or integration approval.
- SaaS assumed to be fully provider-owned: tenant configuration, admin accounts, OAuth integrations and API tokens are always the customer's. See the SaaS Security Guide.
- Complementary user entity controls ignored: the provider's SOC 2 report lists controls the customer must operate, and they never reach the matrix.
- MSP scope by assumption: the customer believes the MSP monitors alerts at night; the contract covers business hours only.
- Non-human identities unowned: service accounts and API keys created by the provider's onboarding or by an MSP have no named owner on either side.
Measuring whether it works
- Coverage: share of critical services with a completed, signed matrix.
- Open gaps: number of rows with no clear owner, and their age.
- Evidence currency: share of P rows backed by an assurance report less than 12 months old.
- Contract alignment: share of M rows matched to a contract clause.
- Exercise findings: responsibility questions the matrix failed to answer in the last tabletop, trending down.
Small vs large organisations: a small organisation using a few SaaS products and one MSP can keep one matrix per service in a spreadsheet and focus on the always-customer rows and the MSP table. A large organisation should hold matrices in its GRC tool, linked to the control framework, so that one control test can be traced to every service that relies on it. For assessing providers themselves, see the MSP Security Questionnaire Template and the FedRAMP Guide.
Standards and references
- NIST: SP 800-53 Rev. 5 (SA-9 External System Services)
- NIST: Cybersecurity Framework 2.0
- GSA: OSCAL generator tool (FedRAMP control origination values)
- Amazon Web Services: Shared Responsibility Model
- Google Cloud: Shared responsibilities and shared fate
- Microsoft Learn: Shared responsibility in the cloud
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Shared Responsibility Models Guide · Cloud Security Guide · PCI DSS for Service Providers and Responsibility Matrix Guide · Security RACI Matrix Template