GDPR DPIA: when to start, how to conduct it and what to deliver

DPIA: definition and obligations

A DPIA, or Data Protection Impact Assessment, is the tool used to assess risks to individuals before implementing potentially sensitive processing. A DPIA is too often seen as a legal formality. In reality, it is a decision-making tool. When conducted properly, it helps you balance business objectives, technical feasibility and an acceptable level of risk.

The principle is simple: before deploying high-impact processing, you document the context, assess the risks, define mitigation measures and decide whether the residual risk is acceptable. You keep a record of decisions and their rationale. This approach is very similar to quality management or project risk management. That is why a DPIA fits naturally into business-side IT project management.

In public organisations, a DPIA is often required for processing involving large volumes, special categories of data or decisions that have a significant effect on service users. In SMEs and mid-sized companies, the most common cases involve HR programmes, customer relationships, video surveillance, behavioural analysis or the interconnection of several cloud tools.

The obligation is not "punitive". It protects your organisation against design errors that become costly at the end of a project: late reconfiguration, suspension of use, user friction and reputational risks. It also helps professionalise discussions between business teams, the IT department, legal, security and senior management.

Cases requiring a DPIA

The right approach is to consider combinations of criteria. A DPIA is generally required when processing combines several risk factors: systematic evaluation of individuals, automated decisions, monitoring, sensitive data, matching datasets, large-scale processing or a high impact in the event of an incident.

For example, an internal HR scoring project, even without artificial intelligence, may require a DPIA if it relies on detailed individual data and influences career management decisions. Similarly, a citizen portal combining strong authentication, usage histories and personal circumstances data may require a DPIA, depending on the extent of the processing.

The best way to avoid omissions is to introduce a screening process very early, during project scoping. A questionnaire of 10 to 15 questions is often enough to guide the decision: DPIA required, recommended or unnecessary. This decision must be recorded in your processing register and project documentation.

A six-step methodology

Step 1 - Define the processing and its purpose

Precisely define the business need, functional scope, stakeholders and affected populations. Avoid overly broad wording. A well-drafted purpose is a safeguard in itself: it limits opportunistic uses and clarifies the expected controls.

Step 2 - Map data and data flows

Identify data categories, their sources, the transformations applied, recipients and potential transfers. This step must include interfaces, exports, logs and often-overlooked batch processing. Without data flow mapping, your risk analysis will remain incomplete.

Step 3 - Assess necessity and proportionality

Ask the central question: are you collecting only what is necessary to achieve the objective? Are less intrusive alternatives available? This is often the most valuable step because it can simplify processing before you invest in technical controls.

Step 4 - Assess risks to individuals

Build a clear matrix covering: scenario, severity, likelihood, initial score, proposed measures and residual score. Consider practical consequences: discrimination, exclusion from a service, loss of confidentiality, identity theft, reputational harm and administrative stress. A DPIA examines risks to individuals, not only to the organisation.

Step 5 - Define and prioritise measures

Combine technical, organisational and contractual measures: data minimisation, pseudonymisation, granular access management, export restrictions, audit logs, periodic reviews, processor clauses and user training. Prioritise them by impact and effort. Each measure must have an owner and a target date.

Step 6 - Approve, decide and monitor

The final decision can take one of three forms: authorised launch, conditional launch or suspension pending additional measures. This decision must be formally approved. Monitoring should then be integrated into the project committee: the DPIA does not end when the document is signed; it continues throughout implementation and operation.

Expected deliverables and audit evidence

A robust DPIA file contains: a scoping document, data flow map, necessity and proportionality assessment, risk matrix, treatment plan, formal decision and review records. Auditors are not looking for formal perfection. They look for consistency between identified risks, decisions made and measures actually implemented.

In practical terms, you must be able to demonstrate:

• The date and context of the assessment.
• The stakeholders involved.
• The assumptions used.
• The trade-offs made.
• Outstanding actions and how they are managed.

This ability to provide evidence is an operational advantage. It makes discussions with enterprise customers, authorities, cyber insurers and institutional partners more efficient. It also strengthens internal maturity because teams better understand why certain rules exist.

How to integrate a DPIA into business-side IT project management

The most common mistake is starting the DPIA too late, once technical choices have already been finalised. In that situation, the assessment becomes defensive and generates rework costs. Best practice is to integrate it into the IT project lifecycle from the scoping phase onwards.

During the pre-project phase, the screening questionnaire determines whether a DPIA is needed. During the design phase, data protection requirements are integrated into the backlog and acceptance criteria. During acceptance testing, the controls resulting from the DPIA are verified. During the operational phase, quarterly monitoring checks for deviations.

This approach creates a shared language between business teams, the IT department and compliance. It reduces last-minute conflicts and helps keep schedules on track. It is particularly effective for ERP, HR, public service relationship, data platform and portal modernisation programmes.

Post-DPIA action plan template

An effective post-DPIA plan should fit on one actionable page. For each action, it must include: objective, owner, deadline, dependencies, completion indicator and expected evidence. Avoid abstract wording such as "strengthen security". Use measurable actions instead: "enable MFA for all administrator profiles by 30 June", "remove unlogged exports", or "implement an access log for table X".

Recommended structure:

• Quick wins, 0-30 days: simple corrections with high impact.
• Stabilisation, 30-90 days: foundational controls and documentation.
• Industrialisation, 90-180 days: automation, monitoring and training.

Add a short monthly review and a high-level quarterly review. This schedule maintains momentum and prevents the DPIA from becoming a paper exercise.

Applying a DPIA to an HR project

For a cloud-based HR tool covering appraisals, mobility and training plans, a DPIA can examine risks to individuals with business teams, IT, HR, employee representatives and the Data Protection Officer.

The assessment should document purposes, necessary data fields, access rights, retention periods and logging of access to sensitive information.

The action plan records the selected safeguards, their owners and the validation conditions for the project to proceed.

Quick FAQ

Are DPIAs only for large organisations?

No. SMEs and mid-sized companies may also be affected whenever processing presents a high risk to individuals.

Must the DPIA be redone after every change?

Not in full. Conduct an impact review after each significant change and update the relevant sections.

Who signs off the final decision?

Senior management or the controller, informed by assessments from business teams, the IT department, security and the Data Protection Officer.

Learn more

You can complement this guide with our GDPR consulting page, then align your projects through business-side IT project management. If your requirements include operational security, also see Cybersecurity. To discuss support for your project, contact us via Contact OLING.