ISO/IEC 27017 CSP vs CSC Role Split

The provider's scope is the cloud service and the infrastructure, platform, application, facilities, personnel, and support processes it operates for that service.

The customer's scope is its use of the service: selected features, identities, configurations, workloads, data, integrations, endpoints, and customer-run processes.

Name the purchased service and technical layer. The boundary changes between IaaS, PaaS, and SaaS and can also change by feature or service tier.

Provider owners commonly include the service owner, platform or infrastructure operations, security operations, supplier management, incident response, and customer support.

Customer owners commonly include the service owner, security and cloud engineering, identity administrators, data owners, application teams, supplier management, and the risk owner.

Assign a named owner to each action. A shared control needs at least one provider action and one customer action, not a single 'shared' label.

Provider action is triggered by service design and operation, provider changes, incidents, vulnerabilities, capacity or resilience events, supplier changes, and commitments made to customers.

Customer action starts at selection and onboarding and continues through configuration changes, access changes, new workloads or data, incidents, assurance review, renewal, and exit.

Record scheduled reviews and event triggers. A change on either side can invalidate the previous allocation.

The provider should agree and document role allocation, secure its service boundary, disclose relevant capabilities and constraints, support customer requirements, and operate the controls assigned to it.

The customer should define cloud security requirements, assess service gaps, confirm it can perform its assigned role, configure and monitor its part of the service, and add controls where needed.

Write actions as testable statements. For example: provider supplies infrastructure logs; customer enables and retains workload logs.

Useful provider evidence includes the service description, agreement, responsibility schedule, change notices, backup and logging specifications, incident process, assurance reports, and provider test results.

Useful customer evidence includes the approved architecture, configuration baseline, identity and access review, workload logs, key records, restore tests, vulnerability tickets, and risk decisions.

Link each matrix row to current evidence on both sides. Provider evidence cannot prove a customer action, and customer evidence cannot prove an opaque provider control.

Provider timing follows service releases, maintenance, assurance periods, incident procedures, vulnerability handling, supplier reviews, and contractual notice periods.

Customer timing follows onboarding, configuration and access reviews, workload changes, risk reviews, contract milestones, incident exercises, and exit.

Track each side's period and due date. An annual provider report does not set the customer's access-review or restore-test cadence.

The provider can support assurance with service documentation, contractual commitments, independent reports or certificates, customer responses, and evidence permitted by the agreement.

The customer should assess whether provider evidence is sufficient and separately evidence its own controls through operational records, internal audit, risk review, or other applicable assurance.

ISO/IEC 27017 is guidance rather than a law or a standalone certification scheme. State the separate contract, certification scope, or legal requirement that makes a control consequential.

Provider reports, certificates, service descriptions, logs, and test results can support provider-operated portions of several customer controls.

The customer can reuse provider evidence only for the covered entity, service, region, period, and control. It still needs evidence for every complementary customer action.

Record the exact claim each artifact supports, its limits and exceptions, and the customer evidence that completes the control.

Assign an action to the provider when only the provider can operate or evidence the relevant service layer.

Assign an action to the customer when it depends on the customer's choice, configuration, identity, workload, data, endpoint, or internal process.

Mark a control shared when the outcome depends on both actions. Then describe the dependency and test the end-to-end result.