ISO 27018 for PII in public clouds: what it covers

Does a cloud provider's ISO 27018 claim protect our PII?

ISO/IEC 27018:2025 is the guidance for protecting personally identifiable information (PII) in public clouds where the cloud provider acts as a PII processor. A provider's ISO 27018 claim describes how that provider handles PII within the scope it has defined, but it does not discharge your own duties as the PII controller, and it does not tell you that your specific data is protected. When a customer or regulator asks how personal data is protected in a public cloud, the honest answer starts with two questions: which services and locations are inside the provider's certified scope, and which privacy obligations remain with your organization. The edition in force is ISO/IEC 27018:2025 (edition 3, 35 pages, published 26 August 2025), which replaced ISO/IEC 27018:2019. Confirm which edition your provider cites, because an older certificate may refer to the superseded text.

The answer differs for every organization because three things vary: the provider's certification scope, your role under the relevant privacy law, and the contract between you. A provider may hold a certificate covering some regions or services but not others, so list the services you actually use and check them against the certificate's scope statement. Your role matters because the provider's processor duties sit alongside your controller duties, such as deciding purposes, responding to data subject requests and managing breach notification. The contract must then state who does what, including how the provider supports you with those duties, where data is stored, and what evidence you can request. Ask for the current certificate and statement of applicability, verify the certificate through the registry linked from the provider's own compliance pages, and record the gaps you must cover with your own controls.

How ISO 27018 fits with ISO 27001, 27017 and 27701

ISO/IEC 27018 is a PII-protection control set that sits on top of ISO/IEC 27002, not a standalone certification. The other three standards each cover a different layer: the certifiable management system, the control guidance and the cloud or privacy extensions. Knowing which one a provider's certificate actually names is the first check a cloud customer should make.

ISO 27001: the certifiable ISMS

ISO/IEC 27001:2022 is the only standard in this group that an accredited certification body can certify. It requires an information security management system covering clauses 4 to 10 and the Annex A controls. A provider's ISO 27001 certificate shows that its management system was audited, but it does not by itself prove that PII handling meets ISO 27018. Ask which scope the certificate covers, including whether the cloud services in your contract fall inside it.

ISO 27002: control guidance

ISO/IEC 27002:2022 explains the purpose and implementation of the controls that ISO 27001 Annex A draws from. It is guidance, and ISO states that it cannot be certified to. ISO/IEC 27018 builds on it, so a provider's PII controls are usually described against 27002 wording. When reviewing a provider's documentation, check that its PII control descriptions trace back to 27002 themes such as access, cryptography and supplier relationships, rather than accepting a generic security policy.

ISO 27017:2026: cloud-specific controls

ISO/IEC 27017:2026 adds cloud-specific guidance and additional controls to ISO/IEC 27002 for both cloud service customers and cloud service providers, across public, private and hybrid clouds. It replaced ISO/IEC 27017:2015. It answers questions such as who manages configuration, logging and tenant isolation. Where a provider holds both 27017 and 27018 claims, confirm the edition named in the certificate or report, because a 2015 reference is not the same as the 2026 edition.

ISO 27701:2025: privacy management

ISO/IEC 27701:2025 sets requirements for a privacy information management system for PII controllers and processors. It replaced the 2019 edition, which is withdrawn, and ISO describes the 2025 edition as usable as a standalone management system standard. A cloud provider may hold 27701 alongside 27018, which covers its processor role. Ask whether the provider's privacy certificate names the 2025 edition and whether it covers processor obligations in your contract.

What a provider's ISO 27018 claim gives a customer

A provider's ISO/IEC 27018 certification tells you that an independent certification body assessed the provider's controls for protecting personal data it handles as a PII processor, within the scope stated on the certificate. It is evidence about the provider's side of the shared model. It does not mean your workloads are compliant, and it does not make you certified.

What it supports: Evidence that the provider's documented PII processing controls, such as handling of customer data, return and deletion practices and disclosure rules, were tested against the standard within the certified scope.
What it does not cover: Your own configuration, such as storage permissions, encryption settings, logging and network exposure, which remain your responsibility.
Data classification: Deciding which of your records are personal data, and how sensitive they are, is your task. The provider cannot do it for you.
Your own certification: AWS states that customers are not automatically certified because they use AWS. Your own ISO/IEC 27001 certification still needs its own scope, risk assessment and audit.
Where it helps: AWS notes that organizations pursuing their own ISO/IEC 27001:2022 certification while running IT on AWS may find that AWS's certification makes theirs easier, because the inherited provider controls are already independently tested.

Before relying on the claim, confirm the certificate, its scope and its validity through the accredited registry, and check that the scope covers the services you use.

How to verify a cloud provider's ISO 27018 certificate

Start by confirming what the certificate actually says. Ask the provider for the certificate and check that it names ISO/IEC 27018 and the edition it was issued against. Editions matter here: ISO/IEC 27018:2025 replaced ISO/IEC 27018:2019, so a certificate or report that cites only the older edition tells you the provider has not yet been assessed against the current text. Then read the scope. The scope should list the cloud services, the regions or data centers, and the sites covered. A certificate that covers the provider's corporate offices but not the service you plan to use is not evidence for your workload. Ask whether the services you depend on, including backups, support tooling and any sub-processors that touch personal data, sit inside the scope.

Next, confirm that the certification body is accredited and that the certificate is current. Accredited ISMS certification bodies work to ISO/IEC 17021-1 together with ISO/IEC 27006-1, and ISO still points to the IAF CertSearch database for checking accredited certificates, even though Global ACI has assumed the IAF and ILAC roles since 1 January 2026. Search the database yourself rather than relying on a PDF supplied by the provider. Under ISO/IEC 17021-1, a certification cycle lasts three years with at least one audit, surveillance or recertification, in every calendar year. Ask the provider where it stands in the current cycle, when the last audit took place and when the next one is due, so you know whether the certificate reflects recent scrutiny.

An implementation partner can help you turn the provider's claim into a view of your own risks, for example by mapping which personal data your workloads send to the cloud and which of your obligations depend on the provider's controls. That work is useful, but it cannot replace the check. Only the certification body can confirm a certificate's validity, and only the provider can supply evidence of its own operation. Record the certificate number, scope, edition and check date in your supplier file, and set a reminder to repeat the search before each annual review.

What customers still have to own

A provider's ISO 27018 claim covers the provider's side of the processing relationship. The cards below cover what the customer still has to decide, configure and evidence, because a cloud provider cannot know which PII a customer holds, why it is processed, or how long the customer wants to keep it.

Documented instructions to the processor

ISO 27018 expects the provider to process PII only on the customer's documented instructions. The customer owns those instructions, so it must write down which processing it authorizes, for which purposes and through which services. Check that the contract, service configuration and internal records describe the same processing, and keep dated versions of any changes the customer requests.

PII inventory and data flows

A provider can describe its own systems but cannot list the personal data a customer loads into them. The customer owns a current inventory of PII categories, data subjects, storage locations and the flows between applications, regions and third parties. Evidence is a data map that reconciles with cloud resource inventories and is reviewed when new services are added.

Customer-side access and encryption configuration

Access control and encryption keys are often set by the customer's own administrators, not by the provider. The customer owns who may reach PII stores, how privileged roles are granted and reviewed, and who controls encryption keys. Evidence includes identity configuration exports, key policies, and access review records that show the settings in effect, not only the intended ones.

Sub-processor and transfer review

When a provider uses sub-processors or stores PII outside the customer's chosen regions, the customer still needs to assess the risk to its own data and obligations. The customer owns the review of the provider's sub-processor list, change notifications and transfer mechanisms, and its decision to accept or object. Keep dated records of each review and the decision reached.

Incident and breach notification contracts

Notification duties to regulators and data subjects usually fall on the customer as controller, and clocks start when the customer is informed. The customer owns the contract terms that set how and when the provider reports incidents, the named contacts, and the internal escalation path. Check that these terms match the customer's own notification deadlines and that the contacts are tested.

Retention and deletion settings

A provider can delete data on request, but retention periods and deletion triggers are business and legal decisions the customer makes. The customer owns retention schedules, the configuration of backups and snapshots, and the verification that deleted PII is removed from replicas and backups within the agreed process. Evidence is the retention schedule, configuration records and deletion logs.

How a customer checks a PII processing claim in practice

The sequence below lets a cloud customer test whether a provider's ISO 27018 claim covers the personal data the customer actually sends to that provider, and records what remains for the customer to handle in its own controls and contracts.

Collect the provider's certificate and scope evidence
Start by obtaining the provider's current certificate, the certification body that issued it, and the scope statement that names the services and locations covered. For AWS, the compliance FAQs state that its ISO/IEC 27018 certification is held alongside its ISO/IEC 27001:2022 and ISO/IEC 27017 certifications, so confirm each one separately rather than assuming they share a scope. Confirm the certificate is current through the accreditation-backed registry the provider names. This step is complete when the file holds the certificate, its scope, its validity dates and the certification body's verification record, and the customer knows which edition of ISO/IEC 27018 the certificate refers to.
Request the statement of applicability and scope evidence
Ask the provider for the statement of applicability for its ISO/IEC 27001 scope and any ISO/IEC 27018 control statements it can share under confidentiality. The customer should be looking for which controls are stated as applicable, which are excluded and why, and whether the provider describes its role as a PII processor for its public cloud services. Where a provider will not share the full document, ask for the non-confidential summary and written confirmation of the services in scope. The output is a short scope note that lists the provider services the customer uses and whether each one appears in the certified scope.
Map the provider claim to your PII records
Using the customer's own record of processing activities, list every category of personal data that is sent to, stored in or accessed through the provider's services. For each category, record the provider service, the region where it is stored, the people or systems that access it and the reason the provider processes it. Compare this map against the services and regions in the provider's scope note. The output is a mapping table with one row per data flow, and a column marking each row as covered, partly covered, outside the certified scope or unknown. Rows marked unknown become the questions for the provider.
Identify gaps against your own obligations
Next, compare the mapping table against what the customer itself must do as a PII controller under its ISO/IEC 27701 or ISO/IEC 27001 obligations, and under any privacy law that applies. A provider's ISO/IEC 27018 claim covers the provider's processor controls. It does not cover the customer's choice of configuration, its access management, its retention settings, its records of instructions given to the provider or its own transfer assessments. For each row, note which obligations the provider's controls satisfy, which remain with the customer and which are unclear. The output is a gap register with an owner and a proposed action for every open item.
Agree contract terms for each gap
Turn the open items in the gap register into contract points. Typical items to raise include the provider's commitment to process personal data only on the customer's documented instructions, notification of changes to sub-processors or locations, deletion or return of data at the end of the service, audit or assessment rights, and the process for reporting incidents affecting personal data. Confirm each term against the provider's actual data processing agreement and its published commitments, since the customer cannot rely on the certificate alone to prove a contract term. The output is a list of agreed clauses, or documented reasons why a gap is accepted, signed off by the customer's privacy and security owners.
Record the decision and set review triggers
Write a decision record that states which provider services are approved for which categories of personal data, the evidence relied on, the gaps accepted and the owner of each accepted gap. Name the events that should prompt a fresh check, such as a new certificate issue, a change in the provider's certified scope, a new service or region, a change to the customer's data categories, or a material change to the provider's sub-processors. Store the decision record with the ISMS documentation so that an auditor testing the customer's supplier controls can trace the check from certificate to decision. The output is a dated, approved record and a review calendar set by the customer's own policy.

Questions buyers ask about ISO 27018 in public clouds

Is ISO 27018 a certification that a cloud provider can get?

ISO/IEC 27018 is a set of guidelines for protecting personally identifiable information (PII) in public clouds where the provider acts as a PII processor. The current edition is ISO/IEC 27018:2025, published 26 August 2025, and it builds on ISO/IEC 27002. Providers are normally assessed for their information security management system through ISO/IEC 27001 certification, and the 27018 guidance shapes which PII controls the auditor examines. Some providers show a separate ISO/IEC 27018 certificate. AWS lists one, for example, although its FAQs refer to the 2019 edition. Before relying on any such certificate, ask the issuing certification body which scheme it was issued under, the scope, and the edition named on it.

Does a cloud provider need ISO 27018 on top of ISO 27001?

No general rule makes ISO 27018 mandatory alongside ISO 27001. The requirement comes from the contract, the customer's regulator or the customer's own supplier policy. ISO 27001 certifies the management system for the whole organization, while ISO 27018 adds guidance specific to personal data in public cloud services. A provider that processes PII for customers will often be asked for both, and the buyer should confirm that the provider's certificate scope covers the cloud service being purchased. If the customer is itself a PII controller that needs a privacy management system, ISO/IEC 27701:2025 is the separate standard built for that role, and it can be used alongside ISO 27001 and ISO 27018.

How much does it cost to buy the ISO 27018 standard?

ISO sells ISO/IEC 27018:2025 for CHF 179, according to the ISO committee page for the standard. That covers the 35-page document only. ISO also sells a bundle of ISO/IEC 27701:2025, ISO/IEC 27018:2025 and ISO/IEC 27001:2022 for CHF 486. The price of the text is the smallest cost in a certification project. The larger costs are the accredited certification audit, internal staff time to build and run the controls, the evidence collection, and any outside help. Those costs depend on the scope, the number of sites and services, and how mature the provider's controls already are. Ask every quote to show these items separately, and ask whether the provider's purchase of the standard is included or billed on its own.

How long does a cloud provider's certificate cycle last?

Accredited management system certification under ISO/IEC 17021-1 runs on a three-year cycle, with at least one audit in every calendar year. That audit is either a surveillance audit or the recertification audit. Where a provider's ISO 27018 status is shown through its ISO 27001 certificate, the ISO 27001 cycle governs the expiry date. Certification bodies also apply the transition rules that ISO and the International Accreditation Forum (IAF) set for each edition, so a provider certified to an older edition may need to move to the current one within a set period. Check the expiry date on the certificate, confirm the body is accredited, and ask the provider for its transition plan if the certificate names an older edition.

Can DeployOpen certify or verify a cloud provider for ISO 27018?

No. DeployOpen is an implementation partner. It plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, and it helps prepare systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it cannot verify another company's certificate. Only an independent auditor or an accredited certification body can do that. To check a provider's certificate, look up the accredited certificate in the IAF CertSearch database, which the ISO certification page points to, and confirm the scope and edition with the certification body. A customer that wants help documenting how its own self-hosted platform handles PII can ask DeployOpen to prepare that evidence for its own auditor.

What must a cloud customer give an independent auditor?

A cloud customer's own auditor tests the customer's controls, not the provider's, so the customer must supply its own evidence. AWS states that customers are not automatically certified because they use AWS, although a provider's certificate can make a customer's own certification easier. Typical material includes the customer's ISMS scope and the cloud services inside it, an inventory of data and PII processing, the customer's cloud configuration and access records, and records showing that the provider's certificate, scope and any statement of applicability were reviewed as part of supplier management. The customer should also document the split of responsibilities between itself and the provider. The customer owns this evidence, and its quality depends on what the customer has actually configured and reviewed.

What should a buyer check in a provider's ISO 27018 claim?

A useful check covers four things. First, confirm the certificate was issued by an accredited certification body, and look it up in the IAF CertSearch database. Second, read the scope to see whether it names the cloud services, regions and data centers you will use. Third, note the edition, because ISO/IEC 27018:2025 replaced ISO/IEC 27018:2019, and a certificate that names the older edition needs a clear transition explanation. Fourth, confirm the provider's role. ISO 27018 applies where the provider acts as a PII processor, so the provider's contract should describe how it processes your personal data and how it supports your duties under your own privacy rules. Put these checks into your supplier assessment and record the answers, since they will be requested during your own audit.

Where an implementation partner helps with cloud PII evidence

An implementation partner helps with the technical and documentary side of PII protection in a cloud environment, and it does not take over the obligations. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own cloud accounts or data centers, so the data, keys and logs stay under the client's control. For a PII processor, that work can include configuring access roles, logging, retention and encryption settings, and writing down how personal data is handled across the platform. The organization still owns its controls, decides which of them apply to its processing, and answers for them to its customers and assessors.

The evidence an assessor will ask for is usually concrete: exported configuration files, infrastructure-as-code repositories, access review records, log samples, backup and deletion procedures, and a clear description of which sub-processors touch customer PII. An implementation partner can prepare these artifacts so they are consistent with each other and with the stated scope. DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor or certification body can assess the controls and issue a conclusion, so the partner's role ends at making the evidence accurate, reproducible and easy to review.

Before any work starts, agree the scope in writing. Engagements are fixed-scope, and the written scope should name the systems, the cloud accounts or data centers, the controls being prepared, the evidence to be delivered and the handover format. Ask the partner to state which controls it will not touch, such as contractual terms, customer notification duties or staff training records. Confirm with your certification body or assessor, before the engagement begins, what evidence format they expect for cloud PII controls. A quote follows from that written scope, so the more precisely the evidence list is defined, the more accurately the work can be priced.

How DeployOpen scopes and prepares PII evidence for cloud customers

DeployOpen works on ISO 27018 for protecting PII in public clouds as an implementation partner. We help cloud customers and providers set up the self-hosted systems, configuration and records that show how personal data is handled, while the organization owns its controls and an independent certification body issues any certificate.

How we scope

The written scope names which PII processing, cloud services and hosting environments the evidence must cover.
We confirm which responsibilities sit with the organization and which sit with the cloud provider under its own ISO 27018 claim.
Scope, deliverables and timelines are agreed in writing before any work starts, as engagements are fixed-scope.

How we build

We configure self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
We set up access controls, logging, retention and deletion settings that match the PII handling rules agreed in scope.
Security testing of applications, APIs and cloud infrastructure can be run against the controls before evidence is collected.

How we hand over

You receive documentation of configurations, control records and evidence mapped to the agreed scope.
Runbooks explain how your team collects and refreshes evidence for an independent auditor or certification body.
We do not issue audit reports, attestations or certificates; independent auditors and certification bodies do that work.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover changes to PII processing, new cloud services and updates to the evidence set between audits.
Ask your certification body or auditor to confirm which evidence they expect before the engagement starts.

ISO 27018 for protecting PII in public clouds