Practical toolGlobalISO/IEC 27017

ISO/IEC 27017 Cloud Provider Checklist

Use this ISO/IEC 27017 checklist to decide whether a specific cloud service can meet the customer's security requirements and what each party should operate.

The checklist follows ISO/IEC 27017:2015 guidance. It is not an official form, a universal control set, or proof of certification. Adapt it to the service risk, agreement, architecture, jurisdiction, and the edition used.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
5

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Use this checklist to evaluate a cloud provider and the customer's ability to use the service securely. It is not a universal pass/fail certification checklist: select depth and evidence from the service risk, contract, architecture, and applicable legal or regulatory requirements.

Section 1

Can this provider and customer operate the service securely?

Start with the legal provider entity, named service, deployment and service models, regions, data and workloads, administrators, interfaces, upstream providers, business dependency, and exit constraints. Evidence for another service, entity, region, or period does not answer the assessment.

Compare the customer's requirements with the provider's fixed and configurable capabilities before contracting. For every gap, choose another service, add an enforceable commitment, implement a customer control, or obtain authorized risk acceptance.

Confirm that the agreement allocates provider, customer, and shared responsibilities. ISO/IEC 27017 specifically addresses access, backup, cryptography, vulnerability management, incidents, testing, audit evidence, logging, continuity, and protection of information when the agreement ends.

Test relevant operations, including tenant isolation, virtual-machine and network configuration, privileged access, monitoring, logs, backup and recovery, incident notification, and supervised critical operations. The exact split changes with the service model and provider design.

  • Scope: name the service, provider entity and chain, service and deployment models, regions, tenant, workloads, data classes, administrators, interfaces, and critical dependencies.
  • Responsibilities: assign provider, customer, and shared duties for identity, configuration, backup, logging, monitoring, incidents, vulnerability handling, continuity, evidence, and termination.
  • Agreement: document security roles, jurisdictions, change notice, incident scope and notification target, audit or independent evidence, support contacts, return and removal of assets, deletion, and exit timing.
  • Isolation: verify how the provider separates tenants and its administration environment from customer resources; for virtual machines, assign hardening of required ports, protocols, services, malware protection, and logging.
  • Operations: identify critical provisioning, change, deletion, backup, restoration, and termination operations; document procedures and the supervision required to prevent unrecoverable damage.
  • Monitoring and logs: define the events and service aspects the customer should be able to see, access controls for monitoring, retention and export needs, and the boundary between infrastructure, platform, application, and customer logs.
  • Seven-control coverage: record a result for shared roles, asset removal, tenant segregation, virtual-machine hardening, administrator operations, customer monitoring, and virtual/physical network alignment; mark a line not applicable only with a service-specific rationale.
  • Evidence and decision: record the evidence period and scope, gaps, compensating controls, residual risk, approver, corrective actions, and the next scheduled and event-driven review.
Section 2

Which records show the provider assessment is complete and current?

Completion requires evidence for both sides of the responsibility boundary. A provider report can support controls operated by the provider, but it does not show that the customer enabled logging, restricted administrators, hardened workloads, or tested recovery.

Record the evidence's service scope, provider entity, locations, period, exceptions, and method. Where individual customer audits are impractical or add security risk, ISO/IEC 27017 allows for independent evidence, with sufficient transparency, or a disclosed provider self-assessment when an independent audit is impractical.

  • Provider evidence: service control description, current independent report or disclosed self-assessment, tenant-isolation design, administrator controls, logging and monitoring documentation, incident procedure, continuity evidence, and termination process.
  • Customer evidence: approved architecture and configuration baseline, access and privileged-operation reviews, workload logs, backup and restoration tests, vulnerability records, incident contacts, and exit test.
  • Contract evidence: , security schedule, locations and jurisdictions, change notice, incident notification terms, evidence access, remedies where agreed, and asset return, removal, and deletion terms.
  • Decision evidence: requirements, gaps, treatment, exceptions, residual risk, accountable service owner, approver, actions, and review triggers.
Section 3

Who completes the checklist, and when?

The customer service owner coordinates the assessment with security, architecture, legal or procurement, privacy where applicable, operations, and the provider. Control owners supply evidence for their allocated duties; only an authorized risk owner accepts unresolved residual risk.

Run the checklist before selection or renewal, then repeat it after material changes to the service, region, provider chain, architecture, , contract, or applicable requirements. Incidents, failed tests, and expiring assurance are additional triggers.

  • Intake owner: records the service scope, business dependency, data, workloads, locations, provider chain, and proposed agreement.
  • Security and architecture owners: assess risks, provider capabilities, isolation, identity, configuration, logging, monitoring, resilience, and customer controls.
  • Legal or procurement owner: confirms responsibility, evidence, change, incident, jurisdiction, continuity, and termination terms.
  • Service and risk owners: approve the treatment, reject the service, or accept documented residual risk; the service owner tracks actions and reviews.
Section 4

What makes the checklist unreliable?

A yes/no answer without scope, owner, evidence, exception, and review trigger is not enough to support a service decision. Reject marketing claims and certificates that do not cover the named provider entity and service.

Do not assume that the provider performs a control because it operates the infrastructure. ISO/IEC 27017 notes, for example, that IaaS customers may be responsible for backing up data produced in their environment and for logging events in their own virtual machines and applications.

  • Do not apply one to every SaaS, PaaS, and IaaS service.
  • Do not treat a provider certificate as proof of customer-managed configuration or operation.
  • Do not accept vague exit language that omits the assets, timing, return or removal process, and deletion of copies.
  • Do not hide evidence limitations or exceptions; route them to corrective action or authorized risk acceptance.
Section 5

How should the completed review be maintained?

Keep the checklist with the risk decision and evidence index. When a trigger occurs, reopen the affected checks and update the , control evidence, agreement record, and downstream operating procedures together.

As of 24 July 2026, ISO lists Edition 2 of ISO/IEC 27017 as under publication and intended to replace the 2015 edition. Record the edition now, then assess the published replacement before changing control identifiers or evidence mappings.

  • Set a scheduled review and triggers for service, supplier, contract, location, architecture, risk, and standard-edition changes.
  • Track findings to closure and retain the approval for accepted residual risk.
  • Retire superseded evidence so reviewers can identify the current decision and period.
Recommended next step

Keep the responsibility boundary current

Assign each check, attach service-specific evidence, record exceptions and approvals, and reopen the assessment when the service or provider boundary changes.

Primary sources

References and citations

iso.org
Referenced sections
  • Supports keeping cloud-provider checklist decisions inside the ISMS evidence, ownership, and review process.
"Information security, cybersecurity and privacy protection — Information security management systems — Requirements"
iso.org
Referenced sections
  • Supports the underlying information-security control catalogue used when mapping cloud-provider checklist evidence to controls.
"Information security controls"
iso.org
Referenced sections
  • Confirms ISO/IEC 27017 is the cloud-services control guidance this checklist maps into provider and customer responsibilities.
"Code of practice for information security controls based on ISO/IEC 27002 for cloud services"
handle.itu.int
Referenced sections
  • Supports the provider and customer evidence split, including independent evidence, monitoring, logging, responsibility records, and termination arrangements.
Related guides

Explore more topics

ISO/IEC 27017 Audit Rights FAQ
ISO/IEC 27017 does not grant unrestricted cloud-provider audits. Define the contract route for independent assurance, supporting access, exceptions, and escalation.
ISO/IEC 27017 Certification Reality Guide
ISO/IEC 27017 is cloud control guidance, not a standalone management-system certification standard. Learn how to check the actual ISO/IEC 27001 claim and scope.
ISO/IEC 27017 Cloud Admin Access FAQ
Apply ISO/IEC 27017 to customer and provider cloud administrators: strong authentication, limited privileges, logged operations, supervised critical work, and review evidence.
ISO/IEC 27017 Cloud Security FAQ
Answers to ISO/IEC 27017:2015 cloud-security questions on shared roles, agreements, administration, logging, assurance, virtualization, and customer controls.
ISO/IEC 27017 Cloud Service Agreements FAQ
Use ISO/IEC 27017 to define cloud security roles, provider measures, evidence, incident handling, supplier dependencies, and exit terms in the service agreement.
ISO/IEC 27017 Compliance Guide
How cloud providers and customers apply ISO/IEC 27017:2015 through scoped risks, allocated responsibilities, agreements, controls, evidence, and review.
ISO/IEC 27017 Control Mapping to ISO/IEC 27001 Guide
Map ISO/IEC 27017:2015 cloud guidance and CLD controls into an ISO/IEC 27001:2022 ISMS with edition-aware rationale, owners, evidence, and SoA treatment.
ISO/IEC 27017 CSP vs CSC Role Split Comparison
Compare ISO/IEC 27017 responsibilities for cloud service providers and customers, with service-model examples, evidence, and review triggers.
ISO/IEC 27017 Customer Controls FAQ
Identify the cloud controls the customer should assess, configure, operate, monitor, evidence, and review when provider controls do not meet every security requirement.
ISO/IEC 27017 Hyperscaler Evidence Pack
What an ISO/IEC 27017:2015 hyperscaler evidence pack should contain, how to test coverage, and where provider assurance must be joined to customer evidence.
ISO/IEC 27017 Hyperscaler Evidence Pack Workflow
A service-specific workflow for testing hyperscaler claims, collecting provider and customer evidence, resolving gaps, and approving cloud risk under ISO/IEC 27017:2015.
ISO/IEC 27017 Logging FAQ
Allocate cloud event logging and monitoring between provider and customer, verify accessible events, privileged operations, timestamps, retention, alerts, and evidence.
ISO/IEC 27017 Provider Evidence FAQ
Check whether a cloud provider's certificate, audit report, or self-assessment supports its claims for the entity, service, location, controls, and period in scope.
ISO/IEC 27017 Shared Responsibility FAQ
Allocate ISO/IEC 27017 cloud-security roles to named provider, customer, and upstream parties for one service, then document, communicate, implement, and review the split.
ISO/IEC 27017 Shared Responsibility Model Guide
How to allocate provider, customer, and shared cloud security activities under ISO/IEC 27017:2015, document hand-offs, and test the allocation against evidence.
ISO/IEC 27017 Virtualization Responsibilities FAQ
Allocate tenant isolation, virtual-machine hardening, administrative operations, images, snapshots, and virtual-network policy under ISO/IEC 27017.
ISO/IEC 27017 vs CSA CCM Comparison
Compare ISO/IEC 27017:2015 with CSA CCM v4.1 by scope, control structure, responsibility mapping, assurance use, and evidence.
ISO/IEC 27017 vs ISO/IEC 27018 Comparison
Compare ISO/IEC 27017:2015 cloud security guidance with ISO/IEC 27018:2025 public-cloud PII processor guidance by scope, role, controls, and evidence.
ISO/IEC 27017 vs SOC 2 Comparison
Compare ISO/IEC 27017 cloud control guidance with SOC 2 attestation reports by purpose, scope, criteria, period, evidence, and customer responsibilities.