Allocate each cloud security activity to the provider, the customer, or both, then document the hand-off and evidence for the exact service.
ISO/IEC 27017:2015 gives guidance for both cloud service customers and providers. The resulting model must still reflect the agreement, service design, risk assessment, provider chain, and applicable law.
Structured answer sets in this page tree.
Cited legal and guidance references.
treats a shared responsibility model as the documented allocation of security activities for a defined cloud service. It should name the provider and customer duties, explain every shared hand-off, and show how each side proves that it performed its part. The provider's generic diagram is only an input because the usable allocation depends on the purchased service, enabled features, accounts, regions, workloads, data, agreement, and upstream providers.
ISO/IEC 27017 says the cloud service customer and provider should agree an appropriate allocation of information security roles and responsibilities and state both sides in an agreement. The customer should confirm that it can fulfil its allocation. Control CLD.6.3.1 adds that shared roles should be assigned to identified parties, documented, communicated, and implemented by both sides.
The customer remains accountable for the decision to use the service. The provider is accountable for the information security stated in the cloud service agreement. Allocation therefore identifies who performs each activity; it does not turn a provider commitment into proof that the customer's legal, contractual, or risk-management obligations are satisfied.
This page uses . ISO still publishes that edition and marks it for revision. ITU-T lists X.1631 (12/25) as in force and the 2015 ITU component as superseded, but ISO has not yet published the corresponding replacement edition.
Freeze the boundary first: provider legal entity, service and enabled features, service model, accounts or tenants, regions, workloads, data classes, agreement, customer owner, and provider chain. Then break each control into activities small enough to assign. 'Logging is shared' is too vague; separate log generation, access, export, retention, alerting, investigation, and provider-to-customer notification.
Map at least identity and privileged access, configuration, asset ownership, vulnerability handling, logging and monitoring, backup and recovery, incident handling, data protection, cryptography, changes, continuity, evidence requests, and termination. The exact technical split varies with the service. For example, ISO/IEC 27017 notes that application software belongs to the customer in typical PaaS or IaaS use, while the provider supplies it in SaaS.
For each activity, record the accountable party, performing party, agreement or service-document reference, expected evidence, frequency or event trigger, hand-off, exception route, and customer decision. If a preset provider control leaves a gap against the customer's requirements, the standard says the customer may need an additional control of its own.
For incidents, the provider should define the allocation of incident-management responsibilities in the service specification and document the incident scope it reports, disclosure level, target notification time, notification procedure, contact information, and any remedies. The customer should verify that allocation against its own requirements and keep a route to report events and track status.
For monitoring, the customer should request the capabilities available for each service. The provider should supply relevant monitoring for the customer's own service instances, protect access to it, document it, and provide data consistent with event logs and service-level terms. The customer then decides who reviews that data, which conditions alert, and how findings are handled.
For termination, the customer should request a documented process covering return or removal of its assets and deletion of copies. The agreement should identify the assets and schedule. For potential digital evidence, both parties should agree how they will respond to requests for evidence or other cloud-environment information.
An organization can be a cloud service customer and a cloud service provider at the same time. A SaaS provider using an upstream infrastructure service has customer duties toward the infrastructure provider and provider commitments toward its own customers. Its downstream matrix must not assign an activity to 'the provider' without identifying which provider performs it.
ISO/IEC 27017 says a provider using peer cloud providers should ensure that the information security levels offered to its own customers are maintained or exceeded. It should give suppliers information security objectives and request their risk-management activities. The downstream organization still needs evidence that upstream scope, incidents, changes, locations, continuity, and termination arrangements support its promises.
Where the upstream agreement or evidence does not support a downstream commitment, record the gap. The available choices are to change the commitment or architecture, add a control, obtain better terms or evidence, accept the risk through the authorized process, or reject the use.
Keep the approved matrix with the agreement references, provider documentation and assurance, customer configuration and operating records, exceptions, risk decisions, and review history. A policy label or provider matrix shows intent; evidence from the covered period shows whether the allocated activity operated.
Test provider-owned lines against the exact entity, service, period, locations, exclusions, subservice organizations, exceptions, and customer dependencies in the available evidence. Test customer-owned lines against configuration state, access reviews, logs, changes, vulnerability treatment, backup and recovery tests, incidents, and other records relevant to that service. Test shared lines from trigger through both parties' actions to closure.
Review before selection and at planned intervals, and after changes to the provider, service model, features, region, accounts, workloads, data use, architecture, agreement, provider chain, assurance evidence, incident process, or applicable requirement. Update affected operating procedures, risk records, contracts, and evidence requests when the allocation changes.
Connect each provider, customer, and shared activity to the agreement, an operating owner, evidence, an exception route, and a review trigger.
Turn the service-specific responsibility matrix into assigned control checks, evidence requests, and review actions.
Review your current scope, evidence gaps, and next implementation steps.