Organisations that hold ISO/IEC 27001 certification often assume it proves they protect personal data, but an information security management system says nothing about lawful purpose, consent, data subject rights or how a processor follows its customer's instructions. ISO/IEC 27701 fills that gap with requirements for a privacy information management system (PIMS) covering both PII controllers and PII processors. The second edition, published on 14 October 2025, turned the standard from an extension of ISO/IEC 27001 into an independent management system standard, and accredited certificates under the 2019 edition now have a transition deadline. This guide explains the structure of the standard, the controller and processor controls, how it relates to ISO/IEC 29100, ISO/IEC 27001 and GDPR, and how to run a gap analysis, build a statement of applicability and reach certification. It is written for CISOs, data protection officers, GRC leads and security architects. ISO text is copyright, so this page describes structure and confirmed facts only.
Key takeaways
- ISO/IEC 27701:2025 is standalone. ISO describes it as "an independent management system standard (MSS)", so a PIMS no longer has to sit on top of a certified ISMS, although most organisations will still integrate the two.
- Your role decides your controls. Controllers and processors carry different obligations; an organisation that is both must scope and justify each role separately in its statement of applicability.
- Transition has a hard end date in the UK. UKAS expects certification bodies to have moved all certified clients to the 2025 edition by 31 October 2028, following consensus in the IAF working group.
- Certification is evidence, not GDPR compliance. A 27701 certificate supports accountability under GDPR Article 5(2) and processor due diligence under Article 28, but it is not an approved certification mechanism under Article 42 by itself.
- Identity carries much of the evidence. Who and what can read PII, including service accounts, integrations and AI agents, is a common gap between the documented PIMS and reality.
What ISO/IEC 27701 is and what changed in 2025
A privacy information management system is the set of policies, roles, processes, controls and records an organisation uses to manage personally identifiable information (PII) responsibly and in line with privacy law. ISO/IEC 27701 specifies requirements for establishing, implementing, maintaining and continually improving that system, and it applies to any organisation that collects, processes, stores or controls PII, public, private or not for profit. It is published by ISO/IEC JTC 1/SC 27, which also owns ISO/IEC 27001.
The first edition, ISO/IEC 27701:2019, was titled as an extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management. Its requirements were written as additions to 27001 clauses and 27002 controls, so it could only be certified alongside an ISMS. That edition was withdrawn on 14 October 2025, the day the second edition appeared.
| Aspect | ISO/IEC 27701:2019 | ISO/IEC 27701:2025 |
|---|---|---|
| Status | Withdrawn 14 October 2025 | Current, second edition, 64 pages |
| Nature | Privacy extension to ISO 27001 and ISO 27002 | Independent management system standard |
| Title wording | "Requirements and guidelines" | "Requirements and guidance" |
| Dependency on an ISMS | Required: PIMS built on ISO/IEC 27001 | Not required; designed to align with an existing ISO/IEC 27001 system |
| Main body | Clauses 5 to 8 adding privacy requirements and guidance to 27001 and 27002 | Management system clauses in the harmonised structure used by other ISO management system standards |
| Controls | Annex A (controller) and Annex B (processor), with 27002 security controls applied through clause 6 | Annex A tables for controllers, for processors and for controls that apply to both, with implementation guidance in a separate annex |
| Certification body standard | ISO/IEC TS 27006-2:2021 | ISO/IEC 27706:2025, aligned with ISO/IEC 17021-1 |
In practice, a processor with no ISO/IEC 27001 certificate can now certify a PIMS directly, and an organisation with both can run one integrated system with a shared risk process, internal audit and management review.
How the standard is structured
The 2025 edition follows the harmonised structure common to ISO management system standards, so ISO/IEC 27001 users will recognise it.
- Context of the organisation: determine your role as PII controller, PII processor or both, the applicable privacy legislation, contracts and interested parties, and the scope of the PIMS.
- Leadership: a privacy policy, top management commitment and assigned roles.
- Planning: privacy risk assessment and treatment, covering risks to PII principals as well as to the organisation, privacy objectives and the statement of applicability.
- Support and operation: resources, competence, awareness, documented information and running the planned processes and controls.
- Performance evaluation and improvement: monitoring, internal audit, management review, nonconformity and corrective action.
- Annex A (normative): the reference control sets, split by role, which the statement of applicability is checked against.
- Informative annexes: implementation guidance for the controls and mappings to other frameworks and legislation, including GDPR.
The 2019 edition's annexes are still worth knowing because many existing PIMS documents reference them: Annex A held the additional controls for PII controllers, Annex B those for PII processors, Annex C mapped to ISO/IEC 29100, Annex D to GDPR, Annex E to ISO/IEC 27018 and ISO/IEC 29151, and Annex F explained how to apply the standard to ISO/IEC 27001 and 27002. When you transition, re-reference your control register and statement of applicability to the new numbering rather than keeping 2019 identifiers.
PII controller and PII processor controls
The single most important scoping decision is role. A controller determines the purposes and means of processing; a processor acts on a controller's documented instructions. Many organisations are both: a SaaS provider is a controller for its own staff and marketing data and a processor for the data its customers upload. The control themes below follow the four groups used in the 2019 edition (A.7.2 to A.7.5 for controllers, B.8.2 to B.8.5 for processors), which carry through in substance to the 2025 tables.
| Control theme | PII controller controls | PII processor controls | Typical evidence |
|---|---|---|---|
| Conditions for collection and processing | Identify and document purposes and lawful basis, consent records, privacy impact assessment, contracts with processors, joint controller arrangements, records of processing | Customer agreement covers the processor's role, processing only on documented instructions, records of processing carried out for each customer | Record of processing activities, DPIA register, data processing agreements |
| Obligations to PII principals | Privacy notices, mechanisms to withdraw consent, access, correction, erasure, objection and portability, automated decision-making information | Help the customer meet requests from PII principals within agreed timescales | DSAR log and response times, notice versions, request tooling |
| Privacy by design and by default | Limit collection and processing, accuracy, minimisation objectives, de-identification and deletion at the end of processing, retention, transmission controls | Temporary files, return, transfer or disposal of PII at contract end, transmission controls | Design review records, retention schedule, deletion certificates |
| Sharing, transfer and disclosure | Transfer basis between jurisdictions, records of transfers and disclosures to third parties | Disclose transfer locations, notify of legally binding disclosure requests, disclose and obtain agreement for subprocessors, notify changes | Transfer impact assessments, subprocessor list, change notifications |
| Security controls for both roles | Information security controls applied to PII, such as access control, encryption, logging, supplier security and incident management, including breach notification duties | Access reviews, encryption standards, incident and breach register | |
Decision guidance: a pure processor (for example a payroll bureau or cloud host) can exclude most controller controls with a one-line justification in the statement of applicability, but should expect auditors and customers to probe the processor controls on subprocessors, instructions and return or deletion of data hard. A controller that outsources heavily should treat contracts with processors as a high-risk control and test it, not just file the agreements. See the Third-Party Risk Management Guide.
ISO/IEC 29100 and the privacy principles
ISO/IEC 29100 is the privacy framework behind the 27701 control set. The current edition, ISO/IEC 29100:2024, specifies common privacy terminology, defines the actors and their roles in processing PII (PII principal, PII controller, PII processor and third party), describes privacy safeguarding considerations and references known privacy principles. It is not a certifiable management system, so organisations cite it in policies and training rather than audit against it.
Each of the eleven ISO/IEC 29100 principles should trace to at least one PIMS control and one piece of evidence:
- 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
- Privacy compliance
ISO 27701 vs ISO 27001, and the mapping to GDPR
ISO/IEC 27001 protects information of all kinds against confidentiality, integrity and availability risk. ISO/IEC 27701 asks a different question: is PII processed lawfully, fairly and as people were told, by controllers and processors who can prove it? The two share management system mechanics, which is why the integrated route is cheaper for most organisations already certified to 27001. See the ISO 27001 Certification Guide.
| GDPR requirement | Where it lands in a PIMS | Owner in most organisations |
|---|---|---|
| Art. 5(2) accountability, Art. 24 controller responsibility | PIMS policy, roles, management review, internal audit | DPO with the PIMS owner |
| Art. 25 data protection by design and by default | Privacy by design controls, design review gates | Engineering and product |
| Art. 28 processors | Contracts with processors (controller), processor controls on instructions and subprocessors | Procurement, legal, security |
| Art. 30 records of processing | Records of processing for controller and processor roles | Privacy office. See the Data Mapping and ROPA Guide. |
| Art. 32 security of processing | Security controls for both roles, aligned with ISO/IEC 27002:2022 | Security |
| Art. 33 and 34 breach notification (72 hours to the authority) | Incident management with PII breach criteria and records | Security incident response with DPO |
| Art. 35 DPIA | Privacy impact assessment control and risk process. See the DPIA Guide: Running a Data Protection Impact Assessment. | Privacy office |
| Art. 15 to 22 rights of data subjects | Obligations to PII principals | Privacy operations |
| Chapter V international transfers | Sharing, transfer and disclosure controls | Legal |
Two cautions. First, the mapping annex in the standard is informative, and no mapping replaces legal analysis of your own processing. Second, GDPR Article 42 certification requires criteria approved by a supervisory authority or the European Data Protection Board; an accredited 27701 certificate does not become an Article 42 certificate on its own. It does, however, give controllers useful evidence when they assess a processor's "sufficient guarantees" under Article 28(1). For the wider legal picture see the GDPR Compliance Guide for Security Teams.
ISO 27701 implementation: gap analysis and statement of applicability
The order below front-loads the decisions that are expensive to change later.
- Decide role and scope. List each processing activity and mark controller, processor or joint controller. Define the PIMS scope by legal entity, service, location and data category. A scope that excludes the customer-facing product while certifying head office will not satisfy customers.
- Run the ISO 27701 gap analysis. Assess every management system clause and every Annex A control in scope as met, partly met or not met, with the evidence you would show an auditor. If you hold 27001, reuse its evidence where the requirement is shared and focus effort on purpose, lawful basis, rights handling, processor obligations and transfers.
- Extend the risk assessment. Add risks to PII principals (loss of confidentiality, unexpected use, inability to exercise rights) alongside organisational risk. Feed DPIA outputs into the same register.
- Build the ISO 27701 statement of applicability. For every Annex A control record whether it is included, the justification for inclusion or exclusion, and its implementation status. Keep controller and processor controls in separate sections so the role logic is visible. Exclusions must follow from scope and role, not from effort.
- Close gaps by risk. Typical early work: a complete record of processing, data processing agreements with every processor, a DSAR process with tracked deadlines, a retention schedule backed by automated deletion and a subprocessor register.
- Operate before you audit. Run the PIMS for at least one full cycle of internal audit and management review. Certification bodies look for records showing the system works, not just documents.
- Test, then certify. A mock audit catches scope and SoA weaknesses cheaply. If a new control fails in operation (for example an automated deletion job removing records still under legal hold), roll back to the previous procedure, raise a corrective action and record the nonconformity rather than hiding it.
Small vs large organisations: a small processor can run the PIMS from a single register and SoA with one owner, provided responsibilities are documented. Large groups usually certify one entity or service first, then extend scope.
Certification, audit and transition
An ISO 27701 audit follows the familiar ISO pattern: a stage 1 audit reviews documentation, scope and readiness; a stage 2 audit tests implementation and effectiveness by sampling records, interviewing staff and observing controls; surveillance audits follow in the second and third years, with recertification at three years. ISO/IEC 27706:2025, published the same day as 27701:2025, replaced ISO/IEC TS 27006-2:2021 as the requirements standard for bodies that audit and certify PIMS. According to UKAS, it adds competence requirements for auditors and decision-makers and provides audit duration and scope criteria for controller and processor roles.
| Date | Transition milestone (UKAS technical bulletin) |
|---|---|
| 14 October 2025 | ISO/IEC 27701:2025 and ISO/IEC 27706:2025 published; 27701:2019 withdrawn |
| 1 May 2026 | UKAS assessment of certification bodies for the transition begins |
| December 2026 | Certification bodies submit their transition gap analysis to UKAS |
| 31 October 2027 | UKAS to have transitioned all accredited certification bodies |
| 31 October 2028 | Certification bodies to have transitioned all certified clients |
Outside the UK, check your certification body's own transition policy, since accreditation bodies apply the IAF consensus locally. For an ISO 27701 transition, run a delta gap analysis against the new clauses and Annex A tables, update the SoA, decide whether to keep the PIMS integrated with the ISMS or certify it separately, and plan the transition audit into a surveillance or recertification visit to avoid an extra audit.
Choosing a certificate route: keep an integrated ISMS and PIMS certificate if customers ask for both. Choose a standalone PIMS certificate if you are a processor without an ISMS, or your ISMS scope is narrower than the services that process customer PII.
Where identity fits
Most PIMS controls depend on knowing which identities can read, change, export or delete PII, and human users are only part of the answer. Service accounts behind data pipelines, API keys used by integrations, OAuth grants to SaaS tools and AI agents with retrieval access all process PII, and each is a potential undisclosed recipient. Scope them in the record of processing and the access review process, give each one an owner and least-privilege access to the data it needs, and remove access when the processing purpose ends. The Coinbase insider breach shows why access to customer records by support staff needs monitoring as well as granting. See the Identity Data Privacy and Consent Guide.
Measuring the PIMS and framework mapping
Log access to PII stores so you can answer "who accessed this person's data and why", and track these measures:
- Processing coverage: percentage of systems holding PII that appear in the record of processing with purpose, lawful basis and retention set.
- Rights handling: percentage of data subject requests closed within the statutory deadline, and the median response time. See the DSAR Guide: Handling Data Subject Requests.
- Processor assurance: percentage of processors and subprocessors with a current agreement and an assessment in the last 12 months.
- Retention adherence: records past their retention date that have not been deleted or anonymised.
- Access hygiene: PII-access entitlements, human and non-human, reviewed on schedule, and orphaned accounts removed.
- Corrective action closure: audit nonconformities closed by their due date.
| PIMS area | ISO/IEC 27001:2022 Annex A | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| Legal and privacy requirements | 5.31 Legal, statutory, regulatory and contractual requirements; 5.34 Privacy and protection of PII | GV.OC-03 | PT-2 Authority to process PII, PT-3 PII processing purposes |
| Records and inventory of PII | 5.9 Inventory of information and other associated assets | ID.AM-07 | PM-5(1) Inventory of PII |
| Notice and rights | 5.34 | GV.OC-03 | PT-5 Privacy notice |
| Retention and deletion | 8.10 Information deletion; 5.33 Protection of records | PR.DS-01 | SI-12 Information management and retention |
| Minimisation and de-identification | 8.11 Data masking | PR.DS-01, PR.DS-10 | SI-12, PM-25 Minimisation of PII used in testing, training and research |
| Processors and subprocessors | 5.19 to 5.22 supplier controls | GV.SC | SA-9 External system services |
| PII breach handling | 5.24 to 5.28 incident management | RS.MA, RS.CO | IR-8, IR-6 |
For the full Annex A control set see the ISO 27002 Controls Guide.
Common failure patterns
- Role confusion: declaring the organisation a processor for a service where it actually decides purposes (analytics, product improvement, AI training on customer data). Regulators look at what you do, not what the contract says.
- A paper SoA: excluding controller controls such as consent records or privacy notices without a role-based justification, or marking controls implemented that have never produced a record.
- Retention without deletion: a retention schedule that no system enforces, so backups, logs and analytics copies keep PII indefinitely.
- Subprocessor drift: new SaaS tools and AI services adopted by teams without updating the subprocessor list or notifying customers, which breaks processor obligations immediately.
- Machine access left out of scope: access reviews that cover staff but not the service accounts, API keys and integrations that bulk-read PII. Third-party access is a recurring theme in UK retail incidents such as the Marks and Spencer cyberattack.
- Late transition: leaving the move to the 2025 edition to the last visit before October 2028, then reworking the SoA under audit pressure.
Practitioner checklist
- Buy ISO/IEC 27701:2025 and ISO/IEC 29100:2024 and record the edition used in PIMS documents.
- Classify every processing activity as controller, processor or joint controller, and set the PIMS scope to match the services customers buy.
- Run a gap analysis against all management system clauses and Annex A controls, reusing ISO 27001 evidence where requirements are shared.
- Extend the risk register with risks to PII principals and link DPIA outcomes to it.
- Build the statement of applicability with separate controller and processor sections and a justification for every exclusion.
- Bring service accounts, API keys, integrations and AI agents that touch PII into the record of processing and access reviews.
- Automate retention and deletion, including backups and analytics copies, and test it.
- Agree a transition date with your certification body well before 31 October 2028 and update control references to the 2025 numbering.
- Track the six measures above and present them at management review.
Standards and references
- ISO: ISO/IEC 27701:2025 Privacy information management systems, Requirements and guidance
- ISO: ISO/IEC 27701:2019 Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management (withdrawn)
- ISO: ISO/IEC 29100:2024 Privacy framework
- ISO: ISO/IEC 27706:2025 Requirements for bodies providing audit and certification of privacy information management systems
- UKAS: Transition arrangements for privacy information management systems
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
Related NHI Mgmt Group resources: Privacy Programme Guide for Security Teams · Privacy Programme Maturity Model · ISO 27001 Certification Guide · ISO 27002 Controls Guide · GDPR Compliance Guide for Security Teams