Use this workflow to decide whether provider assurance and customer-operated controls cover one defined hyperscaler service and workload.
The workflow applies ISO/IEC 27017:2015 guidance. It does not replace the organization's risk assessment, cloud agreement, applicable law, or the evidence needed for its own ISO/IEC 27001 statement of applicability.
Structured answer sets in this page tree.
Cited legal and guidance references.
Start with one service and one decision: approve its use, approve it with actions or accepted risk, or do not approve it. The workflow connects the provider's documented capabilities and commitments to the customer's own configurations, procedures, logs, tests, and risk treatment. A certificate or assurance report supports only the entities, services, locations, periods, and claims within its scope; it does not cover every customer duty.
The cloud service owner opens the review before selection or renewal and records the exact provider legal entity, service and features, service model, accounts or tenants, regions, workloads, data classes, upstream providers, agreement version, and assessment period. Treat a material scope change as a new review or a documented amendment.
ISO/IEC 27017:2015 is the published ISO edition used here. It supplements ISO/IEC 27002:2013 with cloud-specific guidance and controls for cloud service customers and providers. ISO now marks that edition for revision. ITU-T lists X.1631 (12/25) as in force and its 2015 X.1631 text as superseded, but ISO has not yet published that revision as a replacement edition of ISO/IEC 27017.
Create a signed or otherwise controlled scope record. If the team cannot identify the service boundary, data locations, agreement, or accountable owner, pause the evidence request because later coverage conclusions would be ambiguous.
Track the service scope, responsibility lines, provider claims, customer records, exceptions, approvals, and review triggers in one controlled assessment.
Assign each workflow step, request its evidence, and keep unresolved responsibility lines visible through approval.
Review your current scope, evidence gaps, and next implementation steps.
The security or control owner maps each selected control activity to the cloud service provider, the cloud service customer, or both. For a shared activity, record the hand-off: who acts first, what the other party receives, the time or event that triggers the hand-off, and the evidence each party retains.
Use the agreement and service documentation to test the provider's matrix rather than copying it. ISO/IEC 27017 says the customer and provider should agree an appropriate allocation, state both parties' roles in an agreement, and confirm that the customer can fulfil its assigned roles. The customer remains accountable for deciding to use the service; the provider is accountable for the information security stated in the cloud service agreement.
Trace the supply chain. For example, a SaaS provider running its application on another provider's IaaS is a customer for the infrastructure service and a provider to the SaaS customer. Its must connect the upstream infrastructure controls and exceptions to the downstream commitments it makes.
The evidence-pack owner requests documents against specific provider claims and responsibility lines. Record the document owner, issue date, covered period, provider entity, services, locations, exclusions, qualifications, exceptions, and any customer actions on which the conclusion depends.
ISO/IEC 27017 says the customer should request documented evidence that provider control claims are implemented. It recognizes relevant certification or independent audit evidence when there is enough transparency. If an individual customer audit is impractical or would increase security risk, the provider should supply independent evidence; if an independent audit is impractical, the standard says the provider should conduct and disclose a self-assessment and its results.
Accept the provider item only for the claim and scope it supports. A current certificate can support a management-system claim, but it does not by itself show that a particular customer configuration, feature, workload, or contract term is operating as intended.
Customer control owners attach records from the systems where the work occurred. Use configuration exports or policy state, identity and privileged-access reviews, event and monitoring records, approved changes, vulnerability and patch records, backup and recovery tests, incident exercises or records, and termination tests as applicable to the allocated activities.
Reconcile each shared activity across both sides. For incident handling, the evidence should show the reportable scope, disclosure level, notification target time, reporting route, contacts, status tracking, and any stated remedies. For monitoring, record which service aspects the customer can observe and whether access is limited to its own instances. For exit, keep the documented assets, return or export method, removal schedule, deletion expectations, and responsible parties.
If provider evidence describes a capability that the customer has not enabled, configured, monitored, or tested, mark the responsibility line incomplete. Provider availability does not show customer implementation.
The service owner and authorized risk decision-maker review the coverage table, unresolved lines, provider exceptions, customer control results, contract gaps, and applicable legal or regulatory requirements. Record one outcome: approved, approved with dated actions or explicit risk acceptance, or not approved. ISO/IEC 27017 does not supply the organization's risk acceptance authority or acceptable risk level.
Close the workflow only when every in-scope line has an owner, evidence result, exception status, decision, and review trigger. Keep source documents under access and retention controls; record references and scope rather than duplicating restricted provider reports into uncontrolled folders.
Review on the scheduled date and when the provider, service model, feature set, region, data use, architecture, agreement, upstream provider, assurance report, responsibility boundary, incident process, or applicable requirement changes. Reopen affected lines rather than reapproving the whole pack without analysis.