ISO 27017
cloud security controls and audit guide
ISO/IEC 27017:2015 is the cloud-specific extension to ISO 27002. It restates the ISO 27002 controls with cloud-specific implementation guidance and adds seven controls that only exist when an information service is delivered through a cloud relationship. This page covers the structure, the customer and provider responsibility split, and how a workspace records the evidence ISO 27017 expects.
No credit card required. Free plan available forever.
ISO 27017 in context: the cloud-specific extension to ISO 27002
ISO/IEC 27017:2015 is the international standard for information security controls in cloud services. It does two things at once: it restates the ISO 27002 controls with cloud-specific implementation guidance, and it adds seven CLD-prefixed controls that only exist where the relationship between a cloud service customer and a cloud service provider exists. ISO 27017 is informative on top of ISO 27002 rather than normative on its own; certification runs against ISO 27001, with ISO 27017 informing how the cloud-specific obligations are implemented and evidenced.
The relationship most teams need to keep clear is the layering across the ISO 27001 family. The ISO 27001 framework page covers the management system standard that certifies the ISMS. The ISO 27002 framework page covers the implementation guidance for the 93 ISO 27001 Annex A controls. ISO 27017 sits on top of those: it adds cloud-specific guidance to the existing controls and adds seven controls that the non-cloud catalogue does not need. The Statement of Applicability still cites ISO 27001 Annex A; the cloud-specific implementation guidance and the CLD controls reference ISO 27017 explicitly so the auditor can trace the cloud obligation back to the right standard text.
Where ISO 27017 sits among the ISO 27001 family extensions
ISO 27017 is one of three commonly referenced extensions to the ISO 27002 control catalogue. Each extension addresses a different surface and adds controls or guidance that ISO 27002 alone does not cover. Most cloud-aware organisations need at least ISO 27017, with ISO 27018 and ISO 27701 layered on where personal data and privacy programmes intersect.
ISO 27017 (cloud services)
Adds cloud-specific implementation guidance to the ISO 27002 controls and introduces seven additional CLD controls that only exist when information is processed in a cloud service relationship. ISO 27017 is the most directly applicable extension for any organisation using or delivering Software as a Service, Platform as a Service, or Infrastructure as a Service.
ISO 27018 (PII in public clouds)
Layered on top of ISO 27017 for cloud services that process personally identifiable information. ISO 27018 inherits the ISO 27017 cloud controls and adds privacy-specific obligations for public cloud processors handling PII on behalf of customers.
ISO 27701 (privacy information management)
A privacy management system standard that extends ISO 27001 and ISO 27002 with privacy-specific controls. ISO 27701 is the certifiable privacy companion when an ISMS already has ISO 27001 in place; it sits alongside ISO 27017 rather than replacing it for cloud-specific obligations.
The seven CLD controls in ISO 27017
ISO 27017 introduces seven cloud-specific controls that sit alongside the ISO 27002 controls. These are the obligations that only exist when an organisation consumes or provides a cloud service; they have no equivalent in a self-hosted environment. The identifiers carry a CLD prefix so the audit trail can distinguish ISO 27017-only obligations from the ISO 27002 controls that ISO 27017 supplements.
CLD.6.3.1 Shared roles and responsibilities
A documented allocation of information security responsibilities between the cloud service customer and the cloud service provider, recorded per service and per control. The shared responsibility model becomes a formal artefact of the ISMS rather than a marketing diagram.
CLD.8.1.5 Removal of cloud service customer assets
Customer data and configuration are returned or destroyed at the end of the cloud service contract, with verification that no copies remain in provider-controlled storage, backups, or replicated regions. The control closes the data lifecycle at the provider boundary.
CLD.9.5.1 Segregation in virtual computing environments
Cloud service customers in a shared virtual computing environment are isolated from each other and from provider-internal workloads. The obligation covers the network, storage, compute, and identity planes; tenant isolation is a named control rather than an inherent property of the platform.
CLD.9.5.2 Virtual machine hardening
Virtual machine images and runtime instances are hardened against known threats, with explicit allocation of which hardening obligations sit with the customer (workload, application, in-guest controls) and which sit with the provider (hypervisor, base image, host).
CLD.12.1.5 Administrator operational security
Administrative actions in the cloud environment are documented, authorised, logged, and reviewable. The control raises the bar because a single administrative action in cloud can affect tenants beyond the actor; the change discipline must reflect that blast radius.
CLD.12.4.5 Monitoring of cloud services
The customer monitors the cloud service against its agreed service definition, with logs, metrics, and incident records that feed into the customer ISMS. Monitoring is the customer obligation that turns provider visibility into ISMS evidence rather than a passive contractual entitlement.
CLD.13.1.4 Alignment of security management for virtual and physical networks
Security management of virtual networks (VLANs, virtual switches, SDN, service meshes) is aligned with the controls applied to the equivalent physical networks. The control prevents the common failure mode where virtual networks inherit weaker access controls than the physical networks they replaced.
The CLD controls reach into territory that pentest and configuration review work touches directly. Tenant isolation, virtual machine hardening, and virtual network segmentation are evaluated by cloud security assessments that produce findings against the underlying obligations. Findings against misconfigured object storage often map to CLD.8.1.5 and several ISO 27002 controls at once; the cloud bucket misconfiguration guide covers the technical detection side of those findings. Finding-level evidence anchors the control evidence rather than substituting for it.
The shared responsibility model as an audit obligation
ISO 27017 turns the shared responsibility model from a marketing diagram into a documented obligation. CLD.6.3.1 requires a per-control, per-service allocation of responsibility between the cloud service customer and the cloud service provider. Without that documentation, neither side can demonstrate that its part of the obligation is being met, and the auditor cannot verify the boundary the organisation operates against.
- Responsibility allocation is recorded per control, per service, and per cloud delivery model. Software as a Service shifts more obligations to the provider than Infrastructure as a Service; the responsibility table in the ISMS documents that variance rather than treating the cloud as a single relationship.
- Provider responsibilities reference provider-supplied attestations (SOC 2 Type II reports, ISO 27001 certificates, ISO 27017 statements of applicability, region-specific compliance reports). The ISMS holds the attestation reference; the provider audit report holds the evidence behind the attestation.
- Customer responsibilities reference internal evidence the customer controls (configuration baselines, audit logs, identity provisioning records, vulnerability management output). Customer responsibilities cannot be discharged by citing the provider attestation; they require their own evidence chain.
- Shared responsibilities reference both sides of the boundary explicitly. A control like patch management on a managed database is shared: the provider patches the engine, the customer applies in-database security configurations, and the responsibility table lists both with the relevant artefacts.
- Boundary changes are tracked with a date and a rationale. Cloud providers move responsibilities back and forth across releases (managed identity replacing customer-managed, for example); the responsibility allocation has a version history rather than a single static snapshot.
Provider attestations carry a lot of weight in the cloud responsibility split, but they do not discharge the customer side of the boundary. SOC 2 Type II reports issued by the provider attest to provider obligations; the customer still owns its workload, its configuration, and its identity boundary. The SOC 2 framework page covers the trust services criteria that most provider attestations follow, and the GDPR framework page covers the privacy obligations that often layer on top of ISO 27017 when the cloud workload processes personal data.
Building the per-control evidence base for cloud
ISO 27017 audit findings most often centre on evidence rather than on control intent. The cloud control is named in the SoA, the responsibility allocation is documented, and the team can describe what each side does, but the artefact a certification body asks for is either missing, stale, or non-specific. The evidence model below is what survives stage 2 and surveillance review.
- Provider evidence sits in attestation references attached to the ISMS. The reference records which provider control framework the attestation covers (SOC 2, ISO 27001, ISO 27017, or a regional regime), the report period, and the link to the underlying report or its excerpt.
- Customer evidence sits in workspace records that walk back to the work itself: vulnerability assessment findings against cloud assets, configuration review output, identity and access management audit logs, scanner findings against cloud-hosted endpoints, and remediation records that close the loop.
- Shared evidence is tagged at both ends. A control that depends on the provider patching the engine and the customer hardening the configuration carries two evidence pointers; the audit can see both threads from the same control row.
- Cloud incidents that affect customer data are recorded against the relevant CLD control with the provider notification reference, the customer impact assessment, and the remediation chain that followed. The incident is the most load-bearing form of evidence for the monitoring control.
- Region-specific obligations (GDPR, HIPAA, regional sovereignty rules) inherit from ISO 27017 by adding region-specific controls to the per-control evidence base. The evidence chain still walks back to the same workspace; the control set adds rather than replaces.
For technical evidence specifically, cloud findings cluster against a small set of common misconfiguration patterns. The sensitive data exposure guide covers the data lifecycle failures CLD.8.1.5 addresses, the OAuth misconfiguration guide covers identity boundary failures common in cloud federation, and the broken access control guide covers authorisation failures that the tenant isolation control depends on.
How SecPortal aligns to ISO 27017 implementation work
SecPortal is the workspace that holds the engagement, the cloud assessment findings, and the audit trail that the per-control evidence chain references. The platform does not certify the ISMS and is not a substitute for the certification body audit, but it does hold the work the implementation team relies on when building and maintaining the cloud-specific evidence base.
- Compliance tracking with workspace-level templates that record per-control status, evidence pointers, and the customer/provider responsibility split each cloud control needs to capture.
- Findings management that links cloud penetration test, configuration review, and scanner output to the specific CLD or ISO 27002 control the finding evidences, so the audit trail walks from the cloud finding back to the obligation in the catalogue.
- Engagement management that records the work behind cloud assessments (the scope, the targets, the methodology, the testers, the timeline) so the assessor activity is itself a piece of ISO 27017 evidence rather than a separate file.
- AI report generation that produces the narrative compliance summary an internal audit committee or a certification body expects, with the underlying control register and evidence base kept available behind the narrative.
- Activity logs that record every status change, evidence upload, and assignment. The log is the audit trail surveillance and recertification ask for during cloud-specific control review.
- Continuous monitoring with scheduled scans against verified cloud-hosted endpoints, so the technological evidence behind monitoring controls stays current rather than ageing between audit cycles.
For the technological side of ISO 27017, the workspace is most directly load-bearing. Cloud assessment findings link to specific control identifiers, scanner output is preserved at import, and the activity trail records every status change without manual tracking. The scanner output deduplication guide covers how to preserve evidence quality when cloud scanner findings feed into control evidence, and the false positives guide covers the validation discipline that keeps the per-control evidence chain trustworthy.
The certification path for ISO 27017
ISO 27017 cannot be certified on its own. The certifiable obligation is ISO 27001; ISO 27017 informs the cloud-specific portion of the ISO 27001 audit. Certification bodies accredited under the ISO 17021 family scheme typically state ISO 27017 alongside ISO 27001 on the certificate when the cloud scope is in play, with the ISO 27017 reference signalling that the cloud-specific control guidance has been audited as part of the ISO 27001 examination.
- Stage 1 review checks the management system documentation: scope, ISMS policy, the Statement of Applicability that cites ISO 27001 Annex A controls, and the ISO 27017 references that show how cloud-specific obligations are addressed. The review is documentary; gaps surface before stage 2 reaches operations.
- Stage 2 audit examines the operational evidence: how each cloud-relevant control is implemented, what evidence supports the implementation, and whether the responsibility allocation between customer and provider is documented and current. The auditor walks the evidence chain per control rather than accepting policy alone.
- Surveillance audits in years one and two re-examine a sample of controls and any non-conformities raised at certification. Cloud controls usually feature in surveillance because the underlying services change faster than the ISMS does; the assessor checks that the responsibility allocation has been refreshed against operational reality.
- Recertification at year three repeats the full stage 1 and stage 2 cycle, with the cloud control set typically expanded if the organisation has moved to additional cloud services since initial certification.
Common implementation mistakes
The mistakes below recur across organisations bringing cloud workloads into an existing ISMS and across organisations that started cloud-native and added the ISMS later. Each is recoverable with a documented correction; each is hard to recover when discovered at the certification body audit.
- Treating ISO 27017 as a substitute for ISO 27001. ISO 27017 extends the ISO 27002 control catalogue with cloud-specific guidance; certification still runs against ISO 27001 with ISO 27017 informing the implementation. Statements of Applicability that cite ISO 27017 alone fail the audit review.
- Using the provider attestation as the entire customer evidence base. A SOC 2 Type II report from the provider does not discharge the customer side of a shared control; the customer must hold its own evidence for the obligations the responsibility allocation places on the customer.
- Letting the responsibility allocation drift. Cloud providers re-cut their service boundaries across releases; an allocation written at contract signing diverges from operational reality without an explicit refresh discipline. The audit finding is usually a stale shared-responsibility table.
- Citing CLD controls without mapping them to the cloud service in scope. The seven CLD controls only apply where the relationship exists; pasting the list into the SoA without per-service mapping produces an audit gap because the assessor cannot verify scope.
- Confusing ISO 27017 (cloud services), ISO 27018 (PII in public clouds), and ISO 27701 (privacy management). Each layers on the others; treating one as covering all three leaves either privacy or cloud-specific obligations unsupported.
- Treating tenant isolation as a provider concern. CLD.9.5.1 names segregation as an obligation that customers verify against the service they consume; multi-tenant security is provider-built and customer-verified, not customer-ignorable.
Where ISO 27017 sits alongside other compliance regimes
Most cloud-using organisations carry obligations from more than one regime, and the ISO 27017 controls overlap with several of them. The cross-walks below cover the regimes that most often layer on top of an ISO 27017 implementation rather than replacing it.
- SOC 2 is the attestation many cloud providers publish; ISO 27017 customers consume that attestation as part of the provider evidence chain. ISO 27001 + ISO 27017 and SOC 2 cover overlapping ground from different sides of the boundary.
- GDPR treats ISO 27017 as evidence that the technical and organisational measures required for cloud processors are in place, with the privacy-specific overlay coming from ISO 27018 or ISO 27701 where relevant.
- DORA draws on ISO 27001 family controls for ICT risk management framework evidence and specifically calls out third-party (cloud) provider risk management; ISO 27017 addresses the customer side of the cloud third-party relationship.
- NIS2 names cybersecurity risk management measures that cloud workloads must meet; ISO 27001 + ISO 27017 implementations supply much of the evidence base NIS2 reviews expect.
- FedRAMP is the US federal cloud authorisation regime, drawing on NIST 800-53 rather than ISO 27017. The control families overlap heavily; organisations operating both run a control mapping exercise rather than a full re-implementation.
Cloud security work that feeds the ISO 27017 evidence base
Cloud assessment work is the most direct source of evidence for the technological side of ISO 27017. Penetration tests against cloud-hosted applications, configuration reviews of cloud platform settings, identity reviews of federated access, and continuous scanning of verified cloud-hosted endpoints all produce findings that link back to specific ISO 27002 and CLD controls.
The page for cloud security consultancies covers the delivery model many ISO 27017 evidence engagements use, and the cloud security assessment guide covers the methodology that produces the findings the ISMS evidence base inherits. For the engagement workflow that runs the cloud assessment from scoping through to delivery, the cloud security assessment workflow covers the operational discipline that turns each assessment into reusable ISO 27017 evidence rather than a single-use report.
Scope and limitations
ISO/IEC 27017:2015 is published by the International Organization for Standardization and the International Electrotechnical Commission. SecPortal is the workspace that holds the engagement, the findings, the evidence, and the audit trail; certification under ISO 27001 with the ISO 27017 reference remains the registrant is responsibility, carried out through an accredited certification body. This page describes the structure of the standard and how a workspace-driven programme plays against the cloud-specific implementation guidance; the authoritative reference for the obligations remains the published standard text and any subsequent ISO and IEC revisions.
Nothing on this page is legal or audit advice. ISO 27001 certification decisions, including the ISO 27017 cloud reference, require the involvement of the organisation is information security leadership, internal audit, and the chosen certification body. The platform supports the underlying work record those roles rely on; it does not substitute for the certification body audit that determines whether the ISMS meets the standard.
Key control areas
SecPortal helps you track and manage compliance across these domains.
CLD.6.3.1: Shared roles and responsibilities
A formal record of which security responsibilities rest with the cloud customer, which rest with the cloud service provider, and where the boundary sits per service. The control codifies the shared responsibility model as an obligation rather than a marketing diagram.
CLD.8.1.5: Removal of cloud service customer assets
Customer data and configuration are returned or destroyed when the cloud service contract ends, with verification that no copies remain in provider-controlled storage. The control closes the data lifecycle inside the provider boundary.
CLD.9.5.1: Segregation in virtual computing environments
Customers in a multi-tenant cloud environment are isolated from each other and from the provider tenants at the network, storage, and compute layers. The control names tenant isolation as a discrete obligation rather than a property of the platform.
CLD.9.5.2: Virtual machine hardening
Virtual machine images and instances are hardened against known threats, with the customer and provider responsibilities for hardening recorded per layer. The control addresses the workload baseline that sits above the platform baseline the provider operates.
CLD.12.1.5: Administrator operational security
Administrative actions in the cloud environment are documented, authorised, and auditable. The control raises the bar for administrative governance because cloud admin actions can affect many customers in a single change.
CLD.12.4.5: Monitoring of cloud services
The cloud customer monitors cloud service operation against the agreed service definition, with logs, metrics, and incident records that feed into the customer ISMS. The control names provider monitoring as customer evidence rather than as provider opacity.
CLD.13.1.4: Alignment of security management for virtual and physical networks
Security management of virtual networks (VLANs, virtual switches, software-defined networking) is aligned with the equivalent physical network controls. The control prevents the gap that opens when virtual networks inherit weaker controls than the physical networks they replace.
Evidence ISO 27017 cloud controls without losing the audit trail
Track customer and provider responsibilities per control, attach cloud assessment findings, and keep the evidence base ready for surveillance review.
No credit card required. Free plan available forever.