ISO/IEC 27017 Cloud Security Controls Guide

Most cloud security failures happen in the gap between what the provider secures and what the customer assumes the provider secures. ISO/IEC 27017 is the ISO code of practice written for that gap: it extends the ISO/IEC 27002 controls with guidance for cloud service providers and cloud service customers, and adds controls that only make sense in a shared, multi-tenant service. This guide explains what the standard is, which edition is current (the 2015 edition was withdrawn in July 2026), how it is structured, how to use it alongside an ISO/IEC 27001 ISMS, what auditors look for and where machine identities fit. It is written for security architects, cloud platform teams, GRC leads and anyone reading a provider's ISO/IEC 27017 certificate during due diligence.

Key takeaways

It is guidance, not a certifiable management system on its own. ISO/IEC 27017 is a code of practice used inside an ISO/IEC 27001 ISMS; organisations are certified to ISO/IEC 27001 with ISO/IEC 27017 controls in scope.
The current edition is ISO/IEC 27017:2026. ISO published the second edition on 27 July 2026 and withdrew ISO/IEC 27017:2015 the same day, so check which edition a certificate references.
It speaks to both sides of the contract. Each piece of guidance is split between what the provider does and what the customer does, which makes it a practical tool for writing a shared responsibility matrix.
A provider certificate does not certify you. AWS and Microsoft both state that customers are not certified by association; your own configuration, identities and data remain your responsibility.
Identity is where the shared model breaks most often. Customer-side cloud accounts, roles, keys and tokens, many of them non-human, were the root cause in incidents such as Snowflake 2024 and Capital One 2019.

What it is and who it applies to

ISO/IEC 27017 is published by ISO and IEC through joint technical committee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection). The ISO catalogue describes the first edition as giving guidelines for information security controls applicable to the provision and use of cloud services, by providing additional implementation guidance for relevant ISO/IEC 27002 controls and additional cloud-specific controls with their own guidance, for both cloud service providers and cloud service customers.

Edition	Published	Status (ISO catalogue)	Base control set
ISO/IEC 27017:2015 (edition 1, 30 pages)	30 November 2015	Confirmed in 2024, marked for revision in 2025, withdrawn 27 July 2026	ISO/IEC 27002:2013
ISO/IEC 27017:2026 (edition 2, 39 pages)	27 July 2026	Published, stage 60.60	ISO/IEC 27002 (the title states the controls are based on ISO/IEC 27002)

The 2026 edition carries the new SC 27 title prefix "Information security, cybersecurity and privacy protection". The ISO catalogue page does not list what changed between editions. Until you have read the 2026 text, treat descriptions of the control set on provider pages as describing the 2015 edition, which is what most certificates in circulation still reference.

Cloud service providers (CSPs): IaaS, PaaS and SaaS providers use it as implementation guidance and to scope ISO/IEC 27001 certification of their cloud services. AWS, Microsoft and Google Cloud all publish ISO/IEC 27017 certificates.
Cloud service customers (CSCs): any organisation consuming cloud services uses it to understand what to expect from a provider and which controls remain its own. Microsoft's offering page makes this explicit.
SaaS vendors in the middle: a SaaS company is a customer of its IaaS provider and a provider to its own customers, so both halves of the guidance apply at once.
Auditors and procurement teams: ISO/IEC 27017 gives a common vocabulary for questionnaires and contract schedules. See the Third-Party Risk Management Guide.

Structure and key requirements

The standard follows the ISO/IEC 27002 structure and adds cloud-specific text where it is needed. Microsoft and Google describe the 2015 edition the same way: additional implementation guidance on 37 ISO/IEC 27002 controls and seven new cloud-specific controls. For each control, guidance is given for the CSP and for the CSC, which is what makes the document useful for both parties. This guide does not reproduce clause text or numbering; buy the standard from ISO or your national standards body for that.

The seven cloud-specific controls (2015 edition, as described by providers)

Topic	Provider side (typical evidence)	Customer side (typical evidence)
Shared roles and responsibilities	Published responsibility model per service, contract terms	Responsibility matrix per service consumed, owners named for each customer control
Return and removal of customer assets at contract end	Documented export formats, deletion process, retention periods	Exit plan, export tested, deletion confirmation requested and kept
Segregation in virtual computing environments (tenant separation)	Isolation design, hypervisor and network separation testing	Separate accounts, subscriptions or projects per environment and data class
Virtual machine hardening	Hardened base images and host builds	Hardened images, CIS benchmarks, disabled unused services and ports
Administrator's operational security	Procedures for privileged operations on the platform	Documented procedures for destructive or high-risk admin operations, approvals, break-glass
Monitoring of cloud services	Logs and monitoring features exposed to customers	Audit logs enabled, retained and reviewed for all accounts and regions
Alignment of virtual and physical network security	Consistent policy between physical and virtual network layers	Virtual network segmentation, security groups and firewall rules consistent with on-premises policy

Themes in the extended ISO/IEC 27002 guidance

Supplier relationships: what a cloud agreement must state, including the location of data, sub-contracted providers and responsibilities. See the ISO/IEC 27036 Supplier Relationships Guide.
Access control: user registration, privileged access and authentication for cloud administration interfaces, on both sides.
Cryptography: who generates and holds keys, and what the provider tells the customer about encryption it applies. See the Cryptographic Key Management Guide.
Logging and clocks: which events the provider logs, which logs the customer can obtain, and time synchronisation.
Capacity, change and backup: notification of changes that affect customers, and clarity on backup scope.
Incident management: how and when the provider reports incidents to customers, and how customers report to the provider. See the ISO/IEC 27035 Incident Management Guide.
Legal and compliance: jurisdiction, records and evidence collection in a multi-tenant environment.

Identity and NHI requirements

The access control guidance in ISO/IEC 27017 applies to every identity that can call a cloud control plane, and in most estates the majority of those identities are not people. IAM roles, service principals, service accounts, access keys, storage SAS tokens and CI/CD credentials all sit on the customer side of the shared responsibility line.

Customer identity concern	What good looks like	Confirmed control references
Cloud admin accounts (human)	Federated SSO, phishing-resistant MFA, no standing global admin, separate break-glass accounts	NIST SP 800-53 AC-2, AC-6; CSF PR.AA-05
Workload roles and service accounts	Scoped to one workload, least privilege, owner recorded, reviewed	NIST SP 800-53 AC-6, AC-3
Long-lived keys and tokens	Replaced by workload identity federation or short-lived credentials; where unavoidable, vaulted, rotated and expiring	NIST SP 800-53 IA-5, SC-12
Instance metadata credentials	Metadata service hardened (for example token-based IMDSv2 on AWS), role scope minimal	ATT&CK T1552.005 Cloud Instance Metadata API
Valid cloud account abuse	Anomaly detection on sign-ins and API calls, network restrictions on service logins	ATT&CK T1078.004 Cloud Accounts; CSF DE.CM-09
Bulk data access	Alerting on unusual read volumes from storage	ATT&CK T1530 Data from Cloud Storage

Write identities into the responsibility matrix: the provider secures its own staff access and the IAM service itself; the customer owns every principal, policy and credential it creates.
Treat administrator's operational security as including automation: pipelines and infrastructure-as-code roles perform the destructive operations the standard is concerned with, so give them the same approval and logging as human admins.
Tie exit to identity: returning and removing assets at contract end includes revoking federations, keys and third-party OAuth grants. See the NHI Offboarding and Decommissioning Guide.

See the Workload Identity Federation Guide and the Cloud PAM and CIEM Guide.

Implementation steps

For a customer, the aim is a documented, tested split of responsibilities per service, with ISO/IEC 27017 controls included in the ISMS Statement of Applicability. For a provider, the aim is the same split published to customers, plus certification evidence.

Confirm the edition and get the text. Buy ISO/IEC 27017:2026. If you hold a certificate against the 2015 edition, ask your certification body how and when it expects you to transition.
Inventory cloud services. List every IaaS, PaaS and SaaS service in use, including those bought by business units, with the data classes each holds. See the Data Classification Guide.
Build the responsibility matrix. For each service, map each relevant control to provider, customer or shared, using the provider's published model and certificate scope as input. Name an owner for every customer and shared row.
Gather provider evidence. Download certificates and the in-scope service lists (AWS publishes services and Regions in scope; Microsoft through the Service Trust Portal; Google through Compliance Reports Manager). Confirm the services you use are actually in scope.
Close customer gaps first where data is most sensitive. Typical first fixes: MFA and federation for all console access, removal of unused keys, audit logging in every account and region, separation of production from development tenants.
Update the ISMS. Add the cloud controls to the risk treatment plan and Statement of Applicability, and update policies for cloud use, change and incident reporting.
Test before audit. Run a tabletop on a provider incident, test a data export and deletion for one non-critical service, and run a cloud posture scan in report-only mode before enforcing new guardrails through policy (for example service control policies or Azure Policy deny effects), so you can roll back a guardrail that breaks workloads.
Review on change. Re-run the matrix when you adopt a new service, when a provider changes its scope or when certificates are renewed.

Decision guidance

Situation	Approach
Small organisation, one SaaS-heavy estate	Use ISO/IEC 27017 as a due diligence checklist and a short responsibility matrix per critical SaaS; certification is rarely worth it on its own
Organisation already certified to ISO/IEC 27001	Add ISO/IEC 27017 controls to the Statement of Applicability and ask your certification body to include them in scope
SaaS or managed service provider	Certify ISO/IEC 27001 with ISO/IEC 27017 (and ISO/IEC 27018 if you process customer PII); publish a customer-facing responsibility model
Need for a cloud control catalogue with self-assessment registry	Consider the CSA Cloud Controls Matrix and STAR alongside ISO/IEC 27017. See the Cloud Security Alliance CCM and STAR Guide.

Evidence and assessment

ISO/IEC 27017 is assessed as part of an ISO/IEC 27001 certification audit, by an accredited certification body. AWS names EY CertifyPoint, accredited by the Dutch Accreditation Council, an IAF member; Microsoft states its cloud services are audited at least annually. Customers receive the certificate and, in some cases, an audit assessment report.

Reading a provider certificate: check the standard and edition, the certified services and Regions, the issue and expiry dates, the certification body and its accreditation. A certificate that omits the service you use gives you no assurance for it.
Customer evidence an auditor will ask for: the responsibility matrix, the Statement of Applicability entries, identity and access reviews for cloud admin and workload identities, logging configuration, exit and deletion procedures, and incident reporting arrangements with providers.
Do not inherit what you cannot show: Microsoft states that customers may use its certifications in their own assessment but remain responsible for engaging an assessor for their own implementation.

Detection and measurement

Monitor control plane audit logs (AWS CloudTrail, Azure Activity Log and Entra sign-in logs, Google Cloud Audit Logs) for privileged changes, new keys, policy changes and disabled logging. See the Cloud Logging and Audit Trail Guide.

Responsibility coverage: percentage of in-use cloud services with an approved responsibility matrix and named owners (target 100% for services holding confidential data).
Certificate currency: percentage of critical providers whose certificate is in date and lists the services you use.
Long-lived credential count: number of active access keys or secrets older than 90 days, trending down.
Logging coverage: percentage of accounts, subscriptions and projects with audit logging enabled and centralised.
Exit readiness: share of critical services with a tested export in the last 12 months.

Mapping to other frameworks

ISO/IEC 27017 topic	ISO/IEC 27001:2022 Annex A	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Shared roles and supplier agreements	5.19 to 5.23 (5.23 information security for use of cloud services)	SA-9, SA-9(5)	GV.SC-05, GV.SC-07, GV.RR-02
Return and removal of assets	5.23, 8.10 information deletion	MP-6	GV.SC-10
Tenant separation and network alignment	8.22 segregation of networks	SC-4, SC-7	PR.DS-01
VM hardening	8.9 configuration management	CM-6	PR.PS-01
Administrator operations and access	8.2 privileged access rights	AC-2, AC-6	PR.AA-05
Monitoring of cloud services	8.15 logging	AU-2, AU-6	PR.PS-04, DE.CM-09
Encryption and keys	8.24 use of cryptography	SC-12, SC-28	PR.DS-01

In CIS Controls v8.1, Control 15 (Service Provider Management) covers the provider relationship, and Controls 3 (Data Protection) and 6 (Access Control Management) cover much of the customer side. The CSA Cloud Controls Matrix v4.1 (197 control objectives in 17 domains) is a cloud-specific catalogue that also indicates which party should implement each control. For the management system itself see the ISO 27001 Certification Guide and the ISO 27002 Controls Guide. For PII processing by cloud providers see the ISO/IEC 27018 Cloud PII Protection Guide.

A naming note: searches for "27017" also return MongoDB, whose default port is TCP 27017. That is unrelated to the standard, though exposed databases on default ports are a classic customer-side cloud failure. See the Network Ports and Protocols Security Guide.

Common pitfalls

Treating the provider's certificate as your control. In the Snowflake breach, attackers logged in to about 165 customer accounts with infostealer credentials where MFA, rotation and network allow lists were missing; Snowflake reported no flaw in its own platform. Customer-side identity controls were the gap.
Over-permissive workload roles. In the Capital One breach, a misconfigured firewall's role credentials gave access to S3 data on about 106 million people because the role held far more access than the firewall needed. VM hardening and least privilege are customer duties.
Unmanaged sharing tokens. The Microsoft SAS token exposure used an account-level, full-control token with expiry extended to 2051, exposing 38TB of internal data. Shared access mechanisms need scope, expiry and inventory.
Checking certificate existence, not scope. Providers list in-scope services and Regions separately; a new or regional service may not be covered.
No exit test. The asset return and removal control is often only on paper until a migration or dispute reveals export gaps.
Edition drift. Policies and supplier questionnaires still citing ISO/IEC 27017:2015 after its withdrawal in July 2026.

Practitioner checklist

Obtain ISO/IEC 27017:2026 and record which edition each provider certificate references.
Maintain an inventory of cloud services with data classes and business owners.
Publish a responsibility matrix per critical service with named customer owners.
Confirm each service you use is inside the provider's certified scope and Regions.
Enforce SSO and phishing-resistant MFA on all cloud consoles, with tested break-glass accounts.
Replace long-lived access keys with federation or short-lived credentials, and record an owner for every workload identity.
Enable and centralise control plane audit logs in every account, subscription and project.
Test data export and deletion for at least one critical service each year.
Add ISO/IEC 27017 controls to the ISO/IEC 27001 Statement of Applicability and risk treatment plan.

ISO/IEC 27017 Cloud Security Controls Guide: Guidance for Providers and Customers