ISO 27017 Checklist

Use this ISO 27017 Audit Checklist to assess cloud security controls compliance, all 7 CLD controls, for ISO 27017 certification within your ISMS.

Download as free PDF

Library
ISO Standards
ISO 27017 Checklist

ISO 27017 Checklist

CLD.6.3.1 — Shared Roles And Responsibilities In Cloud Environments

CLD.8.1.5 — Removal And Return Of Cloud Service Customer Assets

CLD.9.5.1 — Segregation In Virtual Computing Environments

CLD.9.5.2 — Virtual Machine Hardening

CLD.12.1.5 — Administrator's Operational Security

CLD.12.4.5 — Monitoring Of Cloud Services

CLD.13.1.4 — Alignment Of Security Management For Virtual And Physical Networks

Extended Cloud Controls — Key ISO 27002 Controls With Cloud-Specific Guidance

2. Cloud asset classification: Data stored in or processed by cloud services is classified in accordance with the organization's information classification policy, and cloud storage and processing controls are applied commensurate with the classification level.

Photo Comment

3. Cloud access control policy: Access control policies are applied to cloud services based on the principle of least privilege, with role-based access control (RBAC) or attribute-based access control (ABAC) configured for each cloud service in scope.

Photo Comment

9. Cloud supplier management: Cloud service providers are assessed before adoption and at defined intervals, including review of their security certifications (such as ISO 27001, SOC 2, or CSA STAR), audit rights, and incident notification obligations.

Photo Comment

11. Cloud compliance: Compliance requirements applicable to data stored or processed in cloud environments — including data residency, privacy regulations, and sector-specific obligations — are identified, documented, and verified against the CSP's capabilities and contractual commitments.

Photo Comment

Checklist by GoAudits.com – Please note that this checklist is intended as an example. We do not guarantee compliance with the laws applicable to your territory or industry. You should seek professional advice to determine how this checklist should be adapted to your workplace or jurisdiction.

Is this sample what you are looking for?
Sign up to use & customize this template, or create your own custom checklist.

NEW! Try generating a custom checklist with our free AI tool:

Easy inspection app for your digital checklists

Conduct inspections anytime, anywhere - even offline
Capture photos as proof of compliance or areas needing attention
Instantly generate and share detailed reports after the inspections
Assign & track follow-up tasks, view historical trends on a centralized dashboard

ISO 27017 Checklist

Use this ISO 27017 Audit Checklist to assess cloud security controls compliance, all 7 CLD controls, for ISO 27017 certification within your ISMS.

1. A shared responsibility model is documented for each cloud service in scope, clearly defining which security controls are the responsibility of the cloud service provider (CSP) and which are the responsibility of the cloud service customer (CSC).

2. The shared responsibility model is documented at the service model level (IaaS, PaaS, or SaaS) and reflects the actual division of control for the specific service in use.

3. The responsibility matrix covers all relevant security domains, including patching, encryption, access control, logging, incident response, and vulnerability management — not only the seven CLD controls.

4. The shared responsibility documentation is formally agreed with the CSP and is referenced in or attached to the service agreement or contract.

5. The shared responsibility model is reviewed and updated whenever the service scope changes, the service model changes, or the CSP updates its responsibility documentation.

6. All relevant internal personnel — including security, operations, and development teams — are aware of their responsibilities under the shared responsibility model.

7. Where the organization acts as both a CSP and a CSC (for example, providing a SaaS application hosted on IaaS), shared responsibilities are documented from both perspectives.

8. Evidence is available that the shared responsibility model has been reviewed as part of the ISO 27001 internal audit cycle.

1. A documented procedure is in place for the secure removal and return of cloud service customer assets at the termination or expiry of a cloud service agreement.

2. The procedure defines the scope of assets to be returned or deleted, including data, configurations, cryptographic keys, and access credentials stored within or generated by the cloud service.

3. The timeframe for asset removal or return is defined in the cloud service agreement and the procedure reflects this obligation.

4. The procedure specifies verification steps to confirm that all customer data has been deleted from the CSP's systems, including from backups, replicas, and caches, upon termination.

5. Where the organization is a CSP, a process exists to return or securely delete customer assets on request or upon contract termination, with confirmation provided to the customer.

6. Where the organization is a CSC, a procedure exists to retrieve all organizationally owned data and configurations from the cloud environment before terminating a service.

7. Records of asset removal or return events are retained, including confirmation of deletion or return and the identity of the responsible party.

8. The asset removal procedure is tested or reviewed at defined intervals to confirm it remains operable and aligned with current cloud service arrangements.

1. Controls are in place to ensure that each cloud service customer's virtual environment is logically segregated from those of other customers, preventing unauthorized cross-tenant access to data, configurations, or resources.

2. The segregation architecture is documented, specifying the technical mechanisms used to achieve isolation (such as virtual networks, containerization, tenant-specific encryption keys, or identity boundary controls).

3. Segregation controls are tested at defined intervals, including as part of penetration testing scope, to verify that cross-tenant access is not possible under normal or adversarial conditions.

4. Penetration test results covering cross-tenant segregation are retained and any findings are tracked to remediation.

5. Where the organization is a CSC, evidence is obtained from the CSP (such as audit reports, certifications, or penetration test summaries) that multi-tenant segregation controls are in place and effective.

6. Changes to virtualization architecture, containerization platforms, or network topology are subject to a change control process that includes a segregation impact assessment before implementation.

7. Segregation controls are included in the ISMS risk assessment and their effectiveness is reviewed as part of the management review or internal audit cycle.

1. A virtual machine (VM) hardening standard or baseline configuration is documented, defining the security configuration requirements for all VM images used within cloud environments in scope.

2. The hardening standard addresses unnecessary services and ports (disabled or removed), default credentials (changed or removed), OS and software patching, host-based firewall rules, and logging and monitoring agent installation.

3. VM images are built from approved, hardened base images and are not deployed from unverified or unapproved sources.

4. A process is in place to review and update the VM hardening standard at defined intervals and following the release of significant vulnerabilities or patches affecting the underlying OS or platform.

5. Hardened VM images are stored securely in an approved image repository with access controls restricting who can create, modify, or publish images.

6. Configuration compliance scanning or equivalent tooling is used to verify that deployed VMs conform to the hardening standard, with results reviewed at defined intervals.

7. Deviations from the hardening baseline are recorded, risk-assessed, and subject to a formal exception or remediation process.

8. Container images and serverless function configurations are included in the hardening scope where these are deployed as equivalents to traditional VMs.

9. Evidence of VM hardening compliance is available and has been reviewed as part of the ISO 27001 internal audit.

1. Administrative access to cloud infrastructure, management consoles, and cloud-native control planes is restricted to authorized personnel with a documented business need.

2. Privileged access accounts for cloud administration are separate from standard user accounts and are not used for routine, non-administrative tasks.

3. Multi-factor authentication (MFA) is enforced for all cloud administrative accounts without exception.

4. Administrative activities performed in cloud environments are logged, with logs retained for a defined period and protected against tampering or unauthorized deletion.

5. Administrative access logs are reviewed at defined intervals for anomalous or unauthorized activity.

6. Just-in-time (JIT) or time-limited privileged access is implemented for cloud administrative roles where technically feasible, minimizing the standing exposure of privileged credentials.

7. Cloud administrator accounts and their access entitlements are reviewed at defined intervals, and access is revoked promptly when an administrator changes role or leaves the organization.

8. Procedures are in place for the emergency creation and revocation of cloud administrative access, including during security incidents.

9. Third-party or outsourced cloud administrators are subject to the same access controls, logging, and review requirements as internal administrators.

1. A cloud monitoring strategy is documented, defining what security events, metrics, and logs are captured from cloud environments, and by whom.

2. Logging is enabled for all cloud services in scope, including management plane activity (API calls, configuration changes, administrative actions), data plane activity (access to data and storage), and identity and access events.

3. Cloud-native logging services (such as AWS CloudTrail, Azure Monitor, or Google Cloud Audit Logs) are enabled and configured to capture the event types required by the monitoring strategy.

4. Logs are forwarded to a centralized, tamper-protected log management or SIEM system outside the cloud environment being monitored, ensuring logs cannot be deleted by a compromised cloud account.

5. Log retention periods are defined and enforced, meeting both the organization's security incident investigation requirements and any applicable regulatory obligations.

6. Alerts are configured for high-priority security events including unauthorized API calls, privilege escalation, configuration changes to security controls, and access to sensitive data stores.

7. Cloud security monitoring results are reviewed at defined intervals by personnel with appropriate cloud security competence.

8. Cloud monitoring coverage is reviewed as part of the ISO 27001 internal audit, including verification that all in-scope services are captured and that alert thresholds remain appropriate.

9. Monitoring arrangements are reviewed and updated when new cloud services are adopted, existing services change, or the threat environment shifts significantly.

1. Security controls applied to virtual networks within cloud environments are documented and are equivalent in coverage to those applied to equivalent physical network segments.

2. Network segmentation and access control policies are applied to cloud virtual networks (such as VPCs, VNets, or equivalent), with security groups, firewall rules, and routing controls configured to enforce the principle of least privilege.

3. A network security architecture document covers both physical and virtual network environments, demonstrating consistent security policy application across both.

4. Cloud virtual network configurations are subject to the same change management process as physical network changes, including security review before implementation.

5. Virtual network security configurations are audited at defined intervals using cloud-native configuration assessment tools or third-party tooling to detect deviations from policy.

6. Cloud network traffic is monitored for anomalous patterns, unauthorized connections, and data exfiltration indicators using cloud-native or third-party network detection capabilities.

7. Encrypted connections are enforced for all traffic between cloud virtual networks and on-premises environments (such as VPN or dedicated interconnect), and encryption in transit is enforced within cloud virtual networks for sensitive data flows.

8. Virtual network security controls are included in penetration testing scope at defined intervals, with results retained and findings tracked to remediation.

1. Cloud service inventory: All cloud services in use across the organization are identified and recorded in the asset register, including shadow IT discovery processes to identify unsanctioned cloud service adoption.

2. Cloud asset classification: Data stored in or processed by cloud services is classified in accordance with the organization's information classification policy, and cloud storage and processing controls are applied commensurate with the classification level.

3. Cloud access control policy: Access control policies are applied to cloud services based on the principle of least privilege, with role-based access control (RBAC) or attribute-based access control (ABAC) configured for each cloud service in scope.

4. Identity and access management: Cloud identity management includes a formal provisioning and deprovisioning process for cloud service accounts, with access rights reviewed at defined intervals and revoked promptly on role change or departure.

5. Encryption in cloud environments: Encryption is applied to data at rest in cloud storage services, with encryption key management documented, including whether keys are managed by the CSP, the CSC, or a third-party key management service.

6. Encryption key ownership: Where the organization manages its own encryption keys (customer-managed keys), key lifecycle procedures are documented covering generation, storage, rotation, and destruction.

7. Cloud vulnerability management: Vulnerability scanning is applied to cloud workloads, container images, and infrastructure-as-code templates, with findings prioritized, tracked, and remediated within defined timeframes.

8. Cloud incident response: The organization's incident response plan explicitly covers cloud-specific scenarios, including cloud account compromise, unauthorized configuration changes, and data exposure via misconfigured cloud storage.

9. Cloud supplier management: Cloud service providers are assessed before adoption and at defined intervals, including review of their security certifications (such as ISO 27001, SOC 2, or CSA STAR), audit rights, and incident notification obligations.

10. Cloud business continuity: Business continuity and disaster recovery plans address cloud service dependencies, including the impact of CSP outages, data recovery from cloud backups, and failover to alternative cloud regions or providers.

11. Cloud compliance: Compliance requirements applicable to data stored or processed in cloud environments — including data residency, privacy regulations, and sector-specific obligations — are identified, documented, and verified against the CSP's capabilities and contractual commitments.