Your ISO 27001 certificate tells customers you protect information. It says very little about whether you handle personal data the way privacy law expects. A buyer's privacy team knows the difference, and sooner or later one of them asks what you have for privacy.
ISO/IEC 27701 is the standard most often offered as the answer. It is also one of the most misunderstood. People describe it as "GDPR certification", as a separate program, or as a paperwork exercise layered on top of 27001. None of those is accurate.
This article settles what the standard is, how it relates to the ISMS you already run, what changed with the 2025 revision, and how to decide whether it is worth your time. Later articles in this series take each part in depth.
What ISO 27701 is, and what it is not
ISO/IEC 27701 specifies a privacy information management system, usually shortened to PIMS. A PIMS is the set of policies, roles, processes, and controls an organization uses to manage personal data and the privacy risk it creates.
The standard was first published in 2019 as an extension to ISO/IEC 27001 and ISO/IEC 27002. That framing is the important part. It does not ask you to build a second management system. It asks you to widen the one you have so that "information" explicitly includes personally identifiable information (PII), and "risk" explicitly includes risk to the people that information is about.
The standard uses its own vocabulary, which helps when reading it:
PII principal is the person the data relates to. GDPR calls this the data subject.
PII controller decides why and how PII is processed.
PII processor processes PII on behalf of, and on the instructions of, a controller.
What the standard is not matters as much. It is not a law and does not make you compliant with one. It is not tied to any single jurisdiction. It is written to work alongside GDPR, US state privacy laws, and others, and it leaves the legal judgments to you and your counsel.
How it extends ISO 27001
You can think of the 2019 edition as doing four things to your existing ISMS.
It extends the management system requirements. Where ISO 27001 talks about context, scope, risk assessment, and the Statement of Applicability, ISO 27701 adds privacy to each. You determine whether you act as a controller, a processor, or both. You consider privacy law and PII principals when you define context. Your risk assessment covers privacy risk as well as security risk.
It adds privacy guidance to the ISO 27002 controls. Many existing security controls gain a privacy angle. Your incident process, for example, needs to recognize when an incident involves PII and what notification duties may follow.
It adds controls specific to controllers. These cover purpose, lawful basis, consent, privacy impact assessment, obligations to PII principals, privacy by design and by default, and sharing or transfer of PII.
It adds controls specific to processors. These cover the customer agreement, processing only on instructions, assisting the customer with its obligations, subcontractors, disclosure requests, and return or disposal of PII.
It also includes informative annexes that map its content to other documents, including GDPR. Those mappings are useful starting points. They are not a substitute for reading the law that applies to you.
If you need a refresher on the base layer, our explainer on what an ISMS is in plain terms covers the management system that ISO 27701 builds on.
The 2025 revision and why the edition matters
ISO revised ISO/IEC 27701 in 2025. The revision reorganized the document and changed how it is positioned relative to ISO 27001. Part of the reason is straightforward: the 2019 edition was written against the 2013 editions of ISO 27001 and 27002, and both were replaced in 2022.
For you, the practical consequence is that clause numbers, control numbering, and certification prerequisites can differ between editions. An article, template, or consultant's checklist written for one edition may not line up with the other.
The underlying ideas have not changed in substance. You still decide your role, assess privacy risk, select controller or processor controls, and operate them with evidence. This series describes the structure in general terms for that reason.
Controller, processor, or both
Role is the first real decision, and it shapes everything after it.
A typical B2B SaaS company is a processor for the customer data that flows through its product. The same company is a controller for its own employee records, its marketing lists, and its product analytics, if it decides the purposes of that processing.
Most organizations are therefore both, for different processing activities. That is normal. It means you select controls from both sets and apply each set to the activities where it fits. The mistake to avoid is declaring yourself "a processor" for the whole scope because that is how you describe the product. An auditor will ask about your HR system and your CRM.
Who it is worth pursuing for
ISO 27701 earns its cost in a fairly specific set of situations.
You already hold, or are pursuing, ISO 27001. The incremental work is real but bounded, because the management system already exists.
Your buyers are privacy-mature. European enterprises, regulated industries, and public sector buyers increasingly ask processors to show how privacy is managed, not only how data is secured.
You process PII at scale on behalf of customers. A processor that can show independently audited controls over instructions, subprocessors, and deletion answers a large share of a customer's processor due diligence in one document.
You want structure for a privacy program that is currently a set of documents. The management system disciplines of internal audit and management review apply to privacy once it is inside the PIMS.
It is a weaker fit if you have no ISO 27001 program and no plans for one, if your customers have never asked about privacy beyond a data processing agreement, or if you process very little personal data. In those cases a well run GDPR or state law program, documented clearly, may serve you better for now.
Be honest about one thing. Certification does not remove the need to meet legal obligations. A certified organization can still miss a breach notification deadline or rely on a lawful basis that does not hold. If you are still settling questions like which GDPR lawful basis applies to each activity, do that work first. The standard will ask you to document the answer, not to invent it.
What changes in your ISMS day to day
Once the PIMS is running, a few things look different.
Your scope statement and Statement of Applicability cover privacy controls, with a justification for each inclusion and exclusion.
Your risk register contains risks to PII principals, scored on harm to them, not only on impact to the business.
You keep records of processing, and you can show where PII lives, why, and for how long.
New features and vendors go through a privacy review before launch, and you keep the output.
Requests from individuals, or from customers relaying them, are logged and tracked to completion.
Internal audit and management review include privacy objectives and results.
None of these is exotic. Most privacy-aware teams do some of them already. The standard's contribution is to make them systematic, owned, and auditable.
For the framework summary and how it sits next to the rest of your program, see the ISO 27701 framework page.
How TrustLynce helps
TrustLynce maps ISO 27701 controls to the ISO 27001 controls you already operate, so shared evidence is collected once through compliance automation. Its Statement of Applicability workflow covers both standards, and the data privacy tools hold your processing records, impact assessments, and data subject requests in the same place your auditor will look.