Organizational change — mergers of teams, transfers of activities, onboarding of external providers — often exposes gaps in access rights, unclear ownership and out-of-date documentation. A practical privacy management system should detect and document those gaps before they become operational failures or audit findings. The goal is not only to update an org chart: every change must be linked to the data involved, the controls to be updated and the evidence proving execution.
This article sets out an operational approach for handling consolidations, handovers and supplier introductions. The guidance focuses on organization and evidence; it is not legal advice.
When should a change trigger a privacy review?
Not every personnel or structural change has the same impact on personal data. Renaming a function is different from transferring an activity to another legal entity, even if people and tools stay the same.
Open a privacy review when the change affects any of these elements:
- Responsibility: a process gets a new owner or the previous owner leaves.
- Access: people, teams or consultants acquire new authorisations.
- Data flows: an activity is delegated to an external provider or to another company.
- Purpose and use: data already collected will be used for different purposes.
- Systems and repositories: applications, shared folders or databases are merged, migrated or retired.
These checks support the accountability principle of the GDPR (see Articles 5(2) and 24), which requires controllers to demonstrate compliance and to review measures when necessary.
The change record described below is an organizational tool to make decisions and actions reconstructible — it is not a form mandated by regulation.
Create a change record before moving activities or data
Within your privacy system, every change should have a unique identifier tying together the request, assessment, controls and evidence. An email titled “reorg” is insufficient if, months later, nobody can reconstruct which activities were included.
The initial record should define scope rather than replicate the company’s full reorganisation plan.
Recommended fields to capture:
- Identifier and planned date: link evidence and actions to the same event.
- Involved processes: list the activities and reference the affected data processing records.
- Parties involved: functions, legal entities and suppliers implicated by the change.
- Data and tools: categories of data, applications and archives to be checked for access and flows.
- Change coordinator: a named person responsible until closure.
- Preconditions: checks that must be completed before the transfer.
Missing information should be logged as outstanding issues with an owner and a due date. “To be verified” without assignment is not actionable.
Example: if it’s unclear who will receive employee files, record that uncertainty and assign someone to resolve it before sharing.
Capture a before-and-after snapshot
A before/after comparison is essential: a single updated list of access rights only shows the current state, not whether obsolete permissions were revoked.
Keep a focused, verifiable comparison limited to elements relevant to the change.
Compare, for example:
- Operational responsibility: current process owner vs. new owner and documented handover.
- Authorisations: users and groups enabled before vs. access maintained, revoked or newly granted.
- Record of processing: version applicable to the process vs. updated entries where applicable.
- Operational documents: procedures and instructions in use vs. approved versions for the reorganised function.
- Controls: ongoing checks and pending tasks vs. reassigned checks and continuity of execution.
Article 30 of the GDPR provides the reference for the content of processing records; your system may add a management field for the internal owner name.
To select relevant evidence, apply audit-evidence principles: identifiability, linkage to the control and ability to be verified. When producing comparison reports, avoid including unnecessary personal data.
For operational guidance on types of evidence, see /en/blog/evidenze-di-audit.
Assess impact before authorising the transfer
Assessments should answer concrete questions: who will be able to see which data, for what task, using which tools and under what limits? Merging teams can increase visibility of data even if no new systems are introduced.
For example, combining HR payroll and operational personnel administration does not mean everyone in the new team needs access to all employee records. The control focuses on actual authorisations and not merely on reporting lines.
Record the assessment outcome and any conditions required to proceed. If doubts arise about purpose, legal basis or the role of an external entity, involve the appropriate experts before execution.
A reorganisation does not automatically trigger a Data Protection Impact Assessment (DPIA). Article 35 of the GDPR links DPIAs to processing likely to result in high risks and requires review when the processing risk changes. Preserve the screening rationale, consulted documentation and any actions requested; a bare note “DPIA not required” without context does not explain how the decision was reached.
Manage handovers so responsibilities are never unattended
The riskiest phase is often the interval between the departure of the previous owner and the new owner becoming fully operational. During that gap, subject access requests, supplier checks or remediation work may be left without oversight.
A handover must include open activities, not just documents. The incoming owner needs visibility of deadlines, dependencies and outstanding decisions. A temporary owner should be assigned to cover any transition window.
In the privacy system, acceptance of responsibility should be a record separate from the mere change of a name: capture the scope received, pending tasks and resources needed to continue.
Also verify that the new owner has the authorisations required to perform checks. Assigning verification to someone who cannot access the necessary reports creates a merely formal responsibility.
Example: HR’s outgoing manager leaves while an access remediation is in progress. The successor receives the remediation plan, but the change cannot be considered complete until excess access rights are identified, revoked and verified. A signature on a handover note documents transfer but does not replace the actual tests.
Control documents shared with external parties
Reorganisations often require external advisers. Before sharing personnel files or other personal data with a consultant or law firm in another country, identify the purpose of the sharing, authorised recipients and exactly which documents are necessary.
Document how access will be managed, and how data will be returned or archived at the end of the engagement. Distinguish between a legal mandate and operational data handling: appointing external counsel does not automatically make the adviser a processor under Article 28 — that classification requires case‑by‑case assessment.
As operational evidence, retain the authorised scope of sharing, the engagement reference and checks on permissions. Temporary transitional folders should have a planned review and expiry so they do not remain broadly accessible by oversight.
Verify closure in the privacy system
Authorising a change allows execution; closure must prove the expected state has been achieved. These are distinct stages and must produce different evidence.
For access rights, verify effective permissions after the transfer, including inherited group privileges. For documents, ensure the updated version is accessible where people actually work, not only attached to the change record. For responsibilities, confirm open tasks have an operational owner.
Closure should map each initial precondition to its outcome. If a condition is unmet, the record should show that clearly rather than marking the whole change as “completed.”
Outstanding remediations are acceptable if they have an owner, a deadline and a verification criterion. Accepting residual risk does not remove applicable obligations nor does it make non‑compliant activity compliant.
Record who made each entry, when and what changed. Follow audit‑trail best practices to separate original evidence from later edits, so corrections do not erase the history of the check — see /en/blog/audit-trail-best-practices.
Case study: merging two functions
Imagine a company merges customer service and commercial administration. Both teams process customer data, but access needs for complaints, billing and operational notes differ.
A change record lists the processes involved and compares previous authorisations. The assessment determines which information is necessary for the new combined function and which must remain limited. The appointed owner coordinates updates, while test executors keep verification results.
The privacy system reconstructs the sequence: scope evaluated, access decisions made, configuration applied and verification performed.
If a legacy group continues to grant access to unnecessary documents, the test generates a finding linked to the change. A remediation is opened with the group to fix, a responsible person and a re‑test.
Closure happens only after the correction is verified, not merely after the IT ticket is sent. The evidence package stores the prior configuration reference, the initial test result and the final verification so an auditor can distinguish control design from execution.
Frequently asked questions
Which organisational changes require a privacy review? Perform a proportionate screening to see if processing, operational responsibility, recipients, authorisations or risks change. If the change is purely nominal, retain the rationale and update administrative references only.
Who should close the change record? The organisational model should identify who coordinates closure and who verifies outcomes. A privacy system should not accept the requester’s confirmation as sufficient proof when controls remain to be executed. The DPO performs duties required by their role but does not replace operational owners.
What evidence to keep for an owner change? The scope transferred, open tasks, acceptance of responsibility and verification of required authorisations. If the previous owner left the organisation, retain proof of revoked access instead of indiscriminate copies of their data.
Can a change be closed with actions still open? Distinguish completed conditions from remaining remediations. Preconditions for go‑live must not be confused with later improvements. Any open action should remain visible, assigned and verifiable according to your risk management process.
Tie changes to evidence with AuditReady
AuditReady centralises evidence with ownership, versioning and an audit trail, linked to controls, risks and privacy records. To see how to organise proof of a change within a GDPR workflow, request the AuditReady demo for privacy management at /auditready/lp/gdpr.
audit-ready evidence pack demo / not legal advice