Use the pack to show whether one defined cloud service and workload is covered by provider commitments and customer-operated controls.
This is an organization-designed evidence set, not an official ISO form. Apply it with the cloud agreement, the organization's risk assessment, applicable law, and its selected ISO/IEC 27001 controls.
Structured answer sets in this page tree.
Cited legal and guidance references.
A useful supports the organization's decision to use a defined service, in named accounts and regions, for specified workloads and data. It should identify what the provider operates, what the customer must operate, what remains uncertain, and who accepted or rejected the resulting risk. Provider badges identify assurance claims but do not establish this service-specific coverage.
The pack supports a customer-side selection, renewal, assurance, or risk-treatment decision for a defined cloud use. Its header should name the provider legal entity, service and features, service model, accounts or tenants, regions, workloads, data classes, upstream dependencies, agreement version, business owner, and assessment period.
ISO/IEC 27017:2015 provides cloud-specific controls and implementation guidance for cloud service customers and providers. The pack is a practical way to retain the records behind an organization's application of that guidance; ISO/IEC 27017 does not prescribe a document called a .
This page uses the 2015 edition. ISO still lists it as the published first edition and marks it for revision. ITU-T now lists X.1631 (12/25) as in force and the joint 2015 ITU text as superseded, but the revised ISO edition has not yet been published.
Keep the scope, responsibility matrix, provider evidence, customer records, exceptions, approval, and review triggers together.
Assign evidence requests and customer control checks against the exact service and responsibility boundary.
Review your current scope, evidence gaps, and next implementation steps.
Organize the pack around claims, not file types. Each entry should state the control activity or provider claim, responsible party, applicable service scope, source record, covered period, review result, exception, follow-up owner, and decision effect. This makes a missing hand-off visible even when both parties have supplied documents.
The responsibility matrix and cloud service agreement are the index. ISO/IEC 27017 says both parties' information security roles should be stated in an agreement. The agreement can cover access control, malware protection, vulnerability management, incident management, continuity, audit, evidence such as logs and audit trails, termination protection, and identity and access management. For a shared line, record each action separately: for example, the provider supplies infrastructure event logs while the customer enables, retains, and reviews workload logs.
Include the provider chain. A provider may itself use another cloud provider, so the pack should show which upstream dependency supports each downstream commitment and whether the available evidence covers that dependency.
Match every provider document to the frozen scope. Record the issuing or audited entity, service and locations, covered period, control framework, exclusions, subservice organizations, qualifications or opinion, exceptions, complementary customer controls, and any gap between the report period and the decision date. Ask for clarification or additional evidence when those fields do not support the claim being made.
ISO/IEC 27017 says a customer should request documented evidence that provider control implementation matches the provider's claims. Relevant certifications can contribute. When individual customer audits are impractical or could increase information security risk, the provider should make independent evidence available with enough transparency. If an independent audit is impractical, the standard says the provider should perform a self-assessment and disclose its process and results.
A report can support provider operation during its covered period, but it cannot show that the customer enabled a security feature, reviewed access, responded to alerts, tested recovery, or met a legal obligation outside the report's scope.
For every customer-owned or shared activity, link evidence from normal operations. Examples include identity inventories, privileged-access reviews, configuration policy and current state, approved changes, vulnerability findings and treatment, event and alert records, backup status and recovery tests, incident tickets or exercises, data-location decisions, and termination tests. Select records that fit the actual service model; a SaaS customer and an IaaS customer will not operate the same technical layers.
Cloud monitoring is a specific hand-off. ISO/IEC 27017 says the customer should request information about the monitoring capabilities available for each service, while the provider should give the customer access to relevant monitoring for its own instances and document that capability. The pack should show both provider availability and the customer's use of the capability where the risk treatment relies on it.
Critical customer administrative operations also need procedures and monitoring. The standard names installation, change and deletion of virtualized devices, termination, backup, and restoration as examples where failure can cause unrecoverable damage. Include procedure approval and execution evidence when those operations fall within the customer's boundary.
The pack is ready when each in-scope activity has an allocated owner, a supported provider or customer claim, an evidence result, and an exception status. The decision-maker should be able to see which controls are complete, which require action, which are not applicable and why, and which gaps require rejection or authorized risk acceptance.
Check incident and exit terms before approval. Incident records should cover responsibility allocation, reportable incident scope, disclosure level, notification target time, reporting and tracking routes, contacts, and stated remedies. Exit evidence should identify customer assets, the return or export and removal arrangements, the schedule, deletion of copies, and the parties responsible.
Set a calendar review and event triggers. Reassess affected claims after changes to the provider, service, feature, service model, region, account boundary, workload, data use, architecture, agreement, provider chain, assurance report, incident process, or applicable requirement. Do not reuse an old conclusion merely because the files are still available.