ISO/IEC 27701:2025: ISO/IEC 27701:2025 – Tutorial (about 60 minutes)

ISO/IEC 27701:2025 is the international standard for a privacy information management system (PIMS): a managed, risk-based way for an organisation to look after personal data and the people that data describes. Organisations that collect personal data for their own purposes, and service providers that process it on behalf of clients, use it to organise privacy work, show accountability to customers and regulators, and in many cases obtain an accredited certificate. After this tutorial you will be able to explain what the 2025 edition requires, how its clauses and Annex A controls fit together, how a PIMS is built and audited, and how it relates to ISO/IEC 27001, ISO/IEC 29100 and privacy laws such as the GDPR.

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 27701:2025, the second edition, published on 14 October 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 – Privacy information management systems – Requirements and guidance". It replaces ISO/IEC 27701:2019 and, unlike that first edition, is a stand-alone management system standard that no longer has to be built on top of ISO/IEC 27001. A companion standard for certification bodies, ISO/IEC 27706:2025, was also published in 2025. Certificates issued against the 2019 edition are being moved to the 2025 edition during a transition period set by accreditation bodies; the end dates differ between schemes, so confirm yours with your certification body. The 2025 edition is current and not under revision. Verified 2026-10-29.

Who this is for: privacy and data protection officers, security and compliance staff, engineers and product owners who build systems that handle personal data, cloud and SaaS teams who receive customer questionnaires asking about "ISO 27701", and auditors or consultants who are new to the standard. It is equally useful if your organisation already runs an ISO/IEC 27001 information security management system and wants to add privacy to it.

Prerequisites: none. A general idea of what personal data is and what a security control is will help, but every term is explained when it first appears. You do not need a copy of the standard to follow this tutorial, although anyone who implements it should buy one from ISO, IEC or a national standards body.

By the end of this tutorial:

You will be able to explain why ISO/IEC 27701 exists, what a PIMS is, and what changed between the 2019 and 2025 editions.
You will be able to use the core vocabulary correctly, especially PII, PII principal, PII controller and PII processor.
You will be able to describe the clause 4 to 10 structure and the purpose of Annexes A to F, including the three control tables of Annex A.
You will be able to walk through the privacy risk assessment and treatment process and explain the role of the Statement of Applicability.
You will be able to outline how a PIMS is certified, transitioned from the 2019 edition and kept alive through surveillance audits.
You will be able to apply the standard to a realistic organisation that is a controller for some processing and a processor for other processing.
You will be able to compare ISO/IEC 27701 with ISO/IEC 27001, ISO/IEC 29100, ISO/IEC 27018 and the GDPR.

Lesson 1 – Origins, purpose and scope

Why privacy needs a management system

Most organisations hold personal data: employee records, customer accounts, website analytics, support tickets, CCTV footage, health or payment details. Laws in many countries give people rights over that data and place duties on the organisations that use it. The European Union's General Data Protection Regulation (GDPR), India's Digital Personal Data Protection Act, Brazil's LGPD, California's privacy laws and dozens of others differ in detail, but they share common ideas: be clear about why you use data, use no more than you need, keep it accurate and secure, respect the person's rights, and be able to prove what you did.

The last idea, accountability, is where many organisations struggle. A privacy policy on a website and a few contract clauses do not show that privacy is actually managed. Someone has to know where personal data lives, who decides how it is used, which risks exist for the people concerned, which safeguards are in place and whether those safeguards work. When staff change, systems are replaced or a new product is launched, all of this has to keep working. That is exactly the problem a management system solves. A management system is the set of policies, roles, processes, records and review routines an organisation uses to reach its objectives in a repeatable way. ISO publishes management system standards for quality (ISO 9001), environment (ISO 14001), information security (ISO/IEC 27001) and many other topics. ISO/IEC 27701 is the one for privacy.

From an extension to a stand-alone standard

The first edition, ISO/IEC 27701:2019, was developed by working group 5 of ISO/IEC JTC 1/SC 27, which deals with identity management and privacy technologies. It was written as an extension to ISO/IEC 27001 (the requirements for an information security management system, or ISMS) and ISO/IEC 27002 (guidance on security controls). Its main clauses said, in effect, "wherever ISO/IEC 27001 talks about information security, read it as information security and privacy", then added privacy-specific guidance and two control annexes, one for organisations that decide how personal data is used and one for organisations that process it for others. The consequence was practical: you could only be certified to ISO/IEC 27701:2019 if you also had, or obtained at the same time, an ISO/IEC 27001 certificate.

Many organisations liked the idea but found that dependency awkward. A marketing agency, a hospital department or a public body might want to prove good privacy management without running a full ISMS certification. The 2025 edition answers this. It contains its own complete set of management system requirements in clauses 4 to 10, following the ISO Harmonized Structure (the common clause layout shared by all modern ISO management system standards). Its only normative reference is ISO/IEC 29100, the privacy framework that defines the basic privacy terms and principles. The security controls that matter for personal data now sit inside the standard itself, in a table of Annex A, rather than being borrowed from ISO/IEC 27002. An organisation can therefore implement and certify a PIMS on its own, or integrate it with an existing ISMS.

Figure 1 – The 2019 edition extended an ISO/IEC 27001 ISMS, while the 2025 edition contains its own management system requirements and can be certified alone or alongside an ISMS.

Scope of the standard

According to its scope clause, the standard sets requirements for establishing, implementing, maintaining and continually improving a PIMS, and it gives guidance to help meet them. It applies to any organisation that acts as a PII controller, a PII processor or both, whatever its size, sector or legal form, including public bodies and not-for-profits. It is technology-neutral and law-neutral: it does not assume a particular country's legislation, which is why it can serve as a common language between a European customer, an Indian service provider and a US sub-contractor.

It is important to be clear about what the standard is not. It is not a law and does not replace legal advice. Conforming to it does not automatically make an organisation compliant with the GDPR or any other regulation, although a working PIMS makes compliance far easier to achieve and demonstrate. It is not a technical specification for encryption or anonymisation techniques. And it is not a one-off project: a PIMS is meant to run for as long as the organisation handles personal data.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 27701 uses the vocabulary of ISO/IEC 29100 and of the Harmonized Structure. Privacy laws often use different words for the same ideas, so learning the mapping early saves confusion. 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 linked, directly or indirectly, to that person. It corresponds broadly to "personal data" in the GDPR. Names, email addresses, device identifiers, location traces and payroll records are all PII.
PII principal – the natural person to whom the PII relates. The GDPR calls this person the "data subject". Employees, customers, patients and website visitors are all PII principals.
PII controller – a party that decides the purposes for which PII is processed and the means of processing (other than individuals using data for purely personal purposes). Similar to the GDPR "controller". When two or more parties decide together, they are joint PII controllers.
PII processor – a party that processes PII on behalf of, and according to the instructions of, a PII controller. Similar to the GDPR "processor". A payroll bureau or a cloud email provider processing a client's staff data is a typical processor. A processor that itself engages another processor creates a sub-processor (sub-contractor) relationship.
Processing of PII – any operation on PII: collecting, storing, changing, retrieving, disclosing, transferring, anonymising, deleting and so on. Even simply holding data is processing.
Privacy information management system (PIMS) – the management system that addresses the protection of privacy as potentially affected by the processing of PII. It is the subject of the standard.
Privacy risk – the effect of uncertainty on privacy, usually expressed as the likelihood and consequences of an event that could harm PII principals, for example unauthorised disclosure, excessive collection or an inability to exercise rights. In ISO/IEC 27701 the focus is on harm to the people concerned, not only on harm to the organisation.
Privacy impact assessment (PIA) – a structured process for identifying, analysing and treating privacy risks of a particular processing activity, system or project. GDPR practitioners call a similar process a data protection impact assessment (DPIA).
Statement of Applicability (SoA) – a document that lists the controls the organisation considers necessary, explains why they are included, states whether they are implemented, and justifies any Annex A control that has been excluded.
Privacy by design and privacy by default – building privacy into processes and systems from the start, and setting default options so that only the PII needed for a stated purpose is processed unless the person chooses otherwise.
Consent – a PII principal's freely given, specific and informed agreement to processing of their PII. Consent is only one possible basis for processing; laws provide others, such as contract or legal obligation.
De-identification – a process that removes the association between a set of identifying data and the PII principal, for example by pseudonymisation or anonymisation. Pseudonymised data can still be linked back with extra information, so it usually remains PII.
Interested party – a person or organisation that can affect, be affected by, or believe itself affected by the organisation's decisions, such as customers, regulators, PII principals, staff and suppliers.
Nonconformity and corrective action – a nonconformity is a failure to meet a requirement; corrective action removes its cause and prevents recurrence. These terms come from the Harmonized Structure.

The two roles that shape everything

The most important concept in the standard is the difference between controller and processor, because Annex A has different controls for each. The role is not a property of the organisation; it is a property of each processing activity. The same company can be a controller for its own employee records and its newsletter list, and a processor for the customer data it handles inside the service it sells. A good PIMS starts by working out, activity by activity, which role applies. Getting this wrong leads to missing controls: a processor that thinks it is a controller may start using client data for its own analytics, which its contracts almost certainly forbid; a controller that thinks it is "just a processor" may never establish a lawful basis or tell people how their data is used.

The eleven privacy principles

ISO/IEC 29100 sets out eleven privacy principles that sit behind the whole standard: consent and choice; purpose legitimacy and specification; collection limitation; data minimisation; use, retention and disclosure limitation; accuracy and quality; openness, transparency and notice; individual participation and access; accountability; information security; and privacy compliance. You do not need to memorise them, but you will see each one reflected in the controls of Annex A. Annex C of ISO/IEC 27701 maps the controls to these principles.

Lesson 3 – Structure of the standard

ISO/IEC 27701:2025 has an introduction, eleven numbered clauses, six annexes and a bibliography. Clauses 1 to 3 set the scene (scope, the normative reference to ISO/IEC 29100, and terms). Clauses 4 to 10 contain the management system requirements, written with "shall". A short clause 11 explains how the annexes are to be used. Annex A and Annex B are normative, which means they are part of the requirements and guidance you are expected to apply; Annexes C to F are informative mappings.

Figure 2 – The 2025 edition combines management system clauses with a normative control annex in three tables, a normative guidance annex and four informative mapping annexes.

Clauses 4 to 10 in plain language

If you already know ISO 9001 or ISO/IEC 27001, these clauses will feel familiar, because the Harmonized Structure gives every management system standard the same skeleton. The difference is that every requirement is aimed at privacy and at the protection of PII principals.

Clause 4, Context of the organization: understand internal and external issues that affect the PIMS (laws, contracts, technology and the sector); identify interested parties and which of their requirements the PIMS will address; determine the organisation's role as PII controller and/or processor; and define the scope of the PIMS.
Clause 5, Leadership: top management shows commitment, sets a privacy policy that is now a document in its own right rather than a section of a security policy, and assigns responsibilities and authorities for privacy roles.
Clause 6, Planning: address risks and opportunities, including a defined privacy risk assessment process and a privacy risk treatment process that ends in a Statement of Applicability; set measurable privacy objectives and plan how to reach them; and carry out changes to the PIMS in a planned way.
Clause 7, Support: provide resources, ensure staff are competent and aware of the privacy policy and their role, plan internal and external communication, and control documented information (the policies, procedures and records the PIMS needs).
Clause 8, Operation: plan and control the processes, perform privacy risk assessments at planned intervals and when significant changes happen, and implement the risk treatment plan.
Clause 9, Performance evaluation: monitor and measure the PIMS, run an internal audit programme and hold management reviews with defined inputs and outputs.
Clause 10, Improvement: react to nonconformities, take corrective action and continually improve the suitability, adequacy and effectiveness of the PIMS.

Annex A – the reference controls

Annex A lists control objectives and controls in three tables. Table A.1 is for organisations acting as PII controllers, Table A.2 for organisations acting as PII processors, and Table A.3 contains the information security controls that matter for PII and apply to both roles. Published commentaries count 31, 18 and 29 controls respectively, 78 in total; always check the numbers against your own licensed copy. The tables are a reference, not a checklist: the organisation compares the controls its risk treatment selected with Annex A to make sure nothing necessary has been overlooked, and records the outcome in the Statement of Applicability.

The controller controls in Table A.1 cover four broad themes that will be familiar from privacy law:

Conditions for collection and processing – identifying and documenting purposes, establishing a lawful basis, handling consent, carrying out privacy impact assessments, having contracts with processors and clear arrangements with joint controllers, and keeping records of processing.
Obligations to PII principals – working out what the organisation owes people, telling them clearly how their data is used, letting them withdraw consent or object, and handling access, correction and erasure requests, including where decisions are automated.
Privacy by design and by default – limiting collection and processing to what the purpose needs, keeping PII accurate, minimising and de-identifying it, managing temporary files, retention and disposal, and protecting it in transmission.
PII sharing, transfer and disclosure – knowing the basis for transfers between jurisdictions, knowing which countries and organisations data may go to, and keeping records of transfers and disclosures to third parties.

The processor controls in Table A.2 follow the same themes from the service provider's point of view: process only according to the customer's documented instructions and contract; do not use the customer's PII for your own purposes such as marketing; tell the customer if an instruction appears to break the law; help the customer meet its own obligations, including requests from PII principals; return, transfer or securely dispose of PII when the service ends; handle legally binding disclosure requests correctly; and be transparent about sub-processors, engaging or changing them only under the agreed conditions.

Table A.3 replaces the long list of ISO/IEC 27002 sub-clauses that the 2019 edition referenced. Instead of repeating every general security control, it concentrates on those with privacy-specific content, such as access control, logging, backup, supplier security, secure development, information security incident management (including PII breaches), and protection of records. General security topics without privacy-specific content are no longer listed separately; they remain the job of the wider security programme. An organisation that runs ISO/IEC 27001 will find that much of its ISMS already supports Table A.3.

Annexes B to F

Annex B gives implementation guidance for each Annex A control, numbered to match the three tables. In the 2019 edition this guidance was spread across clauses 6, 7 and 8; it is now collected in one place and written as advice ("should") rather than as requirements. Annex C maps the controls to the eleven ISO/IEC 29100 principles. Annex D maps them to articles of the GDPR, and the standard stresses that this mapping is only indicative: each organisation must still assess its own legal obligations. Annex E maps to ISO/IEC 27018 (PII protection in public clouds) and ISO/IEC 29151 (a code of practice for PII protection). Annex F shows the correspondence between the 2019 and 2025 controls, which is the starting point for any transition project.

Lesson 4 – How it works in practice

A PIMS is not a binder of documents; it is a cycle of planning, doing, checking and improving. The steps below show the order in which most organisations build one. Real projects overlap the steps, but skipping any of them usually causes trouble later.

Figure 3 – Building and running a PIMS is a loop: risks are reassessed whenever processing, laws or the organisation change.

Step 1 – Context, scope and roles

Start by understanding why privacy matters to this organisation. Which laws apply in the countries where it operates and where its PII principals live? What do customers demand in contracts and questionnaires? Is the organisation mainly a controller, a processor, or both? Then define the scope: which legal entities, locations, services, systems and processing activities are covered. A narrow scope is legitimate, but it must make sense to an outsider. Scoping out the one product that handles sensitive health data while certifying the rest of the company would mislead customers, and auditors will challenge it.

Step 2 – Leadership and responsibilities

Top management approves the privacy policy, sets direction and provides resources. Typical roles include a privacy lead or data protection officer, privacy champions in product teams, owners for each processing activity, and a person responsible for handling requests from individuals. The policy should commit to meeting applicable requirements and to continual improvement, and it should be understandable by the staff who must follow it.

Step 3 – Inventory of processing

You cannot manage what you cannot see. The organisation builds a record of its processing activities: what PII is processed, about whom, for which purpose, on which legal basis (for controllers), on whose instructions (for processors), in which systems and countries, shared with whom, and for how long it is kept. Many organisations already keep such a record because the GDPR requires one; the PIMS makes it a maintained, owned and reviewed asset rather than a spreadsheet created once for a regulator.

Step 4 – Privacy risk assessment

Clause 6 requires a defined, repeatable process: criteria for accepting risk, a method that gives consistent and comparable results, identification of risk owners, analysis of likelihood and consequences, and evaluation against the criteria. The distinctive point is the perspective. A security risk assessment asks what could harm the organisation's information; a privacy risk assessment also asks what could harm the people whose data it is, for example discrimination, financial loss, distress, loss of control over their data or surveillance. ISO/IEC 27557 gives guidance on organisational privacy risk management and fits naturally here. For new or high-risk processing, a privacy impact assessment examines a specific activity in more depth.

Step 5 – Risk treatment and the Statement of Applicability

For each unacceptable risk, the owner chooses treatment options and selects controls. These can come from anywhere: Annex A, ISO/IEC 27002, sector rules or the organisation's own design. The selected controls are then compared with Annex A to catch omissions. The result is the Statement of Applicability, which lists all necessary controls with justification, their implementation status, and the reasons for excluding any Annex A control. A typical justified exclusion is a pure processor excluding controller-only controls such as obtaining consent, because the customer, not the processor, decides on consent. The risk treatment plan, approved by risk owners, describes who will implement what and by when.

Step 6 – Implementing controls and building competence

Controls are a mix of documents, technology and behaviour. Examples include a privacy notice written in clear language; a consent-management feature in the product; data retention rules that the database actually enforces; contract templates for processors and sub-processors; a request-handling procedure with deadlines; pseudonymisation of analytics data; and logging of access to sensitive records. Staff need awareness training on the policy and role-specific training for engineers, support agents and marketers.

Step 7 – Operating the system day to day

Operation is where the PIMS proves its value. Requests from individuals are answered on time; new projects pass through privacy by design reviews and, where needed, a PIA; suppliers are assessed before they receive PII; incidents involving PII are assessed for notification duties under the applicable law and contracts; and changes to processing are reflected in the inventory and the risk assessment.

Step 8 – Checking and improving

The organisation defines what to measure (for example, the percentage of individual requests answered within the legal deadline, the number of processing activities without a reviewed retention rule, or training completion), runs internal audits by people who are independent of the area audited, and holds management reviews. Problems become nonconformities with root-cause analysis and corrective action. This loop is what turns a compliance project into a living system.

Documented information you will typically need

The standard leaves the format to the organisation, but auditors normally expect to see at least: the PIMS scope; the privacy policy; the privacy risk assessment and treatment methods and their results; the Statement of Applicability; privacy objectives; evidence of competence; records of processing; records of PIAs, requests, incidents and disclosures; internal audit reports; management review outputs; and records of nonconformities and corrective actions. Keep documents short and connected to real practice. A thick manual that nobody uses is worse than a few clear procedures that people follow.

Lesson 5 – Assessment, certification and compliance

Who certifies

Organisations can be certified against ISO/IEC 27701 by an independent certification body. Certification bodies that want their certificates to carry weight are themselves accredited by a national accreditation body, such as UKAS in the United Kingdom, ANAB in the United States, DAkkS in Germany or NABCB in India, most of which are members of the International Accreditation Forum (IAF). Accredited certification bodies follow ISO/IEC 17021-1, the general standard for bodies that audit management systems, plus ISO/IEC 27706:2025, which adds PIMS-specific requirements such as auditor competence and audit time. ISO/IEC 27706 replaces the earlier technical specification ISO/IEC TS 27006-2:2021. ISO and IEC themselves do not issue certificates.

Figure 4 – A typical accredited certification cycle: two-stage initial audit, a three-year certificate kept alive by surveillance, then recertification.

The audit process

Before applying, the organisation should have run its PIMS for long enough to produce evidence: at least one full internal audit and one management review, and records of real operation such as answered requests and completed PIAs. The certification audit then has two stages. Stage 1 reviews the design: scope, policy, risk methodology, Statement of Applicability and readiness. Stage 2 tests whether the system works in practice, through interviews, sampling of records and observation. Auditors will ask, for instance, to see how a deletion request moved through support and engineering, or how a new sub-processor was assessed and announced to customers. Major nonconformities must be corrected before a certificate is issued.

A certificate normally runs for three years, with surveillance audits in the intervening years and a recertification audit before expiry. The certificate states the scope, which is why careful scoping in clause 4 matters so much: customers read it to decide whether the certificate covers the service they buy.

Integrated or stand-alone certification

Under the 2025 edition an organisation can hold a PIMS certificate without an ISO/IEC 27001 certificate. Organisations that already run an ISMS usually integrate the two systems: one set of leadership, document control, internal audit and management review processes covering both security and privacy, with separate risk criteria where needed. Certification bodies commonly audit both in a combined visit.

Transition from the 2019 edition

Organisations certified to the 2019 edition must transition to the 2025 edition within the period set by their accreditation body and certification body. UKAS, for example, has published transition arrangements for the certification bodies it accredits, and other accreditation bodies set their own. Deadlines differ between schemes, so confirm the date that applies to you with your certification body. A transition project typically uses Annex F to map old controls to new ones, rewrites the policy and PIMS documents around clauses 4 to 10, updates the risk assessment and Statement of Applicability against the three Annex A tables, and finishes with an internal audit and management review before the transition audit.

Certification versus legal compliance

A PIMS certificate says that an independent auditor found the management system conforming to ISO/IEC 27701 within the stated scope at the time of audit. It does not say that every processing activity is lawful, and it is not by itself a certification under the GDPR's own certification mechanism. Regulators may view it as useful evidence of accountability, and customers often accept it in place of long questionnaires, but legal obligations remain with the organisation. Personal credentials such as "ISO/IEC 27701 Lead Implementer" or "Lead Auditor" are different again: they are certificates for individuals issued by training and personnel certification bodies, not certificates of an organisation's PIMS.

Lesson 6 – Worked example

To see how the pieces connect, follow a fictional company, PayNimbus, a 220-person software company with offices in Pune and Berlin. It sells a cloud payroll and HR service to around 400 business customers in Europe and India. PayNimbus already holds an ISO/IEC 27001 certificate. Its largest customers have started asking for evidence of privacy management, and its sales team keeps losing time on privacy questionnaires. The leadership team decides to implement ISO/IEC 27701:2025 and integrate it with the ISMS.

Context and roles

The new privacy lead, Meera, runs a workshop with the heads of product, engineering, support, HR and marketing. They list the processing activities and decide the role for each. For payroll and HR records of customers' employees, PayNimbus acts on its customers' instructions: it is a PII processor, and its customers are the controllers. For its own staff records, its sales leads, its newsletter and its website analytics, PayNimbus decides why and how data is used: it is a PII controller. One activity is less obvious. The product team wants to use aggregated payroll data to build salary benchmarks to sell as a new feature. The workshop concludes that this would make PayNimbus decide a new purpose for customer data, which the processor contracts do not allow. The idea is paused until the legal team designs an approach in which customers explicitly agree and the data is properly de-identified.

The scope is agreed as "the PayNimbus payroll and HR platform and the supporting business processes in Pune and Berlin, in the roles of PII processor for customer data and PII controller for staff, sales and marketing data". External issues recorded include the GDPR, India's DPDP Act, German employee-data rules, customer contract terms and growing customer demand for transparency about sub-processors.

Leadership and policy

The chief executive signs a privacy policy that is separate from the security policy, commits to applicable legal and contractual requirements and to continual improvement, and names Meera as privacy lead with authority to stop releases that fail a privacy review. Each processing activity gets an owner. Privacy objectives are set for the first year, for example: answer every customer request for help with an individual's rights within five working days; review every sub-processor before onboarding; reach 95 % completion of role-based privacy training.

Inventory and risk assessment

The team extends the GDPR record of processing into a full inventory, adding systems, countries, retention periods and suppliers. The privacy risk assessment uses a five-point scale for likelihood and a five-point scale for consequences to PII principals, with an acceptance threshold approved by management. Three risks stand out:

Support engineers can see full payroll records when troubleshooting, which is more access than most tickets need. The consequence for employees of a leak would be serious (salary, bank and tax data).
A log analytics supplier receives application logs that sometimes contain employee names and bank account numbers.
When a customer leaves, its data is deleted from the main database, but backups keep it for 13 months with no documented reason.

Treatment and the Statement of Applicability

For the first risk, PayNimbus introduces just-in-time access approved by the customer's administrator, masks bank details by default in the support console and logs every view. For the second, engineering adds automatic redaction of PII in logs and the supplier contract is updated with processor terms; the supplier is added to the published sub-processor list, and customers are notified as their contracts require. For the third, retention is reduced to 35 days, matching what customers were told, and the return-and-disposal procedure is documented with a deletion certificate offered to departing customers.

The Statement of Applicability now covers all three Annex A tables. Table A.2 processor controls are applicable to the payroll platform. Table A.1 controller controls are applicable to staff, sales and marketing processing. Table A.3 security controls are applicable throughout and are largely met by the existing ISMS, with additions for log redaction and PII breach handling. A few controls are excluded with justification, for example a controller control about disclosure records for a type of disclosure the company has no channel or business reason to make. Meera records every justification so that an auditor can follow the reasoning.

Operation

Product teams adopt a short privacy by design checklist in their planning template; anything that introduces new PII, a new purpose or a new country triggers a full PIA. Support agents learn to recognise when a customer forwards an employee's access or erasure request, and to route it to the customer's administrator tools rather than acting on it directly, because the customer is the controller. Incident handling gains a privacy step: each security incident is assessed for whether PII was affected and whether customers must be notified under their contracts so that they can meet their own legal notification duties.

Checking, auditing and certifying

After four months of operation an internal auditor from the ISMS team, who did not design the PIMS, samples twenty requests, five PIAs and the sub-processor onboarding records. She finds that two PIAs were completed after the feature had already shipped, and raises a nonconformity. The root cause is that the release checklist did not include the PIA gate; the corrective action adds it and the next audit confirms it works. Management review looks at the objectives, the audit results, the open risks and changes in law, and approves budget for automated data discovery.

PayNimbus then asks its certification body for a combined surveillance audit of ISO/IEC 27001 and an initial ISO/IEC 27701 audit. Stage 1 confirms the design; Stage 2, six weeks later, samples records across support, engineering and HR. The auditors raise one minor nonconformity (two contract templates for marketing tools lacked processor terms), which is corrected within the agreed timeframe, and the certificate is issued with the scope agreed in the workshop. Sales now answer most privacy questionnaires with the certificate, the scope statement and a short summary of the Statement of Applicability, and the salary benchmark idea returns to the backlog with a privacy design that customers can opt into.

What the example shows

The decisive moves were not technical. They were deciding roles per activity, looking at risk from the employees' point of view, making the Statement of Applicability honest, and auditing real records rather than documents. The technical controls followed naturally from those decisions.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27701 sits in a family of security and privacy documents and next to privacy laws. Knowing who does what avoids duplicated effort and false assumptions.

Standard or framework	What it is	Relationship to ISO/IEC 27701:2025
ISO/IEC 27001:2022	Requirements for an information security management system, certifiable	Same Harmonized Structure; often integrated with a PIMS. No longer a prerequisite for 27701 certification since the 2025 edition.
ISO/IEC 27002:2022	Guidance on 93 information security controls	The 2019 edition extended its guidance; the 2025 edition carries its own privacy-relevant security controls in Table A.3.
ISO/IEC 29100	Privacy framework: actors, roles and eleven privacy principles	The only normative reference; supplies key terms. Annex C maps controls to its principles.
ISO/IEC 27018	Code of practice for protecting PII in public clouds acting as processors	More detailed guidance for cloud processors; mapped in Annex E. Often used together with Table A.2.
ISO/IEC 29151	Code of practice for PII protection controls	Additional control guidance; mapped in Annex E.
ISO/IEC 27557	Guidance on organisational privacy risk management	Supports the privacy risk assessment and treatment required in clauses 6 and 8.
ISO/IEC 27706:2025	Requirements for bodies that audit and certify a PIMS	Used by certification bodies, not by the organisation being certified; applies with ISO/IEC 17021-1.
GDPR and other privacy laws	Binding legal obligations	Annex D gives an indicative GDPR mapping. A PIMS helps demonstrate accountability but does not replace legal compliance.
NIST Privacy Framework	Voluntary US framework of privacy outcomes, not certifiable	Complementary: useful for describing target outcomes; a PIMS provides the certifiable management system.

Choosing a combination

A cloud provider serving many customers often combines ISO/IEC 27001, ISO/IEC 27701 and ISO/IEC 27018 under one integrated management system, because customers ask for all three. A small controller with little IT of its own, such as a clinic or a recruitment agency, may implement ISO/IEC 27701 alone and use the GDPR mapping in Annex D as a cross-check with its lawyers. An organisation building AI systems may add ISO/IEC 42001 for AI management, sharing the same Harmonized Structure processes. In each case, the rule is the same: one set of core management processes, with topic-specific risk criteria and controls.

Mapping is not equivalence

The mapping annexes are useful, but the standard is explicit that they are indicative. A row that links a control to a GDPR article means the control helps with that article, not that implementing it satisfies the law. Legal obligations depend on the facts, the jurisdiction and regulators' interpretation, so mappings should be reviewed by people who understand the applicable law.

Common pitfalls and best practices

Common pitfalls

Assuming one role for the whole company. Labelling the organisation "a processor" or "a controller" overall, instead of deciding per processing activity, leads to missing controls and contracts that do not match reality.
Treating privacy as a security add-on. Copying the ISMS risk register and adding the word "privacy" ignores harms such as excessive collection, unexpected purposes or lack of transparency, which no firewall can fix.
A Statement of Applicability without reasons. Marking controls "not applicable" without a justification tied to roles and risks is one of the most common audit findings.
Believing the certificate equals legal compliance. Customers and managers sometimes treat the certificate as proof of GDPR conformity; it is evidence of a working management system within a scope, nothing more.
A misleading scope. Excluding the products, locations or suppliers where most PII is processed makes the certificate look good but gives customers little assurance and invites challenge.
A paper inventory. A record of processing built once and never updated quickly drifts away from the real systems, so risk assessments are done on fiction.
Forgetting sub-processors. Processors that add analytics, support or AI tools without updating contracts and customer notices break the very obligations Table A.2 is about.

Best practices

Map roles per activity first. Build the inventory with a controller/processor decision for every activity, reviewed by legal and the activity owner.
Look from the individual's side. Include consequences for PII principals in risk criteria, and involve people who understand customers and staff, not only IT.
Integrate, do not duplicate. If an ISMS exists, share document control, internal audit, management review and incident processes, and keep privacy-specific risk criteria and controls on top.
Put privacy gates in delivery workflows. Add privacy by design checks and PIA triggers to the tools teams already use, such as ticket templates and release checklists.
Measure what matters. Track request turnaround, overdue retention reviews, PIA coverage of new features and supplier reviews, and report them in management review.
Use the annexes as tools. Use Annex F to drive a transition, Annex D as a legal cross-check with counsel, and Annex B to turn each control into concrete practice.
Audit real records. Internal audits should sample real requests, PIAs, contracts and logs, so that external auditors find a system that already works.

Summary and key takeaways

ISO/IEC 27701:2025 is the second edition of the international standard for a privacy information management system, published in October 2025 by ISO and IEC.
Unlike the 2019 edition, it is a stand-alone management system standard: clauses 4 to 10 follow the Harmonized Structure and it can be certified without ISO/IEC 27001.
The controller/processor distinction drives the standard; the role is decided per processing activity, and many organisations hold both roles.
Annex A holds the reference controls in three tables: A.1 for PII controllers, A.2 for PII processors and A.3 for security controls relevant to both; Annex B explains how to implement them.
Privacy risk is assessed from the point of view of PII principals as well as the organisation, and the Statement of Applicability records which controls are needed and why any are excluded.
Accredited certification follows ISO/IEC 17021-1 and ISO/IEC 27706, with a two-stage initial audit, surveillance audits and a three-year cycle; 2019 certificates must transition within the period set by accreditation bodies.
Mappings to ISO/IEC 29100, the GDPR, ISO/IEC 27018 and ISO/IEC 29151 are indicative: a PIMS supports legal compliance but does not prove it.

Reflection questions

List five processing activities in your own organisation and decide, for each one, whether it acts as PII controller, PII processor or both. Which decision was hardest, and why?
Pick one of those activities and describe two harms that could affect the people concerned. How would you rate them, and which Annex A theme would help reduce them?
If your organisation already runs another ISO management system, which of its processes could the PIMS reuse, and which would need privacy-specific changes?
Draft a one-sentence PIMS scope for your organisation. What might a customer reading the certificate wrongly assume from it, and how would you prevent that?
Imagine a product team wants to reuse customer data for a new feature. Which steps of the PIMS lifecycle should that idea pass through before any code is written?