ISO/IEC 27017 is the cloud security companion to ISO 27001 – a code of practice that takes the familiar information security controls and answers the question they leave open in a cloud world: whose job is this control now? It provides cloud-specific implementation guidance for the existing control set plus seven additional cloud controls (the CLD controls), each written from two perspectives: what the cloud service provider must do, and what the cloud service customer must do. That dual perspective is the standard's entire point – and the reason it's valuable whether you build cloud services or just consume a lot of them.
The problem it solves: the responsibility gapLink to this section
Nearly every significant cloud breach traces to the same root cause – not a hypervisor exploit, but a control that fell into the gap between provider and customer: the storage bucket left public, the admin console without MFA, the logging that was available but never enabled. Providers secure the cloud; you secure what you put in it. ISO 27017 forces that boundary to be drawn explicitly, control by control, service by service – CLD.6.3.1 (shared roles and responsibilities) is arguably the single highest-value control in any cloud programme, and it's the first artefact we build.
What certification looks likeLink to this section
ISO 27017 is a code of practice rather than a standalone management system standard, so you don't certify against it in isolation. Instead, it's assessed as an extension of your ISO 27001 certification: the CLD controls and cloud guidance are added to your Statement of Applicability, audited alongside Annex A, and referenced on your certificate. For cloud-native companies this is the highest-leverage add-on available – a modest increment of effort on top of an ISMS that turns "we're ISO 27001 certified" into "our certification explicitly covers how we run cloud services", which is exactly the distinction enterprise security reviewers probe.
For providers and for customersLink to this section
If you provide cloud services (SaaS counts), ISO 27017 tells you what your customers are entitled to expect: documented responsibility splits, isolation between tenants, defined asset return and deletion at contract end, and the security information you must make available. Having it on your certificate shortens security questionnaires measurably. If you consume cloud services, the same controls become your due-diligence checklist and your internal to-do list – the customer-side responsibilities (identity, configuration, monitoring, backup) are precisely the ones nobody else will do for you.
How ISO 27017 relates to other frameworksLink to this section
It presupposes ISO 27001 – that's the management system it extends. Its sibling ISO 27701 does the same job for privacy (with ISO 27018 covering PII protection in public clouds specifically). And its discipline of explicit responsibility mapping is exactly what regimes like IRAP assessments and SOC 2 audits examine when cloud services are in scope – build the matrix once, reuse it everywhere. One note: ISO 27017's control numbering tracks the 2013-era ISO 27002 catalogue while a refresh aligning it to ISO 27002:2022 works through the pipeline; we map between the two so your SoA stays coherent.
How we helpLink to this section
We're a cloud-native company ourselves, and our consultants secure real AWS, Azure, and GCP estates – so this guidance gets implemented in Terraform and IAM policy, not just in documents:
- Shared-responsibility mapping. A per-service responsibility matrix across your entire cloud and SaaS estate – the foundational artefact for CLD.6.3.1 and for every audit that follows.
- Cloud control implementation. Hardened baselines, admin-plane lockdown, tenant segregation, logging and monitoring pipelines, and tested backup – engineered with your platform team, not thrown over the wall.
- SoA extension and certification. We fold the ISO 27017 controls into your Statement of Applicability, prepare the evidence, and support the extension audit alongside your ISO 27001 cycle.
- Cloud security training. Practitioner-led secure-cloud training for engineers and cloud awareness for the broader workforce, with completions recorded in our tamper-evident training ledger – because misconfiguration is a human error before it's a technical one.
- Customer-assurance collateral. For providers: the responsibility documentation and evidence pack that turns security questionnaires from a week's work into an attachment.
The table below covers the seven cloud-specific CLD controls plus the highest-impact areas of extended guidance, and how we help with each.
Cloud-specific controls and key extended guidance
Cloud-specific controls (CLD)
| Ref | Control | How we help |
|---|---|---|
| CLD.6.3.1 | Shared roles and responsibilities within a cloud computing environment | We build your shared-responsibility matrix per service – who patches, who configures, who monitors, who responds – across AWS, Azure, GCP, and your SaaS estate, and make it part of onboarding and contracts. |
| CLD.8.1.5 | Removal of cloud service customer assets | We verify (contractually and technically) that your data and assets are returned or destroyed when a cloud service ends – the exit clause everyone forgets to test until they need it. |
| CLD.9.5.1 | Segregation in virtual computing environments | We assess tenant isolation for the services you consume and design the account, VPC, and workload segregation on your side of the responsibility line. |
| CLD.9.5.2 | Virtual machine hardening | We implement hardened baseline images, infrastructure-as-code enforcement, and drift detection so every workload starts and stays at the standard you set. |
| CLD.12.1.5 | Administrator's operational security | We lock down cloud admin planes – MFA on every console, just-in-time privileged access, break-glass procedures, and logging of administrative operations. |
| CLD.12.4.5 | Monitoring of cloud services | We wire provider-native telemetry (CloudTrail, Azure Monitor, and friends) into your monitoring so you can actually detect misuse of cloud services, and define what the provider must give you. |
| CLD.13.1.4 | Alignment of security management for virtual and physical networks | We bring virtual network security policy in line with your network security standards, so software-defined networking doesn't become a parallel, ungoverned network estate. |
Extended cloud guidance on existing controls
| Ref | Control | How we help |
|---|---|---|
| 6.1.1 | Information security roles and responsibilities (cloud context) | We define cloud security ownership inside your organisation – platform teams, application teams, and security – so no control is "someone else's job" on both sides of the line. |
| 9.2 | User access management for cloud services | We implement SSO, role-based access, and lifecycle deprovisioning across cloud consoles and SaaS apps, with access reviews that generate their own audit evidence. |
| 10.1 | Cryptography in the cloud | We define encryption and key-management policy for cloud workloads – provider-managed vs customer-managed keys, and when the difference actually matters for your risk and your regulators. |
| 12.3 | Backup in cloud environments | We design backup that survives the failure modes cloud actually has – account compromise, region outage, deletion by automation – and test restoration rather than assuming it. |
| 12.4 | Logging and monitoring of cloud operations | We define log sources, retention, and clock synchronisation across providers, and centralise them so investigations don't start with an archaeology project. |
| 15.1 | Supplier relationships and the cloud service chain | We run cloud-specific due diligence on providers and their subcontractor chains, and encode security requirements into cloud agreements rather than trusting the marketing page. |
| 16.1 | Incident management across the shared boundary | We build incident procedures that span the responsibility split – what the provider notifies, what you investigate, and who communicates – and exercise them with cloud-specific scenarios. |
| 18.1 | Compliance, jurisdiction, and evidence in the cloud | We map where your data physically lives, which jurisdictions can reach it, and how to extract audit evidence from services you don't control – answers your customers and regulators will ask for. |