ISO/IEC 27701:2025 Transition Plan for GDPR PIMS

The board question that exposes a privacy evidence gap

Anya, the CISO of a rapidly scaling FinTech, stared at the board meeting agenda. Tucked between revenue projections and market expansion was the item that had been consuming her week: GDPR compliance and ISO/IEC 27701:2025 readiness.

The company had a GDPR program. There was a DPO, privacy notices, data processing agreements, a DPIA template, and a process for data subject requests. Sales had already told enterprise customers that the company was moving toward an ISO/IEC 27701:2025 Privacy Information Management System, or PIMS. Product was preparing an AI-assisted analytics feature that would process customer user behaviour, support tickets, billing metadata, and account activity. A major EU customer had asked for evidence that controller and processor obligations were managed separately.

The uncomfortable truth was not that privacy documentation was missing. The problem was evidence.

The processing register did not consistently show lawful basis, retention, subprocessor dependencies, international transfers, or whether the company acted as controller or processor for each processing purpose. Supplier reviews focused on security, but not enough on privacy instructions, deletion, breach support, audit rights, and subprocessor flow-down. Engineering had security reviews, yet privacy-by-design was not always triggered when a feature changed the purpose of processing. Internal audit tested GDPR at a high level, but could not always trace an obligation to an owner, control, register, test, and management review decision.

That is the real ISO/IEC 27701:2025 transition challenge. It is not only a certificate project. It is a maturity test: can your organization operate privacy as a managed system, not as a folder of legal documents?

For GDPR-driven organizations, the answer is to extend the ISO/IEC 27001:2022 information security management system into a privacy management system that integrates PIMS scope, records of processing, privacy risk assessment, DPIAs, supplier governance, breach handling, control mapping, internal audit, and continual improvement.

Why fragmented GDPR compliance breaks under audit pressure

Many organizations treat privacy compliance as a separate workstream from information security. Legal manages contracts. IT manages encryption. Procurement manages vendors. The DPO answers subject access requests. Product teams launch features. Security handles incidents. Each function may be doing useful work, but without a single operating model, privacy evidence becomes fragmented.

This creates four recurring problems.

First, teams duplicate effort. Security and privacy risk assessments may use different methods, different scoring, and different owners.

Second, gaps appear in third-party services, cloud configurations, analytics pipelines, support tools, and new development projects because no one has a complete view of PII flows.

Third, board and customer assurance becomes difficult. A collection of disconnected policies does not prove that privacy obligations are implemented, monitored, and improved.

Fourth, modern regulatory expectations are converging. GDPR expects accountability and evidence. NIS2 expects governance, risk management, incident handling, access control, asset management, and supply chain security. DORA expects financial entities to manage ICT risk, incidents, resilience testing, third-party contracts, and exit strategies. A siloed privacy program cannot efficiently support all of them.

The stronger approach is to build the ISO/IEC 27701:2025 transition on the ISO/IEC 27001:2022 ISMS. ISO/IEC 27001:2022 provides the management system structure for context, interested parties, scope, risk assessment, risk treatment, objectives, operational planning, internal audit, management review, corrective action, and continual improvement. ISO/IEC 27002:2022 provides the control foundation for legal obligations, asset inventory, supplier relationships, cloud services, access control, logging, monitoring, deletion, masking, and privacy and protection of PII.

The transition should answer five questions:

1. What is the PIMS scope, including controller, processor, joint controller, and subprocessor roles?
2. Which processing activities, data categories, purposes, lawful bases, recipients, transfers, and retention rules are in scope?
3. Which privacy risks require DPIA, treatment, approval, and residual risk acceptance?
4. Which policies, controls, contracts, technical safeguards, and records prove GDPR accountability?
5. How will internal audit and management review confirm the PIMS is operating and improving?

Phase 1: approve the PIMS scope before rewriting policies

A strong ISO/IEC 27701:2025 transition plan does not begin with rewriting every privacy policy. It begins with governance and scope.

Your existing ISMS scope is the starting point, but the PIMS scope must explicitly identify PII processing, business units, services, systems, regions, cloud environments, suppliers, and privacy roles. The board or top management must understand why the transition matters, especially where customers, regulators, or sector obligations such as DORA depend on demonstrable privacy and resilience evidence.

Clarysec’s Privacy Information Management System Policy [PIMS Policy] makes scope approval mandatory:

[Both] Top Management MUST approve the PIMS scope in REG01 before initial PIMS implementation and within 30 days of any material change.

For transition programs using the clause numbering from the Clarysec policy library, this is the core expectation in Clause 4.1.1. It matters because implied privacy scope is one of the most common audit weaknesses. If a product line, jurisdiction, processing role, supplier, cloud region, or business process changes materially, the PIMS scope must not be left to interpretation.

The same policy also turns the transition into a managed program:

[Both] The Privacy Lead / PIMS Manager MUST record the PIMS implementation plan in REG12 before PIMS rollout or major PIMS change.

REG12 is not administrative overhead. It is the transition control board. It should show what is changing, why it matters, who owns it, which evidence is required, which risks are open, and when readiness will be tested.

Phase 2: build a register-led transition inventory

For GDPR privacy management systems, the first practical deliverable should be an evidence inventory, not a policy rewrite. Clarysec uses a register-led approach because registers convert privacy intent into auditable evidence.

The PIMS scope in REG01 connects to processing activities in REG02, control applicability in REG03, privacy risk and DPIA screening in REG04, and implementation planning in REG12.

The Data Protection and Privacy Policy - SME [SME Privacy Policy] sets the baseline:

The Privacy Coordinator must maintain a register of all personal data processing activities, including data categories, purpose, lawful basis, and retention periods

For larger environments, the Data Protection and Privacy Policy [P17 Data Protection and Privacy Policy] raises the governance expectation:

The organization shall maintain a formal Privacy Governance Framework integrated into the Information Security Management System (ISMS) to enforce this policy.

That integration is the transition principle. A processing register without risk treatment is a spreadsheet. A DPIA without control ownership is a legal memo. A supplier DPA without monitoring is a contract drawer. ISO/IEC 27701:2025 transition work should bring these artifacts into one governed PIMS.

This inventory also supports a NIST Cybersecurity Framework 2.0 style Current Profile and Target Profile. The Current Profile documents existing privacy processes, controls, and evidence. The Target Profile defines the desired ISO/IEC 27701:2025-aligned PIMS. The gap between them becomes the transition backlog.

Phase 3: map GDPR accountability into the PIMS

GDPR accountability is the backbone of privacy evidence. GDPR applies to processing in the context of an EU establishment and can also apply to non-EU controllers or processors that offer goods or services to individuals in the EU or monitor their behaviour. It defines personal data broadly, including direct and indirect identifiers. It distinguishes controllers from processors and defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

For transition planning, the important point is that GDPR is not satisfied by saying “we have security controls.” Article 5 requires lawful, fair, and transparent processing, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and demonstrable accountability. Article 6 requires a lawful basis. Article 9 adds stricter conditions for special categories of personal data. Article 25 requires data protection by design and by default. Article 28 requires processor governance. Article 32 requires security of processing.

Clarysec’s Legal and Regulatory Compliance Policy - SME [SME Legal and Regulatory Compliance Policy] gives smaller organizations a simple starting point:

The GM must maintain a simple, structured Compliance Register listing:

The enterprise Legal and Regulatory Compliance Policy [P37 Legal and Regulatory Compliance Policy] is more explicit:

All legal and regulatory obligations must be mapped to specific policies, controls, and owners within the Information Security Management System (ISMS).

That sentence is the difference between informal GDPR compliance and audit-ready privacy management. Every material GDPR obligation should map to a policy, control, owner, register field, and evidence source.

Controller and processor evidence must be separated. A controller must prove lawful basis, transparency, rights handling, purpose decisions, and retention. A processor must prove processing under documented instructions, subprocessor governance, assistance to the controller, security measures, breach notification support, and return or deletion at the end of service. If the organization acts in both roles, one generic evidence model is not enough.

Phase 4: use the SoA as the privacy control bridge

A common transition mistake is to create a standalone PIMS control spreadsheet while leaving the ISMS Statement of Applicability untouched. That creates two competing control universes.

ISO/IEC 27001:2022 requires risk treatment decisions to be reflected in the Statement of Applicability. Clarysec’s Risk Management Policy [Risk Management Policy] states:

A Statement of Applicability (SoA) shall reflect all treatment decisions and shall be updated whenever control coverage is modified.

For ISO/IEC 27701:2025 transition, the SoA becomes the bridge between the ISMS and PIMS. If a DPIA or privacy risk treatment adds encryption, data masking, deletion controls, consent mechanisms, processor due diligence, access restrictions, or DSAR workflow monitoring, the SoA and REG03 must reflect the decision.

The Zenith Blueprint: An Auditor’s 30-Step Roadmap [Zenith Blueprint] reinforces this in Step 6:

✓ Additional Controls: Are there controls outside Annex A you might include? ISO 27001
allows adding other controls in the SoA. For example, maybe you want to include
compliance with NIST CSF or specific privacy controls from ISO 27701.

Do not force privacy obligations into controls that do not fit. Add privacy-specific controls where needed, but govern them through the same risk treatment, ownership, implementation status, evidence, and audit model.

The ISO/IEC 27002:2022 controls that anchor the transition

In Zenith Controls: The Cross-Compliance Guide [Zenith Controls], two ISO/IEC 27002:2022 controls are central to the ISO/IEC 27701:2025 transition: 5.31 Legal, statutory, regulatory and contractual requirements, and 5.34 Privacy and protection of PII.

Control 5.31 is the compliance hub. It supports the identification, documentation, ownership, and review of legal, regulatory, statutory, and contractual requirements. It connects naturally to GDPR accountability, NIS2 governance, DORA ICT risk obligations, customer privacy clauses, and cloud processing commitments.

Control 5.34 is the operational privacy anchor. Zenith Controls explains the dependency clearly:

An inventory of information assets (5.9) should include PII data holdings (customer databases, HR files). This underpins 5.34 by ensuring the organization knows what PII it has and where, which is the first step to protecting it.

The control crosswalk should be used as a practical design checklist.

This is where privacy becomes operational. For each high-risk processing activity, ask: which assets hold the PII, how is it classified, who can access it, where is it transferred, what cloud services process it, what retention rule applies, what monitoring detects misuse, and what evidence proves those controls operate?

Example workflow: onboarding an AI-assisted analytics feature

Return to Anya’s FinTech. The product team wants to launch an AI-assisted analytics feature that processes user identifiers, account activity, support metadata, billing metadata, and behavioural signals. Some enterprise customers may use the outputs for workforce monitoring, which increases privacy risk.

A PIMS transition workflow should handle the launch as a controlled privacy event.

Step 1: update REG02 for processing roles and purposes

The Process Owner creates or updates the processing record. Required fields include purpose, data categories, data subject categories, lawful basis or processor instruction, retention period, systems, suppliers, recipients, transfers, and role context.

If the company is a processor for customer analytics, REG02 must show processing under customer instructions. If it also uses aggregated data to improve its own product, that separate purpose may make it a controller for secondary processing. The record must not blur the roles.

Step 2: complete REG04 screening

Clarysec’s Privacy Risk Assessment and DPIA Policy [Privacy Risk Assessment and DPIA Policy] requires:

[Both] The Process Owner / Business Owner MUST complete baseline REG04 screening for all in-scope active REG02 processing activities within 30 business days of PIMS scope approval or scope expansion.

The screening should identify monitoring, profiling, special categories, vulnerable individuals, new technology, large-scale processing, cross-border transfers, or changed purpose. If thresholds are met, a DPIA is triggered.

Step 3: perform the DPIA and define treatment

The P17 Data Protection and Privacy Policy requires:

All significant changes to systems or processes involving personal information (PII) shall require a documented Data Protection Impact Assessment (DPIA), reviewed by the Data Protection Officer (DPO).

In the Clarysec library, this is tied to Clause 5.6. The DPIA should assess risks such as excessive collection, unclear purpose, re-identification, unauthorized customer administrator access, unclear retention, and subprocessor exposure. Treatments may include field-level minimization, pseudonymization, customer configuration controls, retention defaults, stronger audit logging, DPA updates, product notices, and restrictions on model training.

Step 4: update REG03 and the SoA

The PIMS Policy requires:

[Both] The Privacy Lead / PIMS Manager MUST maintain REG03 with included controls, excluded controls, implementation status, and justification annually and within 30 days of each privacy risk treatment change.

If the DPIA adds masking for non-production analytics, logging for administrator access, deletion controls, supplier clauses, or customer configuration safeguards, REG03 and the SoA must be updated.

Step 5: prove privacy by design

The SME Privacy Policy captures the principle plainly:

Privacy by design and by default must be enforced in all new systems and services

Evidence should include the DPIA, architecture review, data minimization decision, access model, logging configuration, retention setting, test results, release approval, and post-launch review. This turns the feature launch into reusable PIMS evidence.

Supplier privacy governance in a DORA and NIS2 world

Supplier privacy governance is where many transitions fail. GDPR Article 28 requires controllers to use processors that provide sufficient guarantees and to put processor obligations into written contracts. DORA Articles 28 to 30 require financial entities to manage ICT third-party risk, maintain registers of contractual arrangements, conduct due diligence, include audit rights and exit terms, manage subcontracting, and address critical or important functions. NIS2 Article 21 requires supply chain security measures, including consideration of supplier vulnerabilities, cybersecurity practices, and secure development procedures.

ISO/IEC 27002:2022 control 5.19, Information security in supplier relationships, is the operational anchor. Zenith Controls maps this area to supplier agreements, ICT supply chain security, information transfer, compliance monitoring, acceptable use, GDPR processor obligations, NIS2 supply chain cybersecurity, DORA ICT third-party risk, NIST supplier governance, and COBIT supplier management.

For DORA-regulated financial entities, this evidence must connect to ICT third-party registers and critical or important function assessments. For NIS2 entities, the same supplier records support supply chain risk management. For NIST CSF 2.0, supplier governance aligns with the GOVERN Function, especially supply chain risk management outcomes. For COBIT 2019, supplier governance aligns with objectives such as APO10 Managed Vendors and DSS supplier-related operational controls.

Incident and breach readiness must be integrated

Privacy transition plans often overfocus on documentation and underfocus on breach handling. That is dangerous because GDPR, NIS2, and DORA all expect disciplined incident processes, even though thresholds and reporting timelines differ.

GDPR requires assessment of whether a security event caused a personal data breach and whether notification to the supervisory authority or affected individuals is required. NIS2 establishes staged reporting for significant incidents, including early warning within 24 hours, notification within 72 hours, and a final report within one month. DORA requires financial entities to detect, manage, classify, record, notify, respond to, and learn from ICT-related incidents, with staged reporting for major incidents.

NIST CSF 2.0 supports this cycle through Detect, Respond, Recover, and Govern outcomes. The transition team should ensure privacy breach decisions are embedded in the security incident workflow, not handled as a disconnected legal afterthought.

One roadmap, many compliance outcomes

The ISO/IEC 27701:2025 transition becomes more valuable when it reduces duplicated compliance work. Zenith Blueprint, Step 14, recommends cross-referencing GDPR, NIS2, and DORA so organizations can show that risk treatment and controls satisfy multiple obligations:

For each regulation, if applicable, you may create a simple mapping table (could be an
appendix in a report) that lists the regulation’s key security requirements and the
corresponding controls/policies in your ISMS.

For privacy transition planning, the mapping should be practical and evidence-led.

In Zenith Controls, ISO/IEC 27002:2022 control 5.31 supports legal and regulatory traceability across GDPR accountability, DORA compliance obligations, NIS2 governance expectations, NIST CSF 2.0 GV.OC-03, and COBIT external compliance monitoring. Control 5.34 supports GDPR Articles 25 and 32, PII lifecycle protection, cloud PII processing expectations, and privacy-aware security controls.

The result is not a simplistic “one control equals one law” model. It is a defensible evidence model where one well-designed control set supports multiple assurance needs.

How auditors will test the transition

A strong transition plan anticipates audit techniques.

An ISO management system auditor will start with scope, interested parties, legal requirements, risks, objectives, operational controls, internal audits, management reviews, nonconformities, and improvement. They will verify whether the PIMS scope is approved, whether privacy obligations are included in the compliance register, whether controls are justified in the SoA, and whether implementation evidence matches the stated scope.

A privacy auditor will sample processing records, DPIAs, DSARs, breach decisions, processor contracts, retention controls, and project onboarding. They will not accept policy intent where operating evidence is missing.

A NIST-aligned assessor will look for governance, legal and contractual obligations, target profiles, supplier risk, monitoring, response, and recovery evidence.

A COBIT 2019 auditor will focus on board oversight, compliance reporting, supplier governance, roles and responsibilities, and whether privacy risk is managed across the information lifecycle.

Clarysec’s PIMS Monitoring, Audit and Improvement Policy [PIMS Monitoring, Audit and Improvement Policy] makes the audit program mandatory:

[All] The Internal Audit / Compliance Reviewer MUST prepare a risk-based PIMS internal audit programme in REG12 annually before the first planned PIMS audit cycle.

The Audit and Compliance Monitoring Policy [Audit and Compliance Monitoring Policy] applies the same discipline at ISMS level:

A risk-based Audit Plan shall be developed and approved annually, taking into account:

For smaller organizations, the Audit and Compliance Monitoring Policy - SME [SME Audit and Compliance Monitoring Policy] keeps audit planning focused:

The plan must identify key systems and policies to be reviewed, with a focus on:

During transition, the first internal audit should not test everything. It should test the highest transition risks: incomplete processing records, missing DPIA triggers, weak supplier privacy clauses, untested breach decisions, unclear controller and processor roles, and SoA mismatch.

A practical 90-day ISO/IEC 27701:2025 transition roadmap

A realistic roadmap should be short enough to execute and structured enough to create evidence.

The 90-day target does not mean every remediation item will be closed. It means leadership should have an approved scope, a credible evidence baseline, prioritized risk treatment, focused audit results, and a management decision on readiness.

Make the transition evidence-driven

Organizations that succeed with ISO/IEC 27701:2025 transition are not the ones with the longest privacy policy. They are the ones that can prove how privacy obligations move from law to scope, from scope to processing records, from processing records to risk assessment, from risk assessment to controls, from controls to evidence, and from evidence to improvement.

Clarysec helps teams make that transition practical. Our PIMS policy set, GDPR mappings, controller and processor evidence registers, DPIA workflows, supplier privacy governance templates, breach handling materials, management review agendas, Zenith Blueprint, and Zenith Controls give CISOs, DPOs, compliance managers, auditors, and business owners a structured path from privacy intent to audit-ready operation.

If your organization is preparing for ISO/IEC 27701:2025, start this week with three actions: approve the PIMS transition scope in REG01, populate REG02 for your highest-risk service, and run the first REG04 screening. Then use Clarysec to turn that evidence set into a complete GDPR-aligned PIMS transition roadmap, ready for customers, auditors, regulators, and the board.