DPIA Workflows

A Data Protection Impact Assessment (DPIA) is a systematic process for identifying and minimising the data protection risks of a project, system, or processing activity. Article 35 of the GDPR makes DPIAs mandatory for processing that is "likely to result in a high risk to the rights and freedoms of natural persons". GDPR4All's DPIA module guides you through every step — from scoping the assessment and identifying risks to securing formal approval from your organisation's decision-makers.

When Is a DPIA Required?

Article 35 specifies that a DPIA is required when processing is likely to result in high risk. The GDPR and supervisory authority guidance identify several scenarios where a DPIA is typically necessary:

Systematic and extensive profiling with significant effects on individuals (e.g., credit scoring, automated hiring decisions).
Large-scale processing of special category data such as health records, biometric data, or criminal offence data.
Systematic monitoring of publicly accessible areas on a large scale (e.g., CCTV networks).
New technologies — when deploying technology that has not been used before in your context, the risks may be unknown and a DPIA helps identify them.
Automated decision-making with legal or similarly significant effects on individuals.
Large-scale processing — any processing that affects a large number of data subjects, involves a large volume of data, or covers a wide geographical area.
Combining datasets — merging data from different sources in ways that exceed the reasonable expectations of the data subjects.

When in doubt, conduct a DPIA. It is always better to assess risks proactively than to discover them after a breach or complaint.

Creating a DPIA

Navigate to Compliance > DPIAs and click New DPIA. The creation form is organised into four sections to ensure a thorough assessment.

Section 1: Basic Information

Title — a clear, descriptive name for the assessment (e.g., "DPIA for Customer Loyalty Programme").
Description — a summary of the processing activity being assessed, its objectives, and why a DPIA is being conducted.
Assessor — the person conducting the assessment.

Section 2: Processing Details

Processing description — a detailed account of how personal data will be collected, used, stored, and shared.
Necessity and proportionality — explain why this processing is necessary and why it is proportionate to the purpose. This is where you demonstrate that you have considered less intrusive alternatives.

Section 3: Linked Processing Activities

Select one or more processing activities from your ROPA to link to this DPIA. This connection is important because:

It ties the risk assessment to the specific data flows documented in your ROPA.
It creates an audit trail between your processing register and your impact assessments.
A DPIA must have at least one linked ROPA activity before it can be submitted for review. This requirement ensures that every DPIA is grounded in a documented processing activity.

Section 4: Consultation

Document any consultation undertaken — with data subjects, your DPO, or other stakeholders — and record their input. The GDPR encourages seeking the views of data subjects where appropriate.

Risk Assessment

After creating the DPIA, you can add individual risk items from the DPIA detail page. Each risk item captures:

Risk category — GDPR4All provides preset categories (e.g., unauthorised access, data loss, excessive collection, insufficient transparency, inadequate security, unlawful transfer) or you can define your own.
Risk description — what could go wrong and what the impact would be on individuals.
Likelihood — scored from 1 (very unlikely) to 5 (almost certain).
Impact — scored from 1 (negligible) to 5 (severe).
Risk score — automatically calculated as likelihood multiplied by impact, giving a score from 1 to 25.
Mitigation measures — the controls, safeguards, or changes you will implement to reduce the risk.
Residual risk — the risk level remaining after mitigation measures are applied.

The 5x5 Risk Matrix

GDPR4All visualises your risk items on a 5x5 risk matrix — a grid with likelihood on one axis and impact on the other. Each cell is colour-coded:

Green (1-4) — low risk. The processing can proceed with standard safeguards.
Yellow (5-9) — medium risk. Additional controls should be considered.
Orange (10-14) — high risk. Significant mitigation measures are required.
Red (15-25) — critical risk. The processing should not proceed without substantial changes, or you may need to consult the supervisory authority.

Hovering over a cell in the matrix shows a tooltip with the risk items that fall in that position. This visualisation makes it easy to communicate the risk profile of a processing activity to stakeholders and senior management.

Overall Risk Level

GDPR4All automatically computes an overall risk level for the DPIA based on the highest-scoring risk item. This overall level is synchronised every time you add, edit, or delete a risk item, ensuring it always reflects the current state of the assessment.

Approval Workflow

DPIAs in GDPR4All follow a structured approval workflow:

Draft

Every DPIA starts in Draft status. While in draft, you can freely edit all fields, add and modify risk items, and link additional ROPA activities. Take the time to make the assessment as thorough as possible before submitting it for review.

Under Review

When you are satisfied that the DPIA is complete, submit it for review by changing the status to Under Review. Before this transition is allowed, the platform checks that at least one ROPA activity is linked to the DPIA. This ensures that every DPIA is connected to a documented processing activity.

Only users with the Compliance Officer or Client Admin role can submit a DPIA for review.

Approved

Approval signifies that the organisation's decision-makers have reviewed the DPIA and are satisfied that the risks have been adequately identified and mitigated. Once approved, the DPIA becomes read-only — risk items can no longer be edited, and the assessment is locked to preserve its integrity as an audit record.

Rejected

If the reviewer determines that the DPIA is incomplete or that the risks have not been adequately addressed, they can reject it. Rejection requires a reason to be provided, which is recorded on the DPIA. A rejected DPIA returns to Draft status, allowing the assessor to address the reviewer's concerns and resubmit.

Who Can Approve

The approval workflow enforces separation of duties. The following roles can approve or reject a DPIA:

Client Admin — the organisation owner has full authority to approve assessments.
DPO (Data Protection Officer) — as the independent oversight role, the DPO is well-positioned to review and approve DPIAs.
Platform Admin — for platform-level oversight.

Compliance Officers can create and submit DPIAs for review but cannot approve them. This separation ensures that the person conducting the assessment is not the same person signing it off.

Tips for Effective DPIAs

Involve stakeholders early — do not conduct the DPIA in isolation. Engage IT, legal, the business owner of the processing activity, and your DPO from the start. Their perspectives will help you identify risks you might otherwise miss.
Document mitigation measures thoroughly — for each risk, describe not just what you will do, but when, who is responsible, and how you will verify the measure is effective.
Be honest about residual risk — after mitigation, some risk will remain. Document it clearly. If residual risk is still high, you may need to consult the supervisory authority under Article 36.
Review DPIAs periodically — a DPIA is not a one-off exercise. When the processing activity changes, when new risks emerge, or when mitigation measures prove insufficient, revisit the DPIA and update it.
Link to your ROPA — every DPIA should be connected to at least one processing activity in your ROPA. This creates a coherent compliance framework where your data inventory, risk assessments, and documentation all reference each other.
Use the risk matrix for communication — the 5x5 grid is an excellent tool for presenting risk to non-technical stakeholders. A board member who might not read a detailed risk register can immediately understand a colour-coded matrix.
Consider consulting the supervisory authority — if your DPIA indicates that the processing would result in a high risk that you cannot mitigate, Article 36 requires you to consult the supervisory authority before proceeding. This is not a failure — it demonstrates responsible data governance.

DPIAs are one of the most powerful tools in your compliance toolkit. Done well, they do not just satisfy a regulatory requirement — they genuinely reduce the risk of harm to the individuals whose data you process.