ISO 27017 Readiness Checklist & Evidence Pack for Cloud Audits

Checklist Overview

This readiness checklist is designed to help organizations preparing for an ISO 27001 certification audit that includes ISO 27017 cloud security controls. The checklist is structured in three tiers:

1. Foundation: ISMS-level readiness items that must be in place for ISO 27017 to be properly integrated
2. CLD Controls: Specific readiness items for each of the 7 additional cloud controls
3. Extended Controls: Readiness items for key ISO 27002 controls with cloud-specific guidance from ISO 27017

For each checklist item, we indicate whether it is primarily relevant to cloud service providers (CSP), cloud service customers (CSC), or both. Use this to filter the checklist based on your organization's role.

Foundation Checklist

Before addressing individual ISO 27017 controls, confirm these foundational elements are in place:

ISMS Scope and Context

• [CSP & CSC] ISMS scope explicitly includes cloud services (provided and/or consumed)
• [CSP & CSC] Cloud service inventory documented — all cloud services listed with provider, service model (IaaS/PaaS/SaaS), and data classification
• [CSP & CSC] Interested parties analysis includes cloud-specific stakeholders (cloud customers, cloud providers, cloud regulators)
• [CSP] Cloud service offerings documented with security characteristics
• [CSC] Cloud provider assessment criteria defined and applied to all providers

Risk Assessment

• [CSP & CSC] Risk assessment methodology extended to include cloud-specific threat scenarios
• [CSP & CSC] Cloud-specific risks identified: multi-tenancy, data residency, provider lock-in, API exposure, shared infrastructure vulnerabilities
• [CSP & CSC] Risk treatment plan includes ISO 27017 controls as treatment measures
• [CSP] Risks related to providing cloud services assessed (customer data protection, service availability, multi-tenant security)
• [CSC] Risks related to consuming cloud services assessed (vendor dependency, data sovereignty, control visibility)

Statement of Applicability

• [CSP & CSC] SoA includes all 7 CLD controls with applicability justification
• [CSP & CSC] SoA identifies which controls apply to CSP role, CSC role, or both
• [CSP & CSC] SoA includes implementation descriptions for each ISO 27017 control
• [CSP & CSC] SoA version is current and approved by management

Policies and Procedures

• [CSP & CSC] Cloud security policy exists (standalone or integrated into information security policy)
• [CSP & CSC] Cloud-specific procedures documented for operational activities
• [CSP & CSC] Policies reviewed and updated to reflect cloud environments

CLD Controls Readiness Checklist

CLD.6.3.1 — Shared Roles and Responsibilities

• [CSP] Shared responsibility matrix published for each cloud service offering
• [CSP] Customer-facing security documentation available and current
• [CSC] Internal responsibility matrix created for each cloud service consumed
• [CSC] Responsibilities validated against service agreements and provider documentation
• [CSP & CSC] Responsibility allocation covers all security control domains (not just ISO 27017 CLD controls)
• [CSP & CSC] Responsibility documentation reviewed within the last 12 months or when services changed
• [CSP & CSC] Key stakeholders acknowledge and understand their assigned responsibilities

CLD.8.1.5 — Removal of Cloud Service Customer Assets

• [CSP] Data return procedure documented with supported export formats
• [CSP] Secure data deletion procedure covers primary storage, backups, replicas, caches, and logs
• [CSP] Deletion timeline defined and communicated to customers
• [CSP] Certificate of destruction process available
• [CSC] Exit strategy documented for each cloud service
• [CSC] Data portability requirements included in service procurement criteria
• [CSC] Provider's data return and deletion capabilities assessed before contract signing

CLD.9.5.1 — Segregation in Virtual Computing Environments

• [CSP] Tenant isolation architecture documented
• [CSP] Compute, network, and storage segregation controls implemented and documented
• [CSP] Segregation controls tested via penetration testing (cross-tenant testing specifically)
• [CSP] Segregation architecture reviewed when platform changes occur
• [CSC] Provider's segregation approach evaluated and documented
• [CSC] Additional customer-side segregation implemented where needed (VPC segmentation, security groups)

CLD.9.5.2 — Virtual Machine Hardening

• [CSP] Hardened base VM images (golden images) maintained and versioned
• [CSP] VM hardening guidelines published for customers
• [CSP] Provider infrastructure VMs hardened according to standards
• [CSC] VM hardening baselines defined (CIS Benchmarks or equivalent)
• [CSC] Hardening applied to all provisioned VMs and verified via compliance scanning
• [CSC] Patch management process covers cloud-hosted VMs
• [CSP & CSC] Configuration drift detection implemented

CLD.12.1.5 — Administrator's Operational Security

• [CSP] Administrative procedures documented for critical cloud operations
• [CSP] Privileged access management (PAM) implemented with MFA
• [CSP] Audit logging enabled for all administrative actions
• [CSP] Administrative access reviews conducted regularly (at least quarterly)
• [CSP] Break-glass procedures documented and tested
• [CSP] Segregation of duties enforced for critical operations
• [CSC] Cloud console/API access managed with least privilege principles
• [CSC] MFA enforced for all cloud administrative accounts
• [CSC] Administrative access reviewed regularly

CLD.12.4.5 — Monitoring of Cloud Services

• [CSP] Monitoring capabilities documented for customers
• [CSP] Service health dashboards available
• [CSP] Security event log access provided to customers
• [CSP] Monitoring APIs or integrations available
• [CSC] Monitoring requirements defined based on risk assessment
• [CSC] Cloud monitoring integrated with enterprise SIEM
• [CSC] Alerting thresholds configured for cloud-specific events
• [CSC] Monitoring coverage reviewed regularly for completeness

CLD.13.1.4 — Virtual and Physical Network Alignment

• [CSP] Network security policies cover both virtual and physical environments
• [CSP] Change management applies to virtual network configurations
• [CSP] Virtual network components included in vulnerability assessments
• [CSC] Security groups and NACLs configured per organizational policy
• [CSC] Virtual network architecture documented
• [CSC] Virtual network security reviewed as part of cloud security assessments

Extended Controls Readiness Checklist

Key ISO 27002 controls with significant cloud-specific extensions in ISO 27017:

Access Control (A.9)

• [CSP & CSC] Cloud identity and access management policy defined
• [CSP] Identity federation capabilities offered (SSO, SAML, OIDC)
• [CSC] Cloud identity integrated with enterprise IAM
• [CSC] Cloud access reviews conducted regularly (at least quarterly)
• [CSC] Service account and API key management procedures in place

Cryptography (A.10)

• [CSP] Encryption capabilities documented (at rest, in transit, key management options)
• [CSP] Customer-managed key (BYOK/HYOK) options available where required
• [CSC] Encryption requirements defined for cloud-stored data
• [CSC] Key management responsibilities clarified and implemented

Operations Security (A.12)

• [CSP & CSC] Change management process covers cloud environment changes
• [CSP & CSC] Capacity management includes cloud resource monitoring
• [CSC] Logging from cloud environments collected and retained per policy

Supplier Relationships (A.15)

• [CSC] Cloud provider due diligence conducted and documented
• [CSC] Service agreements reviewed for security obligations
• [CSC] Provider's sub-processor and supply chain dependencies assessed
• [CSP] Sub-processor security requirements defined and enforced

Incident Management (A.16)

• [CSP] Cloud incident notification procedures defined with timelines
• [CSP] Forensic capabilities available for customer incidents
• [CSC] Cloud incident response integrated with enterprise incident management
• [CSC] Provider's incident notification commitments understood and verified

Evidence Matrix: CLD Controls

The following matrix maps each CLD control to the types of evidence auditors typically request:

Compiling the Evidence Pack

A well-organized evidence pack significantly streamlines the audit process and demonstrates maturity. Here is how to compile one effectively:

Step 1: Create a Master Evidence Index

Build a spreadsheet or document that lists:

• Control reference (CLD.6.3.1, CLD.8.1.5, etc. plus applicable extended controls)
• Evidence title
• Evidence type (policy, procedure, configuration, log, report, record)
• File location or reference
• Date of evidence
• Owner/responsible person

This index becomes the auditor's navigation tool during the assessment.

Step 2: Organize by Control Reference

Create a folder structure organized by control:

• CLD.6.3.1/ — Responsibility matrices, RACI charts, contractual excerpts, review records
• CLD.8.1.5/ — Data return/deletion policies, exit procedures, deletion certificates
• CLD.9.5.1/ — Architecture docs, pen test reports, segregation configs
• CLD.9.5.2/ — Hardening standards, compliance scans, patch records
• CLD.12.1.5/ — PAM configs, access reviews, admin audit logs
• CLD.12.4.5/ — Monitoring configs, alert records, SIEM integration evidence
• CLD.13.1.4/ — Network configs, change records, assessment reports
• Extended/ — Sub-folders for A.9, A.10, A.12, A.15, A.16 cloud extensions

Step 3: Include Both Current and Historical Evidence

Auditors want to see that controls are consistently operational, not just configured at the point of audit. Include:

• Current configuration states and policy versions
• Historical records showing ongoing operation (e.g., monthly access review records, quarterly monitoring reports)
• Records of changes and improvements over time

Step 4: Redact Sensitive Information Appropriately

When preparing evidence, redact information that should not be shared with auditors (e.g., actual passwords, customer personal data) while retaining enough context to demonstrate control operation. Mark redacted items clearly so auditors can request additional detail if needed.

Step 5: Include CSP Evidence Where Applicable

For controls where the CSP is responsible, include:

• CSP's ISO 27001 certificate (showing cloud scope)
• CSP's SOC 2 Type II report (if available)
• CSP's published shared responsibility documentation
• CSP's security whitepapers or compliance documentation
• Records of your due diligence review of CSP evidence

Common Gaps and How to Fix Them

Based on our audit experience, these are the most frequently identified gaps during ISO 27017 readiness assessments:

Gap 1: Generic Shared Responsibility Documentation

What we see: Organizations use the cloud provider's generic shared responsibility model without tailoring it to their specific services, configuration, and contractual terms.

How to fix: Create service-specific responsibility matrices that map to your actual services, reflect your configuration choices, and align with contractual obligations. The provider's generic model is a starting point, not the final document.

Gap 2: No Cloud-Specific Risk Assessment

What we see: The risk assessment covers general information security risks but does not include cloud-specific threat scenarios such as cross-tenant attacks, API abuse, data residency violations, or provider failure.

How to fix: Extend the risk assessment to include a cloud threat catalog. Use ISO 27017 controls as a starting point to identify cloud risks that each control is designed to mitigate.

Gap 3: VM Hardening Standards Not Defined

What we see: VMs are deployed without a defined hardening baseline, or hardening is performed ad-hoc without compliance verification.

How to fix: Adopt CIS Benchmarks or equivalent as your hardening baseline. Implement golden images with pre-applied hardening. Deploy compliance scanning tools to detect drift.

Gap 4: Administrative Access Not Monitored

What we see: Cloud console and API access is configured but administrative actions are not logged, or logs exist but are not reviewed.

How to fix: Enable cloud trail/audit logging for all administrative actions. Integrate with SIEM. Establish review procedures for administrative activity alerts. Implement regular access recertification.

Gap 5: Cloud Controls Missing from Internal Audit

What we see: The internal audit program covers standard Annex A controls but does not include ISO 27017 cloud controls in its scope.

How to fix: Update the internal audit program to include all CLD controls and relevant extended controls. Ensure internal auditors have cloud security competence or engage specialists for cloud control auditing.

Gap 6: No Evidence of Segregation Testing

What we see: Segregation architecture is documented but has never been tested, or testing does not specifically cover cross-tenant access scenarios.

How to fix: Include cross-tenant access testing in penetration testing scope. Document testing methodology, results, and remediation actions. Retest after significant platform changes.

Gap 7: Insufficient Monitoring Coverage

What we see: Basic infrastructure monitoring is in place but security-specific monitoring for cloud environments is missing or incomplete.

How to fix: Define monitoring requirements by control area. Implement security-focused monitoring including unauthorized access attempts, configuration changes, privilege escalation, and data exfiltration indicators. Document monitoring coverage and review it regularly.

Tips for Presenting Evidence to Auditors

1. Provide Context with Every Evidence Item

Don't just hand over a screenshot or log extract. Include a brief description of what the evidence shows, which control it relates to, and why it demonstrates control effectiveness.

2. Demonstrate the Lifecycle

Auditors value evidence that shows the complete lifecycle: planning, implementation, operation, review, and improvement. Show that controls are not static but part of a living management system.

3. Prepare for Demonstrations

Auditors may ask for live demonstrations of cloud controls — monitoring dashboards, access review processes, administrative procedures. Have the right people available with appropriate access to demonstrate controls in real-time.

4. Anticipate Cross-References

Auditors will cross-reference your evidence. For example, risks identified in the risk assessment should map to controls in the SoA, which should map to evidence in the evidence pack, which should be verified by internal audit findings. Ensure these chains are consistent.

5. Be Transparent About Gaps

If you have identified gaps and are actively addressing them, be transparent. Auditors appreciate honesty and evidence of corrective action plans more than perfect but implausible documentation. An open corrective action is better than a hidden gap.

Frequently Asked Questions

What evidence do I need for ISO 27017 cloud controls?

For each CLD control, you need policy documentation, implementation evidence (configurations, screenshots, reports), operational records (logs, review minutes, access reviews), and records of monitoring and improvement. The evidence must demonstrate both the design of the control and its operational effectiveness over time.

How do I compile an ISO 27017 evidence pack?

Organize evidence by control reference (CLD.6.3.1 through CLD.13.1.4 and extended controls). For each control, include the policy, procedure, implementation evidence, operational records, and review records. Create a master index that maps each control to its evidence files for easy auditor navigation.

What are common gaps found during ISO 27017 readiness assessments?

Common gaps include: missing or generic shared responsibility documentation, no cloud-specific risk assessment, VM hardening standards not defined, insufficient monitoring of cloud administrative activities, no evidence of cross-tenant segregation testing, and cloud controls not covered in the internal audit program.

How long should I collect evidence before an ISO 27017 audit?

Aim for at least 2-3 months of operational evidence before the audit. This allows time for access reviews to be conducted, monitoring data to accumulate, administrative audit logs to be generated, and at least one cycle of internal review to complete. More evidence is better.

Can I use CSP-provided evidence for my ISO 27017 audit?

Yes, for controls where the CSP is responsible. Commonly used CSP evidence includes SOC 2 reports, ISO 27001 certificates, penetration test summaries, and shared responsibility documentation. However, you must also demonstrate your own controls for all customer-side responsibilities and show that you have evaluated the CSP evidence as part of your due diligence.