ISO/IEC 27017 changed substantially in 2026. The current second edition replaces ISO/IEC 27017:2015, aligns the cloud guidance with ISO/IEC 27002:2022, and changes how cloud-specific controls fit into the broader information security control structure.
For a cloud security engineer, the harder task starts after the control is identified. You need to establish who owns the control, which part the cloud provider operates, what the customer must configure, and what evidence shows that the implemented state still satisfies the organization's requirements.
TL;DR
- ISO/IEC 27017:2026 is the current edition and replaces ISO/IEC 27017:2015. It aligns cloud security guidance with ISO/IEC 27002:2022 and changes the old seven-CLD-control model
- The 2026 structure includes four standalone cloud-specific controls, while several topics previously handled as separate CLD controls are now addressed through the corresponding ISO/IEC 27002 controls
- Implementation starts with responsibility mapping: for each cloud service, define what the CSC, CSP, and any cloud service partner operate, then verify the customer-controlled configuration across AWS, Azure, and GCP
- Audit evidence must combine provider assurance with current customer-side evidence. A provider's ISO 27017 assurance does not extend to the customer's own configuration, controls, or audit scope
What is ISO/IEC 27017:2026?
ISO/IEC 27017:2026 provides cloud-specific guidance for implementing information security controls in the provision and use of cloud services. It builds on ISO/IEC 27002 and addresses both cloud service customers (CSCs) and cloud service providers (CSPs). ISO states that the standard applies across public, private, and hybrid cloud environments.
The standard does not replace ISO/IEC 27001 or ISO/IEC 27002. ISO/IEC 27001:2022 defines requirements for an information security management system (ISMS), while ISO/IEC 27002:2022 provides guidance on information security controls. ISO/IEC 27017 adds the cloud context needed when infrastructure, administrative access, monitoring, data handling, and other security activities are divided between organizations.
That responsibility split is central to the standard:
| Decision area | What it means |
|---|---|
| Control selection | Select and apply controls based on the organization's risk assessment and relevant legal, regulatory, contractual, and cloud-specific security requirements |
| Provider-operated controls | A managed cloud service may shift execution of part of a control to the CSP, depending on the service model and agreed responsibility boundary |
| Customer responsibility | The CSC still has to determine whether the provider capability and its own configuration together satisfy the organization's security requirement |
| Evidence | Keep enough customer-side and provider-side evidence to show who performs the control, how it is implemented, and whether the resulting state is acceptable |
For the broader standards landscape, see cloud security compliance standards.
What changed from ISO/IEC 27017:2015 to ISO/IEC 27017:2026?
The 2026 edition is more than a renumbering exercise. The current ISO lifecycle record shows ISO/IEC 27017:2015 as withdrawn and Edition 2 as published. The new edition is explicitly based on ISO/IEC 27002:2022, whereas the 2015 edition was built on the previous ISO/IEC 27002 structure.
| ISO/IEC 27017:2015 | ISO/IEC 27017:2026 |
|---|---|
| Based on the previous ISO/IEC 27002 control structure | Based on ISO/IEC 27002:2022 |
| Seven additional cloud controls commonly used as the implementation model | Four standalone cloud-specific controls in the current implementation structure |
| Several cloud topics existed as separate CLD controls | Several topics are now handled through the corresponding ISO/IEC 27002:2022 controls |
| Focused primarily on the CSC/CSP relationship | Adds explicit treatment of cloud service partner responsibilities and unauthorized cloud use |
The old seven-control model is still visible in current provider documentation. Google Cloud's ISO 27017 page, for example, describes the 2015 edition as providing guidance on 37 ISO/IEC 27002 controls plus seven additional cloud controls covering responsibility allocation, asset return, virtual-environment separation, VM configuration, administrative operations, monitoring, and network alignment.
The 2026 edition reorganizes those topics around the ISO/IEC 27002:2022 structure rather than preserving the old seven-control set. Teams migrating an existing program should remap before rebuilding: update the SoA, risk-treatment mappings, cloud policies, supplier questionnaires, and contracts that still reference the withdrawn edition.
ISO 27001 vs. 27002 vs. 27017 vs. 27018
These standards overlap, but they are not interchangeable. The table below shows what each one is for and where it fits in a cloud security program.
| Standard | Primary job | Cloud relevance |
|---|---|---|
| ISO/IEC 27001:2022 | Defines requirements for an ISMS | Establishes the risk-treatment and certification context |
| ISO/IEC 27002:2022 | Provides general information security control guidance | Supplies the base guidance that ISO/IEC 27017 extends |
| ISO/IEC 27017:2026 | Adds cloud-specific security guidance | Addresses CSC/CSP responsibilities and additional cloud controls |
| ISO/IEC 27018:2025 | Provides guidance for protecting PII in public clouds acting as PII processors | Adds privacy-specific guidance for public-cloud PII processing |
The distinction between 27017 and 27018 is particularly important. ISO/IEC 27018:2025 applies specifically to the protection of personally identifiable information in public cloud services when the CSP acts as a PII processor.
The control decision, therefore, starts upstream of 27017. The organization's risk process determines what needs treatment, ISO/IEC 27002 supplies general control guidance, and ISO/IEC 27017 adds the cloud-specific interpretation. See the ISO 27001 risk assessment guide for the risk-assessment workflow.
What are the ISO/IEC 27017:2026 cloud security controls?
ISO/IEC 27017:2026 should not be read as a four-control checklist. ISO describes the standard as providing additional guidance for relevant ISO/IEC 27002:2022 controls plus additional controls that specifically relate to cloud services.
The standalone cloud-specific set in the current implementation structure consists of:
- 5.38 CLD: Shared roles and responsibilities within a cloud computing environment
- 5.39 CLD: Agreement on the roles and responsibilities of the cloud service partner
- 8.35 CLD: Segregation in virtual computing environments
- 8.36 CLD: Detection and prevention of unauthorized use of cloud services
ISO's Online Browsing Platform publicly exposes 5.38 and 5.39 in the 2026 edition. An open-source ISMS core implementation pack independently maps the current standalone set to 5.38, 5.39, 8.35, and 8.36 and builds implementation material around those controls.
5.38 CLD: Shared roles and responsibilities
5.38 requires the customer and provider to clearly allocate and document their cloud security responsibilities. A provider's shared responsibility model gives the general split, but it does not show who owns every security task in your specific implementation.
For each cloud service in scope, document who is responsible for tasks such as identity configuration, logging, encryption, backup and recovery, incident handling, and control validation. The allocation should also identify any gaps where neither side has clearly accepted responsibility.
A useful implementation artifact is a service-level Shared Responsibility Matrix:
| Security task | CSC responsibility | CSP responsibility | Evidence |
|---|---|---|---|
| Identity and access | Define users, roles, privileges, and access reviews | Provide identity and access-control capabilities for the service | IAM/RBAC configuration, access review record, provider documentation |
| Encryption | Select required encryption options and manage customer-controlled keys where used | Provide supported encryption and key-management capabilities | Service configuration, key policy, provider encryption documentation |
| Logging | Define required database and administrative events and enable available logs | Generate and expose supported service logs | Logging configuration, sample events, retention settings |
| Backup and recovery | Define backup scope, retention, and recovery objectives | Operate the managed backup capability included in the service | Backup policy, restore test, provider service documentation |
| Platform patching | Patch customer-managed components where applicable | Maintain the managed service platform within the provider's responsibility | Provider assurance/documentation, internal patch records where applicable |
| Incident response | Investigate customer-side activity, contain affected accounts/workloads, and coordinate escalation | Notify and support the customer according to the agreed service and incident process | Incident runbook, contact matrix, provider notification terms |
The matrix should be created per service or service type, because the responsibility split for a managed database will differ from IaaS, Kubernetes, or SaaS.
5.39 CLD: Cloud service partner roles and responsibilities
5.39 extends responsibility allocation beyond the direct CSC/CSP relationship to cloud service partners. This matters when the operating chain includes an MSP, broker, systems integrator, managed security provider, or another organization acting between the customer and provider.
The CSP boundary can be perfectly clear while security responsibility still disappears at the partner handoff. For each partner relationship, record:
- Service or function operated
- Authority granted to the partner
- Security responsibilities assigned
- Evidence the partner must supply
- Incident and escalation responsibilities
- Point where responsibility returns to the CSC or CSP
The objective is to prevent a control from becoming implicitly “shared” when no party has accepted responsibility for executing or evidencing it.
8.35 CLD: Segregation in virtual computing environments
8.35 addresses isolation in shared virtual environments. The customer first needs an isolation requirement for the data and workload involved. It can then separate controls inherited from the CSP from controls exposed to customer configuration.
Depending on the service model, the customer may still control identities, network boundaries, account or subscription structure, workload placement, and tenant-facing service settings.
The evidence package therefore needs both sides of the boundary: provider assurance for inherited mechanisms and customer-side evidence for the configuration the customer controls. For environments where the organization operates more of the infrastructure stack itself, see private cloud data security for the control and evidence model.
8.36 CLD: Detection and prevention of unauthorized cloud use
8.36 addresses cloud use that falls outside approved organizational processes.
Shadow cloud is an obvious example: a business unit creates an unapproved SaaS tenant, AWS account, Azure subscription, GCP project, or managed service outside the normal provisioning path. A policy can prohibit that behavior, but policy alone cannot tell the security team where the service exists or who owns it.
The operating process needs to detect unknown cloud use, establish ownership, determine whether it is approved, and route the exception for remediation or formal acceptance. For the broader mechanics behind preventive, detective, and corrective safeguards, see cloud security controls.
How to implement ISO 27017 controls in AWS, Azure, and GCP
The implementation work is easier to manage when controls are grouped by the engineering decision they create. The five groups below are an operational model for implementation, not ISO's official taxonomy.
1. Define shared responsibility and cloud partner boundaries
Start with responsibility and supplier controls such as 5.2, 5.20, 5.38, and 5.39. Map responsibility at the service and control level.
For each service, record:
- CSC responsibility
- CSP responsibility
- CSN or MSP responsibility where applicable
- Internal control owner
- Provider evidence required
- Escalation path when allocation is unclear
The provider's generic responsibility model rarely resolves the last mile. “AWS operates the managed database” does not determine who enables the required logs, chooses customer-controlled encryption settings, validates backup retention, or reviews privileged access inside the customer's account.
AWS and Microsoft both describe cloud security as shared according to the service and customer configuration. Microsoft notes that responsibilities vary across SaaS, PaaS, IaaS, and on-premises deployments.
The control owner therefore needs to distinguish outsourced execution from retained accountability.
2. Maintain cloud inventory, configuration, and lifecycle controls
Controls such as 5.9, 5.11, 8.9, 8.10, and 8.36 depend on knowing what exists and how it is configured.
At minimum, resolve:
- AWS account, Azure subscription, or GCP project
- Resource type and identifier
- Application or business service
- Environment
- Accountable owner
- Approved configuration baseline
- Current configuration state
- Lifecycle or termination status
An approved Terraform module or hardened image demonstrates intended state. It does not prove that every production resource still matches the baseline. Configuration evidence needs current state plus enough change context to explain legitimate exceptions. For the broader process of validating whether approved design still matches deployed resources and current controls, use our cloud security architecture review checklist
Termination needs the same precision. Before a cloud relationship ends, establish how assets are returned, what customer data is deleted, which copies or backups remain, the applicable retention period, and what provider evidence will confirm completion.
Implementation of a multi-cloud CMDB helps inventory become more useful when resources are tied to applications, owners, dependencies, and control context.
3. Control identity, privileged access, and tenant segregation
Controls including 5.16 through 5.18, 8.2, 8.3, and 8.35 shift the review from provider capability to configured access.
Review:
- Privileged identities and administrative roles
- MFA coverage for relevant privileged access
- Restrictions around sensitive resources and data
- Joiner, mover, and leaver behavior
- Tenant and environment boundaries
- Provider-managed versus customer-managed identity functions
The evidence question is “who can perform this action now?” rather than “does the platform offer IAM?”
Example of centralized identity context in Cloudaware: Ownership, roles, access scope, application context, and related violations collected in one view for review.
The same objective can generate different evidence in AWS IAM, Microsoft Entra ID, Azure RBAC, and Google Cloud IAM. A centralized view can then bring the resulting identity, ownership, access, and policy context together for review.
See Kubernetes security best practices guide for how cloud IAM, Kubernetes RBAC, workload identity, network controls, logging, and evidence.
4. Protect workloads, data, vulnerabilities, and recovery paths
Controls such as 8.8, 8.11, 8.13, and 8.24 expose another recurring problem: a provider capability is mistaken for an implemented customer control.
- For technical vulnerabilities, determine which software layer the provider maintains and which remains under customer control.
- For encryption, identify the protected data paths, key-management model, and customer-controlled settings.
- For backup, define the workload population, retention, recovery requirements, restore testing, and gaps between provider capability and the organization's recovery objective.
The review pattern is: Requirement → provider capability → customer configuration → current evidence
Example of centralized workload security evidence in Cloudaware: Current vulnerabilities, threats, observations, and misconfigurations grouped in one view for review.
The open-source ISMS cloud guidance uses this CSC/CSP split across existing controls. For example, its implementation asks the customer to evaluate whether CSP capabilities meet its requirements, while the provider supplies the relevant capability and supporting information.
CNAPP platforms can consolidate posture, workload, identity, data, and runtime findings, but they still need to preserve the control context behind each signal. If you are comparing that broader security layer, see our guide to CNAPP tools.
5. Maintain logs, monitoring, incident workflows, and evidence
Controls including 5.24, 5.28, 5.35, 8.15, 8.16, 8.17, and 8.32 depend on coordination between the capabilities the CSP exposes and the evidence the CSC needs.
Define:
- Required event sources
- Log retention and access requirements
- Time-synchronization expectations
- Incident contacts and notification windows
- Evidence-collection procedures
- Provider changes that trigger customer reassessment
- Independent provider assurance where risk, contractual, or audit requirements call for it
Example of enriched log event in Cloudaware: Raw telemetry connected to account, application, environment, and region context.
Coverage matters more than raw log volume. If a production population is expected to generate security telemetry, the review should determine whether those resources are represented in monitoring and whether the resulting events can be traced to the relevant service and owner.
For GCP-specific implementation, see our Google Cloud security guide for IAM and controls across a multi-cloud operating model. For the broader operating model behind telemetry coverage, resource context, ownership, and verified closure, see cloud security observability
How to build ISO 27017 audit evidence
Audit evidence for ISO 27017 is rarely stored in one place. So the audit problem is proving that these artifacts refer to the same control, cloud service, responsibility boundary, and current technical state.
A control evidence matrix gives reviewers that traceability. You can use a template below:
| Evidence field | 8.13 | 8.15 | 8.35 |
|---|---|---|---|
| Cloud service | Production backup service | Cloud logging | Virtual environment |
| CSC responsibility | Define scope, retention, and recovery objective | Define events and retention | Define isolation requirement |
| CSP dependency | Provider backup capability | Provider log-generation capability | Provider virtualization controls |
| Technical state | Required backups configured | Required sources enabled | Customer boundaries configured |
| Evidence | Configuration export, restore test, provider documentation | Logging configuration, retention settings, sample events | Network/IAM configuration plus provider assurance |
| Owner | Platform team | Security engineering | Cloud security |
| Last validated | Date | Date | Date |
Maintain three evidence layers:
- Provider evidence: Certificate scope, SLA, service documentation, and independent assurance reports
- Customer evidence: Resource configuration, inventory, access state, policies, logs, changes, and tickets
- Operating evidence: Owner, exception status, remediation record, re-test, and validation date
AWS, for example, makes compliance reports and certifications available through AWS Artifact and states that customers can use those reports as audit evidence for AWS-operated controls while remaining responsible for documentation of their own security and compliance.
Microsoft follows the same model for ISO 27017: customers can use Microsoft's certification and audit materials in their assessment, but their own implementation, controls, and processes still need to be evaluated.
Provider assurance only covers the part of the control the provider operates. The rest of the evidence still has to come from the customer’s own configuration, processes, ownership records, and remediation history. A practical workflow can look like this:
This sequence follows the logic of the standard and the wider ISO 27001 risk-based process: define the cloud scope, establish responsibility, assess risk, map controls, implement the customer side, and retain evidence for both inherited and customer-operated controls.
For provider-specific assessment execution, see the Google Cloud security assessment guide for GCP evidence mapping and the Azure cloud security assessment guide for Azure scope, evidence requirements, and revalidation.
Can you get ISO 27017 certified, and does your provider's certificate cover you?
ISO/IEC 27017 is not a standalone certification standard, and a cloud provider's ISO 27017 assurance does not extend to its customers.
ISO/IEC 27017 provides guidance rather than management-system requirements. ISO states that certification can only be performed against a document that contains requirements. The SC 27 Journal 2026 further notes that ISO/IEC 27017 and ISO/IEC 27018 are extensions to ISO/IEC 27001 and that certification bodies should not issue separate certificates for those extensions.
Some national conformity schemes may incorporate ISO 27017 requirements differently, so the exact certification language can vary by market. The broader rule remains the same: provider assurance covers the provider's certified scope, not the customer's own cloud implementation.
- AWS states that customers are not automatically certified by association
- Microsoft allows customers to use its ISO 27017 certifications and audit materials in their own assessments, while customer implementations, controls, and processes still require evaluation
Before relying on a provider's ISO 27017 assurance, check:
- Standard and edition cited
- Type of certificate or assurance
- Services included in scope
- Regions or data centers covered
- Validity period
- Available audit documentation
- Customer-side controls outside the provider's scope
Check the edition as well as the certificate. As of August 18, 2026, the public compliance pages for AWS, Microsoft, and Google Cloud still describe ISO/IEC 27017 assurance against the 2015 edition, while ISO lists ISO/IEC 27017:2026 as the current standard.
Keep ISO 27017 evidence current across multi-cloud environments
In a multi-cloud environment, audit evidence loses value quickly when the resource, configuration, owner, or control state behind it changes. Cloudaware can support this evidence layer by connecting multi-cloud inventory, ownership, relationships, compliance findings, change history, and remediation context around the same cloud resource or CI.
Core capabilities:
- Keep assessment scope current: Use a CMDB-backed inventory to maintain AWS, Azure, and Google Cloud resources in the evaluated population as infrastructure is discovered, changed, or retired
- Turn framework requirements into technical checks: Map cloud policies to established frameworks such as ISO/IEC 27001:2022, CIS Benchmarks, NIST CSF, NIST SP 800-53, PCI DSS, and SOC 2
- Evaluate customer-controlled configuration: Check IAM, privileged access, logging, encryption, backup, network, storage, and other cloud settings against defined policies
- Connect every result to the affected resource: Keep policy outputs tied to the evaluated cloud resource, parent account or project, resource type, and application context
- Preserve current-state evidence: Retain references to the specific resource properties and configuration settings used to determine compliance state
- Move findings into remediation: Add remediation guidance to non-compliant policy outputs so teams can move from failed control check to corrective action without losing asset context
- Report with infrastructure context: Use policy outputs to identify non-compliant resources, analyze compliance trends, and build compliance reports that remain tied to the underlying cloud environment
Cloudaware’s role is narrower than the ISMS itself. The organization still defines control applicability, accepts risk, approves exceptions, and determines whether the collected evidence is sufficient for ISO 27017.