A Data Protection Impact Assessment is the controller's pre-flight check on a processing activity that's likely to result in high risk to data subjects. GDPR Article 35 makes one mandatory in three situations:
- Systematic, extensive evaluation of personal aspects based on automated processing (profiling, scoring, recommendation engines).
- Large-scale processing of special categories of data (health, biometric, religious, political).
- Systematic monitoring of a publicly accessible area on a large scale (CCTV, badge tracking, public Wi-Fi analytics).
Most data protection authorities also publish their own non-exhaustive lists of activities that trigger a DPIA. Onboarding a new HR or payroll vendor that touches employee data, deploying an AI tool that processes customer support transcripts, or adding a new analytics SDK to a consumer app are common triggers in practice.
What a DPIA must contain
Article 35(7) lists the minimum elements:
- Systematic description of the processing operations and purposes.
- Necessity and proportionality assessment — could you achieve the purpose with less data, or with a less intrusive method?
- Risk assessment to the rights and freedoms of data subjects.
- Mitigation measures — what controls reduce the risk to an acceptable level.
If the residual risk after mitigations is still high, the controller must consult the supervisory authority before starting the processing (Article 36).
How vendor monitoring fits
The DPIA isn't a one-time document. The risk assessment and mitigations both depend on what the vendor does and continues to do. If a vendor adds a new subprocessor in a non-adequate jurisdiction six months after you signed the DPIA, the DPIA's transfer-risk analysis is now stale. Most well-run privacy programs treat DPIAs as living documents and review them annually, or whenever a vendor sends a "we've updated our policies" notice.
A DPIA that hasn't been reviewed in two years is, in audit terms, indistinguishable from no DPIA at all.