Multi Purpose DPIAs – one DPIA to rule them all

A Data Protection Impact Assessment (DPIA) doesn’t always need to focus on a single, isolated processing activity. In many organisations—especially those with interconnected systems and overlapping workflows—it makes sense to complete one DPIA that covers multiple related processing activities, provided it remains clear, usable, and defensible.

Done properly, a “multi-activity DPIA” reduces duplication, improves consistency, and creates a more realistic view of how data moves through the organisation.

Below is a practical guide to when a DPIA can cover multiple processing activities, and how to structure it so it stays GDPR-compliant and operationally useful.

• if you would like to explore what a DPIA is and when it is needed before reading further (and get a free template) click here.

1. Can one DPIA cover multiple processing activities?

Yes. The UK GDPR does not require “one DPIA per activity” in a rigid sense. Instead, it requires one whenever processing is likely to result in high risk, and expects organisations to assess the risks in a structured, documented way.

A single DPIA can cover multiple processing activities when they are:

• part of the same project, programme, or system, or
• operationally linked, meaning they share data sources, tools, purposes, or outputs, or
• implemented together, such as a rollout across departments or sites, or
• variations of the same processing pattern, such as a standard model deployed repeatedly.

Good examples of multi-activity DPIAs

• A new HR platform covering recruitment, onboarding, payroll integration, absence management, and performance tools
• A clinical system used across multiple services (appointments, clinical notes, referrals, imaging, patient messaging)
• A marketing and CRM implementation that covers email marketing, segmentation, analytics, and customer profiling
• A security programme combining CCTV, access control, visitor logs, and incident reporting
• A shared data warehouse that ingests data from multiple systems for reporting and planning

In each case, separate DPIAs might create fragmented risk thinking. A single impact assessment gives a more accurate “whole system” picture.

2. When you shouldn’t use one DPIA for everything

A multi-activity DPIA becomes risky when it turns into a sprawling “privacy novel” that nobody can navigate.

Avoid combining processing activities into one DPIA if:

• the purposes are unrelated (e.g., marketing + occupational health + safeguarding)
• different lawful bases apply in complicated ways
• different populations are affected (e.g., employees vs children vs patients)
• the risk profiles differ dramatically
• different teams own the processing with no shared governance
• the DPIA becomes too generic to be meaningful

A DPIA must remain specific enough to show genuine risk assessment, not just broad statements of intent.

A good rule: if the risks, stakeholders, or legal routes differ significantly, split it.

3. The key GDPR requirement: clarity and necessity

When you cover multiple activities in one DPIA, you must still demonstrate:

• what processing happens,
• why it is necessary,
• what risks it creates, and
• what controls mitigate those risks.

This matters because regulators expect DPIAs to show real decision-making. They look for evidence that you identified risks before processing began and made design choices to reduce harm.

4. How to structure a DPIA that covers multiple processing activities

A strong multi-activity DPIA works like a well-organised technical dossier: one core narrative, with modular sections for each activity.

Here is a recommended structure.

A) Executive Summary (1 page)

This should give senior stakeholders a fast understanding of what’s happening.

Include:

• what the project/programme is
• why a DPIA is required (high-risk triggers)
• which processing activities it covers (a short list)
• headline risks (top 5)
• whether residual risk remains high
• whether consultation with the ICO is required (rare, but possible)

B) Scope and Processing Map

This section defines the boundaries.

Include:

• which business areas/services are included
• which systems and tools are in scope
• the data subjects that are in scope (staff, patients, customers etc.)
• exclusions (what is not covered and why)
• high-level data flow diagram (recommended)

For multi-activity DPIAs, this section prevents confusion later.

C) Activity Register (the “index” of processing)

This is the heart of the multi-activity approach: a table listing each activity, with consistent descriptors.

A typical register might include:

This allows you to:

• keep one DPIA document, but
• preserve specificity and traceability.

D) Description of Each Processing Activity (repeatable mini-sections)

For each activity, include a structured mini-profile such as:

Activity X: [Name]

What happens: short description of the processing
Purpose: why it exists
Necessity and proportionality: why you need this data and method
Lawful basis (Article 6): chosen basis + brief justification
Special category basis (Article 9): if applicable
Key data fields: the essentials (not everything)
Data sources: collected directly, imported, third party etc.
Recipients: internal teams, processors, partners
Retention: how long and why
International transfers: yes/no and safeguards
Automation/profiling: yes/no and impact

This keeps each activity discrete and auditable.

E) Necessity and Proportionality Assessment (overall + per activity)

This section demonstrates that the organisation has not collected data “because it might be useful”.

Cover:

• data minimisation
• purpose limitation
• access control principles
• transparency measures
• whether less intrusive alternatives exist
• how you ensure fairness, especially for vulnerable groups

In multi-activity DPIAs, include:

• a general proportionality statement, then
• any activity-specific proportionality issues (e.g., monitoring, profiling, biometrics).

F) Risk Assessment Methodology

You need a consistent way to score risk across activities.

Set out:

• your scoring approach (likelihood × impact)
• what “high risk” means in your organisation
• risk categories (privacy harm, security harm, discrimination, distress, loss of control)

This allows different teams to apply the same yardstick.

G) Risk Register (central, consolidated)

This is where multi-activity DPIAs become powerful.

Create one master risk register, but tag each risk to relevant activities.

Example columns:

This avoids repeating identical risks (e.g., access control weaknesses) across multiple mini-DPIAs.

H) Controls and Safeguards (technical + organisational)

List safeguards that apply across the programme:

Organisational safeguards

• role-based access controls and approvals
• staff training and confidentiality rules
• supplier contracts and processor clauses
• DPIA governance and sign-off
• retention schedule and disposal processes
• audit trails and monitoring of access

Technical safeguards

• encryption at rest/in transit
• MFA
• logging and alerting
• segmentation and least privilege
• pseudonymisation (where appropriate)
• secure backups and recovery testing

Then add activity-specific controls where needed, such as:

• suppression lists for marketing objections
• stricter access rules for occupational health data
• masking/redaction for analytics outputs
• extra safeguards for children or vulnerable people

I) Transparency Plan (privacy information and communications)

Multi-activity processing often affects people in different ways, so include:

• which privacy notices need updating
• whether layered notices are required
• just-in-time notices (e.g., at data collection points)
• staff briefings or FAQs if monitoring changes occur

Transparency often becomes a risk control in its own right.

J) Residual Risk Decision and DPIA Sign-Off

Once controls are applied, assess whether risk remains “high”.

Include:

• who reviewed the assessment (DPO/IG lead/security lead)
• what was accepted, rejected, or modified
• whether any risks were escalated
• formal sign-off by a senior accountable owner

If high residual risk remains, GDPR expects you to consider consultation with the ICO before proceeding.

K) Implementation Plan and Review Schedule

A DPIA is not complete when it is written. It is complete when it is implemented.

Include:

• action plan with owners and deadlines
• go-live checkpoints
• review triggers (system changes, new data sharing, incidents)
• scheduled review dates (e.g., 6 months, then annually)

Remember to add a version control section so the document remains current.

5. A practical model: “Umbrella DPIA + annexes”

One of the most robust approaches is:

• Umbrella document for shared context, governance, and risk controls
• Annex A, B, C… for each processing activity, with its specific details

This structure works well because:

• leadership sees the big picture, and
• operational teams get activity-level clarity.

It also helps when you need to update only one annex later, without rewriting the whole assessment.

6. Key benefits of a multi-activity DPIA

When structured properly, a multi-activity DPIA delivers:

• consistency in lawful basis selection and risk scoring
• less duplication and fewer contradictory assessments
• better system-wide risk visibility
• more credible accountability evidence
• faster onboarding for new teams, because the model already exists

It also supports better procurement decisions, because you can apply one set of privacy requirements across the programme.

7. Key pitfalls to avoid

To keep your DPIA credible, avoid:

• making it too generic (“we will keep data secure”)
• listing controls without linking them to risks
• combining unrelated processing activities just for convenience
• failing to assign owners and deadlines
• never reviewing it after go-live
• treating it as a form rather than a decision record

A DPIA must show thought. It should read like governance, not marketing.

Final thought

A DPIA can absolutely cover multiple processing activities—but only if it stays structured, specific, and auditable. The best approach is an umbrella DPIA supported by a clear activity register, a consolidated risk log, and modular annexes.

That way, you gain efficiency without losing the precision GDPR expects.