ISO/IEC 27017

Introduction: ISO/IEC 27017 and Cloud Security Assurance

ISO/IEC 27017:2015 is the international code of practice for information security controls specific to cloud services. It sits inside the ISO/IEC 27000 family and extends the widely adopted ISO/IEC 27002 control set with cloud-specific implementation guidance, plus seven additional controls that address risks unique to the cloud computing model. Unlike a stand-alone certifiable standard, ISO 27017 is designed to be implemented on top of an ISO/IEC 27001 Information Security Management System (ISMS), giving both cloud service providers (CSPs) and cloud service customers a shared, auditable frame of reference for who does what when workloads move to shared, on-demand, elastic infrastructure.

This guide is written for security, risk and compliance leaders who need an auditor-grade understanding of ISO 27017: what it contains, who it applies to, how to structure an assessment, what evidence auditors expect, how to map it against neighbouring frameworks such as ISO 27018, CSA STAR and SOC 2, and how to run an efficient implementation programme. Terminology, control identifiers and clause references throughout follow the actual ISO/IEC 27017:2015 structure so the material can be used directly to scope and drive an engagement.

What is ISO/IEC 27017

ISO/IEC 27017 is titled 'Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services'. It was published in December 2015 jointly by ISO and IEC (and, in parallel, adopted as ITU-T Recommendation X.1631). Its purpose is to make the generic controls of ISO/IEC 27002 usable in a cloud context, where responsibility for security is shared between the provider who operates the platform and the customer who consumes the service.

The standard does two things. First, for a large subset of the ISO/IEC 27002 controls it adds cloud-specific implementation guidance addressed separately to the cloud service customer and to the cloud service provider. Second, it introduces seven brand-new controls, in an extended annex-style structure, that have no direct equivalent in ISO/IEC 27002 because they address risks that only arise in cloud: shared roles and responsibilities, asset removal on contract termination, segregation in virtualised multi-tenant environments, virtual machine hardening, administrator operational security, monitoring of cloud services, and alignment of virtual and physical network security management.

Because it is a 'code of practice', ISO 27017 is guidance rather than a set of shall-requirements. Organisations typically demonstrate conformance by extending an ISO/IEC 27001 certification scope to include ISO 27017 controls, and having a certification body (or an assessment such as CSA STAR) attest that the cloud-specific guidance and the seven additional controls have been considered and, where applicable, implemented. It is therefore an assurance and trust instrument: it lets a cloud customer ask a provider a consistent set of questions, and lets a provider evidence a mature, cloud-aware security posture.

Key terminology

Who must comply with ISO 27017

ISO 27017 is voluntary, but it becomes effectively mandatory through customer contracts, tender requirements and regulatory expectations in cloud-heavy sectors. It applies to any organisation that provides or consumes cloud services and needs to demonstrate cloud-specific security governance. Both sides of the cloud relationship are in scope, which is a defining feature of the standard.

• Organisations already certified to ISO/IEC 27001 that want to extend assurance to cloud-specific risk.
• Providers responding to RFPs where ISO 27017 conformance is a scored or gating requirement.
• Customers needing to define and evidence their portion of the shared-responsibility model.
• Any party contractually bound to a cloud service agreement that references ISO 27017 controls.

Structure of ISO/IEC 27017

ISO 27017 mirrors the clause structure of ISO/IEC 27002:2013. It walks through the same fourteen security control domains (clauses 5 to 18) and, for the relevant controls in each domain, adds cloud implementation guidance for customer and provider. It then adds an extended set of seven additional controls, numbered CLD.6.3.1, CLD.8.1.5, CLD.9.5.1, CLD.9.5.2, CLD.12.1.5, CLD.12.4.5 and CLD.13.1.4. The table below summarises the domains and the location of the cloud-specific extensions.

The seven additional cloud controls (CLD)

Master assessment checklist

This is the core working section. It enumerates every control domain of ISO 27017 together with the seven additional cloud controls, and for each provides what an assessor should verify and the typical evidence expected. Where a control area is primarily a shared responsibility, the verification questions cover both the cloud service provider and the cloud service customer perspective. Use these tables directly as your fieldwork worksheet.

Domain 5 - Information security policies (clause 5)

Domain 6 - Organization of information security, incl. CLD.6.3.1 (clause 6)

Domain 7 - Human resource security (clause 7)

Domain 8 - Asset management, incl. CLD.8.1.5 (clause 8)

Domain 9 - Access control, incl. CLD.9.5.1 and CLD.9.5.2 (clause 9)

Domain 10 - Cryptography (clause 10)

Domain 11 - Physical and environmental security (clause 11)

Domain 12 - Operations security, incl. CLD.12.1.5 and CLD.12.4.5 (clause 12)

Domain 13 - Communications security, incl. CLD.13.1.4 (clause 13)

Domain 14 - System acquisition, development and maintenance (clause 14)

Domain 15 - Supplier relationships (clause 15)

Domain 16 - Information security incident management (clause 16)

Domain 17 - Information security aspects of business continuity (clause 17)

Domain 18 - Compliance (clause 18)

Scoping the ISO 27017 assessment

Scoping determines which cloud services, environments and shared-responsibility boundaries are covered. Because ISO 27017 is applied on top of an ISO 27001 ISMS, the scope should align with, or be a clearly defined extension of, the existing ISMS scope. A precise scope prevents both under-coverage (missing a shadow-IT SaaS estate) and over-coverage (assessing provider-owned controls the customer cannot influence).

• Identify the cloud service models in use (IaaS, PaaS, SaaS) as responsibilities differ sharply between them.
• Enumerate in-scope cloud services, providers and the data types they process or store.
• Define the shared-responsibility boundary for each service so controls are attributed to CSP or CSC correctly.
• Include management planes, IAM/SSO, key management and monitoring tooling in scope.
• Document geographic regions and data residency constraints affecting scope.
• State exclusions explicitly (e.g. controls owned entirely by the provider) with justification.
• Confirm alignment with the underlying ISO 27001 Statement of Applicability.

Implementation approach

A pragmatic ISO 27017 programme runs in five phases. Each phase produces defined deliverables that build toward a certifiable or attestable posture layered on the existing ISMS.

Phase 1 - Initiation and cloud context

• Activities: secure sponsorship, define objectives, confirm ISO 27001 baseline, catalogue cloud services and providers, map service models.
• Deliverables: programme charter; cloud service inventory; provider list; high-level scope statement.

Phase 2 - Gap assessment and risk

• Activities: assess current state against all ISO 27017 domains and the seven CLD controls; run cloud risk assessment; attribute controls via shared-responsibility model.
• Deliverables: gap analysis report; cloud risk register; shared-responsibility matrix; prioritised remediation backlog.

Phase 3 - Control design and remediation

• Activities: design/update policies and procedures; implement segregation, VM hardening, admin security, monitoring; assign key management; harden IAM and encryption.
• Deliverables: updated cloud security policies; hardening baselines; monitoring configuration; updated Statement of Applicability referencing CLD controls.

Phase 4 - Operationalisation and evidence

• Activities: embed controls into BAU; run internal audit; collect evidence; conduct awareness training; test backups and continuity.
• Deliverables: internal audit report; evidence repository; training records; corrective action log.

Phase 5 - Certification / attestation and continual improvement

• Activities: engage certification body or STAR assessor; support Stage 1/Stage 2 audits; close findings; establish continual monitoring.
• Deliverables: certification or attestation; nonconformity closure records; continual improvement plan; management review outputs.

Maturity and capability model

While ISO 27017 itself does not mandate a maturity model, assessors commonly rate each control area on a capability scale to communicate progress and prioritise remediation. A five-level model aligned to common practice is shown below.

Assessment and audit approach

1. Confirm the ISO 27001 ISMS baseline is in place and current, as ISO 27017 extends it.
2. Agree scope: cloud services, service models, providers, regions and shared-responsibility boundaries.
3. Review documentation: cloud policies, shared-responsibility matrix, Statement of Applicability, risk register.
4. Conduct a Stage 1 readiness review to confirm design of all domains and the seven CLD controls.
5. Perform Stage 2 fieldwork: test operating effectiveness through interviews, configuration review and evidence sampling.
6. Assess provider-owned controls via attestations (ISO 27001/27017, SOC 2, CSA STAR) where the customer cannot test directly.
7. Record findings and nonconformities with severity ratings and evidence references.
8. Agree corrective actions and timelines; verify closure of major nonconformities.
9. Issue the assessment report or recommend certification/attestation.
10. Establish surveillance and continual monitoring for the certification cycle.

Evidence request list

Assemble the following evidence, organised by category, to support an efficient assessment.

• Governance: cloud security policy, shared-responsibility matrix, Statement of Applicability, management review minutes.
• Risk: cloud risk assessment methodology, cloud risk register, risk treatment plan.
• Identity and access: IAM/SSO configuration, privileged access list, MFA enforcement evidence, access recertification reports.
• Asset and data: cloud asset register, data classification scheme, asset removal/offboarding procedure (CLD.8.1.5).
• Segregation and hardening: multi-tenancy/isolation architecture (CLD.9.5.1), VM hardening baselines and scan results (CLD.9.5.2).
• Operations: admin operational security procedures (CLD.12.1.5), monitoring dashboards and CSC log access (CLD.12.4.5), backup and restore tests.
• Cryptography: crypto policy, key management plan, KMS/HSM logs, encryption configuration.
• Network: virtual and physical network alignment records (CLD.13.1.4), firewall/security-group rules, network diagrams.
• Supplier and continuity: cloud service agreements and SLAs, provider attestations, BCP/DR plans and test reports.
• Incident and compliance: incident response plan with provider escalation, legal/regulatory register, data residency evidence, audit reports.

Roles and responsibilities

KPIs to track

• Percentage of in-scope cloud services covered by the shared-responsibility matrix.
• Percentage of virtual machines compliant with hardening baselines (CLD.9.5.2).
• MFA coverage for privileged and administrative cloud accounts.
• Number of tenant segregation tests passed versus performed (CLD.9.5.1).
• Percentage of cloud services with monitoring and CSC-accessible logging enabled (CLD.12.4.5).
• Mean time to detect and respond to cloud security incidents.
• Percentage of privileged access reviews completed on schedule.
• Backup restore test success rate and continuity exercise pass rate.
• Number of open nonconformities by severity and average time to closure.
• Percentage of providers with current ISO 27001/27017 or equivalent attestation on file.

Readiness checklist

• ISO 27001 ISMS is certified or operational and current.
• Cloud service inventory and service models are documented.
• Shared-responsibility matrix is agreed for every in-scope service (CLD.6.3.1).
• Cloud-specific policies are approved and communicated.
• Cloud risk assessment and treatment plan are complete.
• Asset removal/offboarding procedure is defined and tested (CLD.8.1.5).
• Tenant segregation design is documented and verified (CLD.9.5.1).
• VM hardening baselines are applied and scanned (CLD.9.5.2).
• Administrator operational security controls are enforced (CLD.12.1.5).
• Cloud monitoring and CSC log access are enabled (CLD.12.4.5).
• Virtual and physical network security management are aligned (CLD.13.1.4).
• Key management responsibilities are assigned and encryption is applied.
• Provider attestations are collected and reviewed.
• Internal audit completed and major findings closed.
• Statement of Applicability updated to reference ISO 27017 and CLD controls.

Common gaps

• Undefined or ambiguous shared-responsibility boundaries, leaving controls owned by no one.
• Assuming the provider's certification covers customer-side configuration responsibilities.
• Weak or absent MFA and privileged access controls on cloud management planes.
• Inconsistent VM hardening and drift from baselines over time (CLD.9.5.2).
• Insufficient tenant segregation verification in multi-tenant designs (CLD.9.5.1).
• Limited monitoring visibility because provider logs and telemetry are not enabled or accessed (CLD.12.4.5).
• Unclear key management ownership, especially with BYOK/HYOK arrangements.
• No tested procedure for secure asset return or deletion at contract termination (CLD.8.1.5).
• Misaligned virtual and physical network security policies (CLD.13.1.4).
• Ignoring data residency and cross-border transfer obligations.
• Statement of Applicability not updated to include the seven CLD controls.
• Incident response plans that omit provider escalation and cloud evidence collection.

ISO 27017 mapped to other frameworks

Frequently asked questions

Need help with ISO 27017?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.