ISO/IEC 27018: ISO/IEC 27018 – Tutorial (about 60 minutes)

ISO/IEC 27018 is an international code of practice that tells public cloud providers how to protect the personal data their customers entrust to them. Cloud and SaaS providers use it to shape their privacy controls and contracts, and their customers use it to judge whether a provider can be trusted with personal data. After this tutorial you will be able to explain what the standard covers, read its structure, apply its main controls to a real cloud service and understand how providers demonstrate conformity.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 27018:2025, the third edition, published on 26 August 2025 by ISO and IEC through their joint subcommittee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection). Its full title is "Information security, cybersecurity and privacy protection – Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors". It replaces and withdraws ISO/IEC 27018:2019 (which had itself replaced the 2014 first edition). ISO describes the 2025 edition as aligned with ISO/IEC 27002:2022 and as adding a new Annex B with extended implementation guidance. The edition is current (stage 60.60, International Standard published) and the 2019 edition is listed as withdrawn. Many provider certificates and web pages still cite the 2019 edition, because certification bodies move their audits to a new edition over time. Verified 2026-10-29 on the ISO catalogue and the IEC Webstore.

Who this is for: engineers, product owners and security staff at cloud and SaaS companies that store or process personal data for business customers; privacy, procurement and vendor-risk staff who evaluate cloud providers; and auditors or consultants meeting ISO/IEC 27018 for the first time. It is also useful if you already know ISO/IEC 27001 and want to understand what the "27018" line on a provider's certificate actually means.

Prerequisites: none. A general idea of what cloud computing and personal data are will help, but every term is explained when it first appears. You do not need a copy of the standard to follow this tutorial; anyone implementing it should buy one from ISO, IEC or a national standards body, because standards text is copyrighted and this course paraphrases it.

By the end of this tutorial:

You will be able to explain why ISO/IEC 27018 exists, which organisations it targets and what its scope leaves out.
You will be able to use the key vocabulary correctly, especially PII, PII principal, PII controller, PII processor, cloud service customer and cloud service provider.
You will be able to describe how the standard is built on ISO/IEC 27002 and ISO/IEC 29100, and what its annexes contain.
You will be able to apply its main protections: processing only on instructions, no secondary commercial use, transparency about sub-processors and locations, disclosure handling, breach notification, and return or deletion at the end of a contract.
You will be able to explain how conformity is assessed and why there is no stand-alone ISO/IEC 27018 management system certificate.
You will be able to walk through a realistic implementation for a SaaS provider and compare ISO/IEC 27018 with ISO/IEC 27001, 27002, 27017, 27701 and the GDPR.

Lesson 1 – Origins, purpose and scope

The trust problem in public cloud

When a company moves its payroll, customer support or HR system to a software-as-a-service (SaaS) product, the personal data of its employees and customers moves too. The company still answers to those people and to regulators for how their data is handled, yet it no longer runs the servers, cannot walk into the data centre and often cannot inspect the provider's operations. It has to rely on promises in a contract and on whatever evidence the provider is willing to share.

In the early 2010s, this created real uncertainty. Customers asked questions such as: Will the provider look at our data or use it to train its own products? Will our data be used for advertising? In which countries will it be stored? Who are the provider's subcontractors? What happens if a police force or a foreign government demands our data? Will we be told about a breach? Can we get all our data back and have it deleted when we leave? Every provider answered differently, and each customer had to negotiate from scratch.

ISO/IEC 27018 was written to give everyone a common answer. It sets out an agreed set of protections that a public cloud provider acting on behalf of its customers should have in place. A provider that follows it can show customers, in a recognised format, that their personal data will be handled in a predictable and accountable way. Customers, in turn, can ask a simple question in procurement ("Do you follow ISO/IEC 27018, and is that covered by an independent audit?") instead of writing a hundred custom questions.

Three editions

The first edition was published in 2014. It was built on the 2013 edition of ISO/IEC 27002, the general catalogue of information security controls, and on ISO/IEC 29100, the privacy framework that defines the main privacy roles and principles. Large providers adopted it quickly, and it became a common item on cloud compliance pages. A second edition followed in 2019, still based on the 2013 controls catalogue.

When ISO/IEC 27002 was completely reorganised in 2022, the cloud privacy guidance no longer lined up with the controls it was meant to extend. The third edition, ISO/IEC 27018:2025, restores that alignment with ISO/IEC 27002:2022 and adds a new annex of extended implementation guidance. The subject and the core protections are the same as before; what changed is how the guidance is organised and attached to the underlying controls.

Scope in plain words

The standard provides control objectives, controls and implementation guidance for protecting PII in public cloud computing, in line with the privacy principles of ISO/IEC 29100. Its main audience is any organisation, of any type or size, that provides public cloud services and processes PII as a processor under contract to other organisations. It also takes into account the kinds of legal and regulatory requirements that may apply to such providers. ISO notes that the guidance may also be relevant to organisations that act as PII controllers, because a controller choosing a cloud provider needs to know what to expect from it.

Several things are outside the scope, and confusing them causes many misunderstandings:

It is about public cloud processors. Private clouds and traditional outsourcing can borrow its ideas, but they are not its target.
It is about the provider acting as a processor. When a provider decides on its own what to do with personal data (for example, its marketing list or the accounts of individual consumers using a free service it controls), it is a controller for that data, and the standard does not cover its controller duties.
It is guidance, not a set of auditable requirements on its own. It does not contain a management system; it assumes one exists, usually an ISO/IEC 27001 information security management system.
It is not a law and does not replace the GDPR, India's Digital Personal Data Protection Act or any other regulation. Following it helps a provider meet processor obligations found in many laws, but it does not prove legal compliance.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 27018 combines privacy vocabulary from ISO/IEC 29100 with cloud vocabulary from the ISO/IEC cloud computing standards. The definitions below are paraphrased.

PII (personally identifiable information) – any information that can be used to identify the person it relates to, or that is or might be directly or indirectly linked to that person. It corresponds broadly to "personal data" in the GDPR. Names, email addresses, employee numbers, IP addresses and payroll records are typical examples.
PII principal – the natural person to whom the PII relates, called the "data subject" in the GDPR. In a cloud HR system, the employees whose records are stored are the PII principals.
PII controller – the party that decides why PII is processed and how (the purposes and means). In most business cloud services the customer organisation is the controller.
PII processor – a party that processes PII on behalf of, and following the instructions of, a PII controller. A cloud provider running a service for business customers is usually a processor for the customer data inside that service.
Public cloud PII processor – the standard's name for its target: a public cloud service provider acting as a PII processor.
Sub-processor (sub-contracted PII processor) – another organisation that the provider engages to perform part of the processing, such as an infrastructure provider hosting a SaaS product or an outsourced support desk.
Cloud service customer – the party in a business relationship with the provider for the purpose of using cloud services. The customer is the one that signs the contract and gives instructions.
Cloud service provider – the party that makes cloud services available. In ISO/IEC 27018 the provider is the processor.
Public cloud – a deployment model in which cloud services are potentially available to any customer, and resources are controlled by the provider. Many unrelated customers share the same infrastructure.
Multi-tenancy – the allocation of shared physical and virtual resources to several customers (tenants) so that their computation and data are isolated from and inaccessible to one another.
Processing of PII – any operation on PII, including collection, storage, alteration, retrieval, disclosure, transfer, backup and deletion. Simply holding data counts.
Privacy principles – the eleven principles of ISO/IEC 29100, such as consent and choice, data minimisation, and openness, transparency and notice, which the standard uses as the foundation of its additional controls.
Control and implementation guidance – a control is a measure that modifies risk; implementation guidance explains how the control can be put into practice. ISO/IEC 27018 is written with "should" statements, which are recommendations rather than mandatory requirements.

Roles decide everything

The single most important idea in ISO/IEC 27018 is that the provider is acting for someone else. The customer decides why the data exists and what may be done with it; the provider only carries out those decisions. Almost every control in the standard follows from that idea. If the provider only acts on instructions, it must not use the data for its own purposes. If the customer remains accountable to the PII principals, the provider must help the customer answer their requests and must tell the customer about anything that affects their data, such as a breach, a new sub-processor or a demand from an authority.

Figure 1 – The customer controls the PII and instructs the public cloud provider, which processes it as a processor and passes the same obligations down to its own sub-processors.

Note that the roles attach to each processing activity, not to the company as a whole. A SaaS company is a processor for its customers' data inside the product but a controller for its own employee records and its sales contacts. Only the processor side falls under ISO/IEC 27018. A provider that wants to cover both sides in one management system usually looks at ISO/IEC 27701 as well, which is discussed in Lesson 7.

Why "personal data" is broader than people expect

Engineers sometimes think a service holds no PII because it stores only "technical" data. In practice, log files with user identifiers and IP addresses, support tickets with screenshots, memory snapshots captured after crashes and analytics events tied to account numbers are all PII when they can be linked to a person. ISO/IEC 27018 therefore asks providers to look beyond the main database and consider every place customer PII can end up, including temporary files, backups, logs and copies made during troubleshooting.

Lesson 3 – Structure of the standard

Two foundations

ISO/IEC 27018 is not a complete control catalogue on its own. It stands on two other documents:

ISO/IEC 27002:2022 supplies the base security controls. Its 93 controls are grouped into four themes: organizational, people, physical and technological. ISO/IEC 27018 assumes those controls are applied and adds what a public cloud processor needs on top of them.
ISO/IEC 29100 supplies the privacy roles and the eleven privacy principles. Where ISO/IEC 27002 has no suitable control, ISO/IEC 27018 adds one, framed by these principles.

The result is a document of about 35 pages that is easy to underestimate: most of its value lies in the specific additions, not in repeating general security practice.

How the document is laid out

Like all ISO documents it opens with a scope, normative references and terms and definitions, followed by an overview that explains how the guidance is organised. The rest falls into three kinds of content:

Cloud-PII guidance on existing ISO/IEC 27002 controls. For a control that already exists in ISO/IEC 27002, such as information security policies, awareness training, logging, backup, cryptography or incident management, the standard gives additional guidance specific to public cloud PII processing. Where the ISO/IEC 27002 control applies as written, nothing needs to be added. In the 2019 edition this guidance followed the fourteen control clauses of the 2013 catalogue; in the 2025 edition it is aligned with the 2022 catalogue.
Annex A, the extended control set. This annex holds the controls that have no counterpart in ISO/IEC 27002, for example on the processor's purpose, commercial use of customer data, disclosure requests, sub-processors, PII location and return or disposal of data. In earlier editions these extra controls were grouped under the ISO/IEC 29100 principles.
Annex B, new in 2025. ISO describes it as extended implementation guidance. It supports practitioners who need more detail on putting the controls into practice.

Control numbers changed when the guidance was realigned to the 2022 catalogue. This tutorial therefore describes controls by subject. When you build your own mapping, take the numbers from your copy of the 2025 edition and, if you are migrating, compare them with the 2019 numbers you used before.

Figure 2 – ISO/IEC 27018 adds cloud-PII guidance to ISO/IEC 27002 controls, an extended control set framed by ISO/IEC 29100 and new implementation guidance, all applied through the risk treatment of an ISO/IEC 27001 ISMS.

The extended controls, by privacy principle

The eleven ISO/IEC 29100 principles are a helpful way to remember what the additional controls are about. Paraphrased, they work out as follows for a public cloud processor:

Consent and choice – the provider cooperates with the customer so that the customer can honour PII principals' rights, such as access, correction and erasure, typically by offering tools or documented procedures.
Purpose legitimacy and specification – customer PII is processed only for the purposes in the customer's instructions, and it is not used for the provider's own marketing or advertising without the customer's express consent. Accepting such use must not be made a condition of getting the service.
Collection limitation and data minimisation – what PII is collected is the customer's decision; the processor-specific point is that temporary files and working copies created during processing are erased within a defined period.
Use, retention and disclosure limitation – disclosure of customer PII to law enforcement or other authorities happens only when legally binding; the customer is told unless the law prohibits it; and every disclosure is recorded.
Accuracy and quality – this is mainly the customer's responsibility as controller; the provider's part is to process the data faithfully and let the customer correct it.
Openness, transparency and notice – the provider discloses its use of sub-processors before they are used, and tells customers about intended changes so they can object or leave.
Individual participation and access – the provider supports the customer in giving people access to their data, without itself making decisions that belong to the controller.
Accountability – breaches involving PII are notified to the customer promptly, and there is a policy for returning, transferring and securely disposing of PII when a contract ends.
Information security – a set of practical safeguards: confidentiality agreements for staff with access to PII, limits on printed copies, logging of data restoration, encryption of PII sent over public networks and on portable media, secure disposal of storage, unique user identifiers and up-to-date records of authorised users, and making sure storage reused by a new tenant reveals nothing of the previous tenant's data.
Privacy compliance – the provider tells customers in which countries their PII may be stored and processed, and ensures the contract lets the customer meet its own legal duties.

Some principles, such as collection limitation, accuracy and quality, and individual participation, are mostly controller duties, so the processor's part in them is small and supportive. Treat this list as a map of subjects, not as the text of the standard. The standard's own wording and grouping are more precise, and the 2025 edition's Annex B adds detail on how to implement each topic.

Lesson 4 – How it works in practice

Inside an ISMS, not beside it

Because ISO/IEC 27018 contains guidance rather than management system requirements, a provider implements it through an existing management system. The usual home is an ISO/IEC 27001 information security management system (ISMS), which already requires the provider to define a scope, assess risks, select controls, keep a Statement of Applicability (SoA) and run internal audits and management reviews. The practical steps look like this:

Confirm the role. For each service and data set, decide whether the provider acts as a processor (in scope) or a controller (out of scope for this standard). Write the decision down; auditors will ask.
Map where customer PII lives. Primary stores, replicas, backups, logs, analytics pipelines, support tools, staging environments and sub-processors. Diagrams of data flows help here.
Extend the risk assessment. Consider risks to PII principals and to customers' ability to meet their legal duties, not only risks to the provider's business. Add regulatory and contractual requirements from the jurisdictions where customers operate.
Select controls. Work through the ISO/IEC 27002 controls with the extra ISO/IEC 27018 guidance, then through Annex A. Record in the SoA which ISO/IEC 27018 controls apply and why, whether each is implemented, and why any are excluded; many providers also add a short implementation note.
Change the contract. Many controls are commitments to customers: processing only on instructions, sub-processor notice, PII location, breach notification, disclosure handling and data return. They belong in the customer agreement or its data processing addendum, and the same obligations must flow down into sub-processor contracts.
Build the operating procedures. Runbooks for data subject request support, authority requests, breach notification, temporary file clean-up, restore logging and customer exit.
Train and monitor. Staff with access to customer PII need to know the rules, sign confidentiality agreements and understand that "looking at customer data to debug" is processing that must follow procedure.
Audit and improve. Include the ISO/IEC 27018 controls in the internal audit programme and management review, and feed findings into corrective action.

The life of customer PII

A useful way to check completeness is to follow customer PII through the whole relationship. ISO/IEC 27018 has something to say at every stage, from the first contract to final deletion.

Figure 3 – Customer PII moves from contract through processing, possible incidents and exit, and ISO/IEC 27018 expects defined handling at each stage, ending with return and secure erasure.

Handling a request from an authority

Demands for customer data from law enforcement or government agencies are one of the most sensitive situations a provider faces, because the provider holds data it does not control. The standard's approach is simple: disclose only when the request is legally binding, tell the customer unless a law forbids it, and keep a record. Providers often add a published policy and a transparency report.

Figure 4 – A provider discloses customer PII to an authority only under a legally binding request, notifies the customer unless prohibited, and records every request and disclosure.

Roles and artefacts

Typical roles are an information security manager who owns the ISMS, a privacy lead or data protection officer who owns processor commitments and interprets laws, engineering leads who implement technical controls, a legal or contracts owner for the data processing addendum, and a support or operations lead who runs request and incident procedures. Typical artefacts include the PII data-flow inventory, the risk register with privacy entries, the SoA with ISO/IEC 27018 rows, the data processing addendum, the public sub-processor list, the list of storage and processing locations, the authority request procedure and disclosure log, the breach notification procedure, and the customer exit procedure with evidence of deletion.

Shared responsibility still applies

ISO/IEC 27018 does not move the customer's legal duties onto the provider. The customer still decides on a lawful basis, retention periods and what to tell individuals, and it must configure the service sensibly. The provider's job is to make those decisions possible and to keep its own promises. Good providers publish documentation that tells customers which features and settings they need to use to meet their own obligations, for example where to set retention, how to export data and how to handle deletion requests.

Lesson 5 – Assessment, certification and compliance

Why there is no stand-alone certificate

Accredited certification checks conformity with requirements, the "shall" statements of a management system standard. ISO/IEC 27018 is a code of practice made of "should" statements, so it cannot be the basis of a management system certificate on its own. The requirements live in ISO/IEC 27001. In practice, a provider includes the ISO/IEC 27018 controls in the scope and SoA of its ISO/IEC 27001 ISMS, and the certification body assesses them during the ISO/IEC 27001 audit.

The outcome is typically an ISO/IEC 27001 certificate that also references ISO/IEC 27018, or a separate certificate or statement of conformity issued by the same body. Whether that additional document falls under the certification body's accreditation varies between bodies and countries, so read the wording carefully rather than assuming. Major providers state publicly that independent auditors assess their ISO/IEC 27018 controls at least annually as part of their ISO/IEC 27001 cycle, and some publish the auditor's name and the certificate.

The audit cycle

An ISO/IEC 27001 certification cycle normally lasts three years: an initial certification audit in two stages (a documentation and readiness review, then an assessment of implementation), surveillance audits in the following years, and a recertification audit before the certificate expires. The ISO/IEC 27018 controls are sampled in the same way as other controls. Auditors look for evidence such as contract templates with processor clauses, the sub-processor list and change notices, disclosure records, breach notification records, deletion records from customer exits, restore logs and staff confidentiality agreements.

What a customer should check

A certificate is only as useful as its scope. A cloud customer evaluating a provider should check:

that the certificate is current and issued by a recognised, accredited certification body;
that the specific service the customer will use is inside the certified scope, and that the regions or data centres are covered;
which edition of ISO/IEC 27018 is referenced, remembering that a 2019 reference may still be normal while bodies transition;
the provider's contract terms, because the standard's protections only bind the provider if the contract says so;
additional evidence where the stakes are high, such as the provider's audit report, its SoA extract or a SOC 2 report covering privacy-relevant controls.

Transition to the 2025 edition

Because the 2025 edition is fairly new, certification bodies decide how and when their audits refer to it. Providers using the 2019 edition should map their existing controls to the new alignment, update their SoA and procedures, and ask their certification body about its transition plan. This tutorial does not quote a deadline, because none is set by the standard itself.

Compliance with laws

Following ISO/IEC 27018 helps with legal processor duties, such as those in Article 28 of the GDPR (acting only on documented instructions, confidentiality of staff, security, sub-processor authorisation, assistance to the controller, deletion or return at the end, and making information available for audits). However, the standard is not an approved GDPR certification mechanism, and conformity does not by itself prove compliance with any law. Legal advice and the actual contract terms remain essential.

Lesson 6 – Worked example

The organisation

Fernhill Cloud is a fictional SaaS company of 180 people that offers a payroll and HR platform to about 400 business customers in the EU, the UK and India. Customers upload employee names, bank details, tax identifiers, salaries and leave records. Fernhill runs its platform on a large infrastructure-as-a-service provider in two regions, uses an email delivery service for payslip notifications and has an outsourced first-line support desk. It already holds an ISO/IEC 27001 certificate. Several large prospects have asked for ISO/IEC 27018 coverage in procurement, and one has asked whether Fernhill uses customer payroll data to train analytics features.

Step 1 – Roles and scope

Fernhill's privacy lead documents that Fernhill is a processor for all employee data that customers load into the platform, and a controller for its own staff records, its customers' billing contacts and its marketing database. Only the first category falls under ISO/IEC 27018. The ISMS scope statement is updated to say that the payroll platform, its support processes and the related sub-processors are covered by the ISO/IEC 27018 controls.

Step 2 – Data map and risks

The engineering team draws data flows and finds PII in four places nobody had listed: payroll calculation temp files on worker nodes, debug logs that capture full request bodies, CSV exports that support staff download to their laptops when helping customers, and backup snapshots retained for 90 days. The risk assessment adds risks to employees (for example, exposure of bank details), and risks to customers (inability to answer a deletion request because data survives in exports). It also records legal requirements from the GDPR, the UK GDPR and India's Digital Personal Data Protection Act.

Step 3 – Controls and the SoA

Working through the guidance and Annex A, the team decides:

Purpose and commercial use. The terms state that customer PII is processed only to provide the payroll service as instructed. The proposed analytics feature will use only data from customers who opt in through a separate, optional agreement, and declining will not affect the service.
Temporary files and logs. Temp files are written to encrypted, ephemeral volumes and deleted at the end of each run; a weekly job verifies that nothing older than 24 hours remains. Debug logging is changed to mask bank details and tax identifiers, and log access is restricted and reviewed.
Support access. Downloads of customer CSV files to laptops are replaced by a time-limited, logged view inside the support tool. Support staff and the outsourced desk sign confidentiality agreements, and access accounts are unique per person, with a monthly review of who holds access.
Locations and sub-processors. Fernhill publishes a sub-processor page listing the infrastructure provider, the email service and the support desk, with the countries where each processes data. Customers subscribe to change notices and receive 30 days' notice before a new sub-processor starts, with the right to object or terminate. These are Fernhill's own contractual choices, not figures from the standard.
Encryption. All traffic over public networks uses TLS; backups and storage are encrypted; portable media are not used for customer data.
Restore and storage reuse. Every data restore is logged with requester, reason and approver. The infrastructure provider's evidence on wiping storage before reuse is reviewed and filed as supplier assurance.

The SoA gains rows for each ISO/IEC 27018 control with a short implementation statement and a link to evidence. One control on printed copies is applied as a short rule: no printing of customer payroll data at all.

Step 4 – Contracts and procedures

Legal updates the data processing addendum with processing on documented instructions, breach notification to the customer without undue delay with the facts known at the time, cooperation on rights requests, the authority request policy and the exit terms. The same obligations are flowed down to the three sub-processors. Operations writes runbooks for authority requests (following Figure 4), breach notification and customer exit.

Step 5 – A test case

Six months later, a tax authority in one country sends Fernhill a request for one customer's payroll records. The on-call privacy lead checks the request with counsel and finds it is not legally binding on Fernhill, because it is not addressed through the proper legal process. Fernhill declines, refers the authority to the customer, records the request in the disclosure log and tells the customer. When a properly served, binding order arrives later, Fernhill notifies the customer first (no gag order applies), discloses only the records named, and records the disclosure.

Step 6 – Exit and audit

A customer leaves at the end of its contract. Fernhill provides a full export in the agreed formats, deletes production data after the customer confirms receipt, lets backups age out on their 90-day cycle and sends a deletion confirmation. During the next surveillance audit the certification body samples the SoA rows, the sub-processor change notices, the disclosure log, two customer exits and the restore log, and raises one minor nonconformity: the monthly access review was missed twice. Fernhill fixes the cause by automating the reminder and adding the review to the security team's dashboard. Its certificate now references ISO/IEC 27018, and procurement questionnaires take hours instead of weeks.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27018 is one piece of a family. Knowing what each neighbour does helps you explain to customers and colleagues why a provider might cite several of them at once.

Standard or framework	Type	Focus	Relationship to ISO/IEC 27018
ISO/IEC 27001:2022	Requirements	Information security management system	The certifiable management system in which ISO/IEC 27018 controls are usually implemented and audited.
ISO/IEC 27002:2022	Code of practice	93 general security controls in four themes	The base catalogue; ISO/IEC 27018 adds cloud-PII guidance to its controls and extra controls in Annex A.
ISO/IEC 27017	Code of practice	Security controls for cloud services, for providers and customers	Sister document for cloud security in general; providers often implement both together.
ISO/IEC 27701:2025	Requirements	Privacy information management system for controllers and processors	Certifiable, stand-alone privacy management system covering both roles; ISO/IEC 27018 adds detailed public-cloud processor guidance that can sit alongside it.
ISO/IEC 29100	Framework	Privacy roles, terms and eleven principles	Supplies the vocabulary and principles that frame the extended controls.
GDPR (EU 2016/679)	Law	Protection of personal data in the EU	Legal processor duties (for example Article 28) that ISO/IEC 27018 helps meet but cannot prove.
CSA Cloud Controls Matrix and STAR	Industry framework	Cloud security and privacy control objectives with assurance levels	Overlaps with ISO/IEC 27018 on cloud privacy topics; often answered together in cloud procurement.

A short way to remember the relationships: ISO/IEC 27001 says run a management system; ISO/IEC 27002 says here are the security controls to consider; ISO/IEC 27017 says here is how those controls change in the cloud; ISO/IEC 27018 says here is what a public cloud processor adds to protect personal data; and ISO/IEC 27701 says run a privacy management system for whatever role you play.

27018 or 27701?

This is the question most providers ask. ISO/IEC 27018 is narrow and detailed: it speaks directly to public cloud processors and lists the commitments cloud customers care about. ISO/IEC 27701 is broad: it is a full management system for privacy, covering controller and processor roles, and since its 2025 edition it can be certified without an ISMS. Many large providers maintain both, because customers ask for both. A small SaaS company that is mainly a processor may start with ISO/IEC 27018 controls inside its existing ISO/IEC 27001 scope and grow into ISO/IEC 27701 later, when it needs to show privacy management for its controller activities too.

Laws in other regions

The same pattern applies outside Europe. Processor or "data processor" duties exist in India's Digital Personal Data Protection Act, Brazil's LGPD, and many other laws. The details differ, but the core ideas of ISO/IEC 27018, acting on instructions, securing data, being transparent about sub-processors and locations, notifying breaches and deleting data at the end, appear in most of them. That is why a single, recognised code of practice is valuable for providers serving customers worldwide.

Common pitfalls and best practices

Common pitfalls

Claiming 27018 for controller activities. Marketing lists, consumer accounts and analytics the provider decides on are controller processing, which the standard does not cover.
Policy without contract. Promises on a trust page that are missing from the customer agreement and sub-processor contracts give customers little protection and auditors little evidence.
Forgetting the hidden copies. Logs, temp files, support exports and backups are where most surprises sit, and deletion promises fail if they are ignored.
Silent sub-processor changes. Adding a new analytics or support vendor without notice breaks one of the commitments customers value most.
Treating the certificate as the end. A certificate with a narrow scope, an old edition reference or the wrong services does not answer the customer's question.
Using customer data "to improve the product" by default. Secondary use without the customer's express agreement, or making it a condition of service, contradicts the standard's core idea.

Best practices

Write the role decision down for every service and data set, and review it when products change.
Put every commitment in three places: the contract, an operating procedure and an evidence record.
Publish what customers need: the sub-processor list, data locations, the authority request policy and customer-side configuration guidance.
Integrate, don't duplicate: add ISO/IEC 27018 rows to the existing ISO/IEC 27001 risk register, SoA, internal audit plan and management review.
Rehearse the hard cases: run tabletop exercises for a breach notification, a binding authority order and a large customer exit.
Plan the 2025 transition by mapping old to new control references and agreeing timing with the certification body.

Summary and key takeaways

ISO/IEC 27018:2025 is the current, third edition of the code of practice for public cloud providers that process PII on behalf of customers.
Its core idea is that the provider is a processor: it acts on the customer's instructions and does not use the data for its own purposes.
It builds on ISO/IEC 27002:2022 controls and the ISO/IEC 29100 privacy principles, adding cloud-PII guidance and an extended control set in Annex A, with new extended implementation guidance in Annex B.
Key protections cover commercial use, temporary files, authority requests, disclosure records, sub-processors, data locations, breach notification, encryption and return or deletion at exit.
It is guidance, so conformity is normally assessed within an ISO/IEC 27001 certification rather than as a stand-alone certificate.
Customers should check the certificate's scope, edition and issuer, and confirm the contract contains the commitments.
It complements ISO/IEC 27017 for cloud security and ISO/IEC 27701 for full privacy management, and it supports, but does not prove, compliance with laws such as the GDPR.

Reflection questions

Pick a cloud service you use at work. For which data is the provider a processor, and for which is it a controller? How would that change what ISO/IEC 27018 can promise you?
List every place your own service might hold copies of customer PII. Which of them would be missed by a deletion process that only cleans the main database?
Your provider announces a new sub-processor in a country where your customers do not want their data stored. What do you need from the contract and the provider's procedures to respond well?
How would you explain to a non-technical manager why a provider cannot hold a stand-alone ISO/IEC 27018 certificate, and what evidence they should ask for instead?
If your organisation already holds ISO/IEC 27001, what would you add first to cover ISO/IEC 27018, and when would moving to ISO/IEC 27701 make sense?