DPIAs as a repeatable Article 35 process, not a form filed once

What Article 35 requires

A DPIA is required where a type of processing is 'likely to result in a high risk to the rights and freedoms of natural persons' (Art. 35(1)). Article 35(3) names the cases where it is mandatory: a systematic and extensive evaluation based on automated processing, including profiling, with legal or similarly significant effects; large-scale processing of special-category or criminal-conviction data; and large-scale systematic monitoring of a publicly accessible area.

The assessment is not a checkbox. Article 35(7) sets out what it must contain: a systematic description of the processing and its purposes, an assessment of the necessity and proportionality of the processing in relation to those purposes, an assessment of the risks to data subjects, and the measures envisaged to address them. Where the residual risk remains high, Article 36 requires prior consultation with the supervisory authority.

• Art. 35(1) — DPIA where processing is likely to be high risk
• Art. 35(3) — mandatory cases (profiling with effects; large-scale special-category; systematic monitoring)
• Art. 35(7) — description, necessity/proportionality, risks, measures
• Art. 36 — prior consultation where high residual risk remains

Where DPIAs fail in practice

Two failures are common. The first is treating the DPIA as a one-time form: completed at launch, filed, and never revisited as the processing, the vendors, or the data change — so the document describes a system that no longer exists. The second is skipping the substance: a description and a risk list with no genuine necessity-and-proportionality analysis, which is the part Article 35(7) actually turns on and the part a supervisory authority reads first.

Underneath both is a threshold problem: a DPIA that Article 35(3) makes mandatory is quietly skipped because no one made the high-risk call at the start.

What RINS.AI does about it

RINS.AI captures the DPIA as structured fields — scope, risks identified, mitigations, and residual risk — and routes it through a multi-stage approval workflow to the roles that sign off: DPO, legal, security, executive. Each stage records the approver, their decision, and their comments, so the approval trail shows who signed off and what they said.

DPIAs link to the ROPA entries, vendors and evidence they depend on, so when one of those changes it surfaces where a DPIA needs revisiting — the assessment is kept current rather than re-created.

• Structured DPIA fields: scope, risks, mitigations, residual risk
• Multi-stage approval routed to DPO / legal / security / executive
• Per-stage approval record — approver, decision and comments
• Linked to ROPA entries, vendors and evidence

What it does not do

RINS.AI structures the assessment and records the decision; it does not make the high-risk judgment for you. Whether a given processing activity crosses the Article 35 threshold, and whether the residual risk is high enough to require Article 36 prior consultation, are determinations the controller or DPO makes — the platform surfaces the inputs and holds the record, but the consultation with the supervisory authority, and the decision to seek it, remain yours.