ISO 27017 cloud controls for providers and customers

Does ISO 27017 certification apply to my cloud service?

If a customer, contract or tender asks whether your cloud service is ISO 27017 compliant, the accurate answer starts with this: ISO/IEC 27017:2026 is guidance, not a certifiable standard. It adds cloud-specific guidance and additional controls to ISO/IEC 27002 for both cloud service providers and cloud service customers, so no organization is certified to it on its own. Cloud assurance is normally shown through an ISO/IEC 27001 certificate whose scope covers the service, supported by the A.5.23 control on acquiring, using, managing and exiting cloud services, with the 27017 guidance informing how that control and others are implemented.

The answer then depends on your role and on the certificate scope. A provider operating the service should check whether its ISO 27001 scope names the cloud service, the infrastructure behind it and the sites and teams that run it, and whether the 27017 guidance has been used to design the cloud-specific controls. A customer using a cloud service should check its own A.5.23 process, covering provider selection, contract terms, data location, exit and responsibility splits, and should not assume that a provider's certificate covers the customer's own configuration. Many organizations are both, so both checks apply. Confirm with the provider which edition of ISO/IEC 27017 it references, since the 2026 edition replaced ISO/IEC 27017:2015, and ask for the scope statement rather than a general logo or badge.

Ask the provider for three documents before you accept the claim: the current ISO/IEC 27001 certificate and its scope statement, the Statement of Applicability, and any cloud-specific evidence for the services in question. For the 2026 edition itself, which runs to 39 pages and costs CHF 196 from ISO, confirm the purchase with your procurement team, as the edition is a reference for your own control design rather than a document to be certified. Your legal team should also confirm how the provider's responsibilities are divided in the contract, because a certificate describes the provider's management system, not the security of your own data, users and configurations in that service.

Which side of the cloud relationship does ISO 27017 apply to?

Providers that operate a cloud service are the main audience for ISO/IEC 27017. The guidance adds cloud-specific controls on top of ISO/IEC 27002 for the provider's side of the service, including how customer environments are kept apart, how the provider's own staff reach those environments and how the service is operated. The provider builds these controls into its ISMS and shows an assessor how they work in practice, usually during an ISO 27001 certification audit whose scope includes the cloud service.

Tenant separation: Show how one customer's data and workloads are isolated from others on shared infrastructure, and how that isolation is tested.
Provider administrative access: Record which staff can reach customer environments, under what approval, and how those sessions are logged.
Responsibility documentation: Publish a clear split of security duties between the provider and its customers so each side knows which controls it runs.
Service lifecycle and exit: Define how customer data is returned or removed at the end of the service and how the provider manages its own suppliers.
Certificate scope: Name the exact cloud service, locations and platforms covered, since a certificate supports only what the audit tested.

Check that the certificate scope names the specific service and regions a customer buys before relying on it in a tender or contract.

How ISO 27017 fits with ISO 27001 certification and A.5.23

ISO/IEC 27001 is the only standard in this stack that an organization can be certified against. It sets the requirements for an information security management system (ISMS), including the clause 6.1.3 risk treatment step that produces the Statement of Applicability. ISO/IEC 27002 is the control guidance that Annex A draws from, and it cannot itself be certified to. ISO/IEC 27017 sits alongside 27002 as a sector extension: it adds cloud-specific guidance and additional controls for both cloud service customers and cloud service providers. In practice, an auditor tests the ISMS against 27001, uses 27002 and 27017 as the reference for how the cloud controls should work, and asks whether the organization's own cloud decisions are documented and followed. The current edition, ISO/IEC 27017:2026, replaced the 2015 edition, so confirm which edition your certification body expects you to reference.

Control A.5.23 is where cloud use enters the certified ISMS. It asks the organization to establish processes for acquiring, using, managing and exiting cloud services, set in line with its own information security requirements. It is one of the 11 controls that were new in the 2022 revision of Annex A, and it sits in the organizational theme with A.5.7 and A.5.30. Because it is new, many organizations that moved from the 2013 edition are still writing the process from scratch. Each step should name an owner, a set of security requirements for the service, the review points and the exit approach, such as data return and deletion. Keep the evidence for each step: approved requirements, provider due diligence, configuration or contract records and exit plans. An illustrative example: a team that adopts a new managed database service would show who approved it, what security requirements it met, and how its data would be moved out if the contract ended.

What a cloud provider should show to customers

A cloud provider's ISO 27001 certificate proves that an ISMS exists, but it does not by itself show how cloud-specific risks are handled for your workloads. The cards below list the components a customer should ask for and check against the certificate and its scope statement, rather than assume they are covered.

Certificate scope and included services

Confirm which legal entity, regions and services the ISO/IEC 27001 certificate covers. Many providers certify a subset of their platform, so a service you buy may sit outside the scope statement. Check whether the services you depend on are named explicitly, whether the certificate's validity dates are current, and whether a certification body issued it. A certificate that does not name your service does not cover it.

Cloud guidance applied to the service

Ask whether the provider has assessed its service against the cloud-specific guidance in ISO/IEC 27017 and can show how that guidance was applied. Ask for the provider's own statement of how it addresses the cloud controls, mapped to the services in scope. Treat any claim of 27017 coverage as something to confirm against the current edition, since ISO/IEC 27017:2026 replaced the 2015 edition.

Shared responsibility documentation

Request the provider's shared responsibility documentation for each service and read it against your own duties. It should separate what the provider operates, such as physical facilities and hypervisor security, from what you configure, such as identity, encryption keys and network rules. Gaps in this split are where most cloud incidents and audit findings start, so record each customer-side duty as a control in your own ISMS.

Logging and tenant isolation evidence

Ask what log data the provider makes available to you, how long it is retained, and how access to it is controlled. For multi-tenant platforms, ask for evidence of tenant isolation, such as independent testing results or architecture descriptions that you can review. Confirm whether these artifacts come with the certificate or must be requested under a non-disclosure agreement, and whether your auditor will accept them as evidence for controls you rely on.

Supplier and subprocessor controls

Ask for the provider's current list of subprocessors and how it notifies customers of changes. A cloud provider often relies on its own suppliers for data center operations, support or telemetry, and those relationships shape your own supplier risk under Annex A control A.5.19 and related controls. Confirm the notice period for changes and whether you can object or exit if a new subprocessor is unacceptable.

Verifying the certificate independently

Check the certificate through the registry of the accreditation body or the certification body's own verification service, rather than relying on a PDF supplied by the provider. Confirm that the certification body is accredited for ISO/IEC 27001 and that the certificate reference matches the scope statement. Record the date of your check, because certificates can be suspended or withdrawn between audit cycles.

How AWS and Azure show their ISO certifications

The key point for a cloud customer is that a provider's ISO certificate describes the provider's own services inside the scope the certification body audited, not your implementation. AWS states that it holds ISO/IEC 27001:2022, ISO/IEC 27017:2015 and ISO/IEC 27018:2019 certifications, and its FAQs name EY CertifyPoint as the ISO certifying agent that verifies the ISO/IEC 27001:2022 certification. Before you cite any provider certificate in your own evidence, open the certificate itself and check three things: the issuing certification body, the list of in-scope services and regions, and the validity dates. Then confirm the certification body's accreditation through the IAF CertSearch database that ISO points to.

Read the AWS 27017 reference with care. It names the 2015 edition, and ISO/IEC 27017:2026 (edition 2) replaced that edition in July 2026. A reference to the older edition does not automatically mean the provider lacks the current guidance, but it does mean you should not assume the 2026 requirements are covered. Ask the provider in writing whether its 27017 certification has been or will be re-assessed against the 2026 edition, which services are in scope, and when the next audit cycle falls. Record the answer in your supplier file alongside the certificate.

Microsoft takes a similar position but puts more responsibility on the customer. Its guidance says a customer seeking certification for an implementation on in-scope Azure services can use Azure's certifications within its own assessment. The customer, however, still engages an assessor to evaluate its implementation and its own controls and processes. In practice, the provider's certificate supports the inherited parts of your control set, such as physical facilities and parts of the platform, while your own configuration, identity, data handling and exit procedures remain your evidence to produce. Map each Azure-inherited control to a named responsibility in your Statement of Applicability, and confirm the scope of the Azure services you use matches the scope of that certification before the assessor arrives.

What a cloud customer must still do itself

A cloud provider's certificate covers the provider's side of the service. The customer still owns its own information security management system, its choices about which services to use, and the evidence that those choices are controlled. The cards below set out the decisions that no provider certificate can make on the customer's behalf.

Scope the customer's own ISMS

The customer's ISO 27001 scope must name the cloud services, accounts, regions and business units it actually uses, along with the people and data that depend on them. A provider's certificate does not define the customer's boundary. Check whether each cloud workload sits inside your scope or is excluded with a documented reason, because an assessor will test that boundary first. Record the interfaces between your on-premises systems and the cloud.

Apply A.5.23 to each service

Control A.5.23 asks the organization to establish processes for acquiring, using, managing and exiting cloud services in line with its information security requirements. Apply it service by service, not once for the whole cloud estate. For each service, record the security requirements, the approval step, the configuration owner and the review cadence. Ask an assessor how they expect this to be shown before you build the process.

Review provider certificates and scope

Before relying on a provider's certificate, confirm the certificate is current, check which standard edition it names, and confirm which services and regions fall inside the certified scope. Certificates from different editions of the same standard are not interchangeable, so note any gap. Keep a dated record of each review, since an assessor will ask how you knew the provider's controls were in place when you depended on them.

Map shared responsibilities

Each cloud service splits security duties between the provider and the customer, and the split differs by service model. The customer typically owns identity configuration, data classification, encryption choices, logging settings and access reviews. Write a responsibility matrix for each service that shows who performs each control, who evidences it and who is alerted when it fails. Gaps in this matrix are the most common source of findings on the customer side.

Document exit and data return

The customer must plan how it leaves each cloud service before it needs to. Document how data is exported, in which formats, how it is deleted from the provider, and who approves that deletion. Test the export path at least once, because an exit plan that has never been run is hard to defend. Confirm the provider's contractual terms for data return and deletion, and retain the evidence.

How to verify a cloud provider's certification

This sequence lets a customer or procurement team confirm that a cloud provider's ISO 27001 and ISO 27017 claims are issued by an accredited body, cover the services being bought, and can be filed as evidence for Annex A control A.5.23.

Request the certificate and scope statement
Ask the provider in writing for its ISO/IEC 27001 certificate and the accompanying scope statement, and for any ISO/IEC 27017 certificate it cites. The scope statement lists the services, locations and organizational units covered, so it is the document you check the rest of the sequence against. You know this step is done when you hold the current certificate PDF or registry reference and a scope statement that names the services in your contract. If the provider offers only a logo or a marketing claim, treat that as incomplete and keep asking for the certificate.
Confirm the certification body is accredited
Identify the certification body named on the certificate and confirm it is an accredited ISMS certification body. Check that its accreditation covers ISO/IEC 27001 and that it works to ISO/IEC 17021-1 with ISO/IEC 27006-1 applied, the combination IAF MD 29:2024 required all clients to meet by 31 March 2026. Ask the provider or the body directly if the accreditation status is not stated. You know this step is done when you have recorded the certification body's name, its accreditation body and the standards it is accredited to assess against.
Check the certificate in the IAF CertSearch database
Search the certificate in the IAF CertSearch database, which ISO points to for checking accredited certificates. Since 1 January 2026, Global ACI has assumed the roles of IAF and ILAC, so the database and its operator should be checked against the current ISO certification guidance rather than older documents. Match the certificate number, the certified organization, the standard edition and the expiry or validity status against what the provider sent. You know this step is done when the registry shows the certificate as valid and its details match the PDF you received. Save the search date and a screenshot or export.
Confirm the certified services match the services you buy
Compare the scope statement against the services in your contract and order forms. Look for each cloud service you use by name, the regions or data centers that host your data, and any sub-services or managed components it depends on. Note services that are absent or only mentioned in general terms, because they are outside the certified scope even if the provider is certified. Confirm whether an ISO/IEC 27017 certificate or a cloud-specific statement covers the same services. You know this step is done when you have a written mapping of each purchased service to a certified scope line, with gaps listed and sent to the provider for clarification.
Check the 2022 edition and transition status
Confirm the certificate refers to ISO/IEC 27001:2022, not ISO/IEC 27001:2013. Under IAF MD 26:2023, all 2013 certifications had to expire or be withdrawn by 31 October 2025, so a 2013 certificate presented as current is a finding. If the provider cites ISO/IEC 27017, confirm which edition it names, since ISO/IEC 27017:2026 replaced ISO/IEC 27017:2015 and the provider's certificate may still reference the earlier edition during its own transition. You know this step is done when you have recorded the edition on each certificate and raised any gap with the provider in writing.
Request the provider's responsibility matrix
Ask the provider for its shared responsibility documentation for the purchased services, showing which controls it operates and which the customer must operate for its own configuration, access, data classification and exit planning. This is the document that tells you which parts of A.5.23 your organization owns. Remember that a provider's certificate does not transfer your obligations. You know this step is done when you hold a matrix that assigns each relevant control to either the provider or your organization, with the owner named for each line.
File the evidence for A.5.23
Store the certificate, the registry check, the scope mapping, the edition check and the responsibility matrix in your ISMS evidence repository, linked to Annex A control A.5.23 on cloud services and to the supplier entry in your asset or supplier register. A.5.23 asks for processes covering acquisition, use, management and exit from cloud services, so record the owner of each process and the date of review. Confirm with your certification body or assessor which evidence format it expects. You know this step is done when an assessor can trace a purchased cloud service from its contract to its certificate, its scope line and its owner without asking for additional documents.

Mistakes that make cloud assurance fall apart

Cloud assurance usually breaks at the boundary between what the provider certifies and what the customer still runs. The pitfalls below cluster around that boundary, from misread certificates to exit plans that exist only on paper.

Treating the provider's certificate as your certificate

A provider's ISO/IEC 27001 certificate covers the provider's information security management system, not your configurations, identities, data classification or application controls. Your organization still owns its own ISMS scope and its own Statement of Applicability. Before relying on a provider's certificate, map which controls the provider covers and which remain yours, then document that split in your risk treatment plan. An engagement with an independent assessor can test your side of the shared responsibility model.

Assuming the certificate covers every region and service

Certificates name a defined scope, which may cover specific services, accounts, regions or sites. A workload deployed in a region or service outside that scope can run without the assurance your auditor expects. Ask the provider for the exact scope statement, list the services your architecture uses, and check each one against the scope before you sign. Record any gap as a risk with a compensating control or a plan to move the workload.

Citing an outdated 27017 reference

ISO/IEC 27017:2026 replaced ISO/IEC 27017:2015, and older contracts, provider documents and internal policies may still cite the earlier edition. An assessor who sees a 2015 reference in your cloud policy will ask why the cloud controls were not updated. Review every policy, supplier clause and questionnaire answer that names 27017, and update the citation to the current edition. Confirm with the provider which edition its certificate and assessment reference.

Confusing customer and provider duties

ISO/IEC 27017 gives guidance to both cloud service customers and cloud service providers, so each side has different responsibilities. Customers typically own identity management, configuration, data handling and application security, while providers own the platform underneath. Write a responsibility matrix that lists each control, its owner and the evidence that proves it. Without that matrix, gaps tend to appear only during an audit, when neither party can show who was meant to act.

Missing evidence from the provider's side

Customers often hold a certificate and an assurance report but no record of how the provider's controls behave in practice. Ask for the current audit report, the statement of applicability relevant to your services, and notices of material changes. Also confirm how the provider notifies you of incidents and sub-processors. Keep these documents in your evidence register with dates, because a certificate on file from a prior period will not show what the provider does today.

Skipping exit planning

Clause A.5.23 asks for processes covering exit from cloud services, which many organizations write but never test. If a provider changes terms, fails or ends service, you need documented data return, deletion evidence and a tested route to a replacement. Confirm the contractual exit terms, the export formats, and the time needed to move workloads, then rehearse the process at least for the most critical service. A plan that has never run is weak evidence for the control.

Questions about ISO 27017 for cloud services

Is ISO 27017 a certifiable standard?

No. ISO/IEC 27017 is guidance, not a requirements standard, so an organization cannot be certified to it on its own. It gives cloud-specific implementation guidance and additional controls on top of ISO/IEC 27002, for both cloud service customers and cloud service providers, across public, private and hybrid clouds. The certifiable standard is ISO/IEC 27001, and an accredited certification body audits your ISMS against it. ISO 27017 shapes how you implement and evidence the controls in scope, and the certification body uses it as a reference when testing those controls. Confirm with your certification body how it will treat ISO 27017 guidance in your audit plan.

Does a cloud provider's ISO 27001 certificate cover my workloads?

Not automatically. A provider's certificate covers the provider's own management system and the services listed in its certificate scope. Your organization remains responsible for its own ISMS, its configuration of the services it uses, its access management, data handling and the processes it runs on top of the platform. Microsoft's guidance states that a customer seeking certification for an implementation on in-scope services can use Azure's certifications in its assessment, but must still engage an assessor to evaluate its implementation and its own controls and processes. AWS publishes its own ISO/IEC 27001:2022, 27017:2015 and 27018:2019 certification information. Read the scope statement of each provider certificate and map the services you use to it before you rely on it.

What does the 2026 edition of ISO 27017 cost?

ISO lists ISO/IEC 27017:2026 at CHF 196 for the 39-page edition published on 27 July 2026, and that figure is ISO's list price. It replaced ISO/IEC 27017:2015. The standard itself is a one-time purchase, but it is only one cost. Your larger costs are the people who map your cloud services to the controls, the internal time to update the Statement of Applicability and procedures, and the certification body's audit fees, which depend on scope, number of sites and services. Ask your certification body and any implementation partner to quote these separately, and confirm whether your current audit plan references the 2015 or 2026 edition.

Do I need a separate ISO 27017 certificate?

No. ISO 27017 does not issue its own certificate. Cloud-related assurance is delivered through your ISO/IEC 27001 certificate, whose scope statement should name the cloud services in use. Some organizations also pursue CSA STAR certification, which builds on ISO 27001 and adds Cloud Controls Matrix requirements, but that is a separate scheme with its own process. If a customer asks for ISO 27017 specifically, ask whether they mean alignment with the guidance, evidence that your ISMS addresses it, or a certificate that does not exist. Clarify this in writing before you scope the work.

How does ISO 27017 relate to control A.5.23 in ISO 27001?

A.5.23 is the Annex A control on information security for the use of cloud services. It asks your organization to establish processes for acquiring, using, managing and exiting cloud services, in line with your information security requirements. It is one of the 11 controls that were new in the 2022 revision of Annex A. ISO 27017 gives the cloud-specific guidance you use to implement A.5.23, such as shared responsibility between customer and provider, configuration responsibilities and how to handle data at exit. Your evidence for A.5.23 will typically include the cloud service inventory, due diligence records, shared responsibility matrices, exit plans and periodic reviews of each service.

What does the work need from my team?

Your team owns the decisions and the evidence. Expect to name an owner for each cloud service, supply account and configuration information, document who is responsible for each control in the provider's shared responsibility model, and review the Statement of Applicability for cloud-related controls. Engineers usually produce configuration exports, logging and access review evidence. An implementation partner can prepare systems, procedures and evidence collection, but it cannot issue a certificate or decide your risk acceptance. The amount of effort depends on how many cloud accounts and services are in scope and how mature your current change and access processes are, so ask for a written scope and an effort estimate before you commit.

Can we handle ISO 27017 alignment ourselves?

Often yes, if you have a clear cloud inventory, an owner for each service and someone who can run the internal audit and management review. Many organizations start by mapping their cloud services against the guidance in ISO 27017 and the cloud-related controls in ISO 27001, then decide which gaps to close internally. Outside help is most useful when the scope spans several providers, when your shared responsibility records are incomplete, or when the certification body finds nonconformities that need technical remediation. Whatever you decide, the certification body remains independent and must audit your ISMS itself.

Who owns the controls and who issues the assurance

The organization owns its controls and its Statement of Applicability. For a cloud service provider or a cloud service customer, the decision about which ISO/IEC 27017 guidance applies, how cloud controls such as A.5.23 are implemented, and which of them appear in the Statement of Applicability sits with the organization itself. The Statement of Applicability is required by clause 6.1.3 d) of ISO/IEC 27001:2022, so the signed position on each Annex A control, including the justification for exclusions, must be the organization's own work. A cloud provider's certificate covering its platform does not transfer those decisions to a customer, and a customer that inherits a provider's controls still needs to record how it relies on them.

An implementation partner prepares systems and evidence. DeployOpen plans, configures and documents the self-hosted open-source platforms, cloud accounts and supporting processes that the organization operates, and assembles the records an assessor will ask for, such as acquisition and exit procedures for cloud services, access reviews and configuration baselines. That work is delivered under a written, fixed scope. It does not decide which controls the organization adopts, and it does not sign off the organization's Statement of Applicability on the organization's behalf. Ask any partner to confirm in writing which artifacts it produces and which decisions remain with your management.

Only an independent certification body or auditor issues certificates or reports. DeployOpen does not issue audit reports, attestations or certificates, and no implementation work by DeployOpen counts as assurance until an accredited certification body or auditor has assessed it. Before you rely on any claim, confirm that the certification body is accredited, that the certificate's scope includes the cloud services in question, and that the certificate can be checked in the IAF CertSearch database referenced on ISO's certification page. Keep the provider's ISO/IEC 27017 or 27001 evidence separate from your own assessment, because the auditor must still evaluate your implementation.

How DeployOpen prepares cloud evidence for ISO 27001 and 27017 reviews

DeployOpen works on ISO 27017 cloud evidence as an implementation partner: it helps prepare the systems, shared responsibility records and evidence that a cloud service provider or customer presents to an accredited certification body. The organization owns its controls and the certification decision rests with the independent auditor.

How we scope

Each engagement starts with a written scope that names the cloud services, accounts, regions and business units in play.
We map which A.5.23 cloud processes and ISO 27017 cloud-specific controls apply to your provider or customer role.
Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.

How we build

We build or harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
We set up configuration records, access logs and change history so each cloud control produces evidence an assessor can sample.
We run security testing on cloud and infrastructure components to check that the documented controls behave as described.

How we hand over

We document the shared responsibility split between your organization and each cloud provider for every in-scope control.
We deliver the evidence pack, runbooks and control records in a format your internal team and the auditor can follow.
Your organization keeps ownership of the controls, and an independent auditor or certification body issues any report or certificate.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
We can help your team prepare for surveillance reviews by refreshing evidence and checking that configurations still match the Statement of Applicability.
Ask us to confirm in writing which parts of the cloud evidence we prepare and which parts your team or auditor must own.