What Is a DPIA (Data Protection Impact Assessment)?
**A Data Protection Impact Assessment is a documented process for identifying and reducing the privacy risks of a processing activity, carried out before that processing begins.** GDPR Article 35 requires one where processing is likely to result in a high risk to the rights and freedoms of individuals, particularly when using new technologies. The word doing the work is **before**. A DPIA is a design control. Run after launch, it becomes a record of what you already decided, which is worse than useless because it evidences that the assessment did not inform the design. ---
When is a DPIA mandatory?
Article 35(3) names three cases where a DPIA is always required:
- A systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal effects or similarly significantly affect the person • Processing of special categories of data under Article 9, or data on criminal convictions under Article 10, on a large scale • Systematic monitoring of a publicly accessible area on a large scale
Beyond those, Article 35(4) requires each supervisory authority to publish a list of processing operations that require a DPIA in its jurisdiction. Those lists vary, and they are more operationally useful than the Article, because they name concrete activities rather than describing categories.
Where it is unclear, the practical default is to run a short screening assessment and record the conclusion. Documenting why a DPIA was not needed is itself evidence of accountability under Article 5(2).
What must a DPIA contain?
Article 35(7) sets a minimum of four elements:
- A systematic description of the processing and its purposes, including the legitimate interest pursued where relevant • An assessment of the necessity and proportionality of the processing in relation to those purposes • An assessment of the risks to the rights and freedoms of data subjects • The measures envisaged to address those risks, including safeguards and security measures
The second element is where most assessments are thin. Necessity and proportionality is not a security question. It asks whether the processing should happen at all, and whether a less intrusive approach would achieve the same purpose. Answering it honestly sometimes changes the project.
Where a DPO has been designated, Article 35(2) requires you to seek their advice.
What triggers a DPIA in a Salesforce estate?
Four situations come up repeatedly, and they are not exotic.
Deploying AI features over customer data. Grounding a model on CRM records, using AI to score or prioritise people, or letting an agent take action on a customer record is automated evaluation of personal aspects. Where the output influences a decision that affects someone, this is squarely in Article 35(3)(a) territory.
Large-scale special category data. Health, biometric, racial or ethnic origin, religious belief, trade union membership or sexual orientation. In a CRM this often arrives unnoticed, through a custom field created for a specific programme or a case description written by an agent.
Profiling and scoring. Lead scoring, churn prediction, credit or eligibility scoring. The test is whether decisions produce legal effects or similarly significant effects, not whether the model is sophisticated.
Combining datasets. Merging CRM data with acquired third-party data, or unifying identities across previously separate systems, creates a richer profile than any source held alone. That change in profile richness is itself the risk.
A fifth is worth flagging because it is routinely missed: non-production environments. A full-copy sandbox reproduces production personal data, then exposes it to developers, contractors and offshore teams who would not have production access. That is a change in the population who can see the data, which is a risk factor a DPIA should address. Masking the sandbox is one of the most straightforward mitigations available, which is exactly why it belongs in the measures section rather than being left unstated.
What happens if the risk cannot be mitigated?
Article 36 requires prior consultation. If the DPIA indicates high residual risk that you cannot reduce with available measures, you must consult your supervisory authority before starting the processing.
This is uncommon in practice, partly because the DPIA process usually surfaces mitigations before that point. When it does apply, proceeding without consulting is a separate breach from whatever the underlying risk was.
How does a DPIA relate to a RoPA?
They answer different questions and feed each other.
| RoPA (Article 30) | DPIA (Article 35) | |
|---|---|---|
| Question | What do we process, and why? | Is this specific processing too risky? |
| Scope | Every processing activity | High-risk activities only |
| Timing | Maintained continuously | Before processing starts |
| Audience | Supervisory authority on request | Internal, plus the authority if consulted |
Your RoPA is often what tells you a DPIA is needed, because it is the inventory that reveals which activities involve special category data or automated evaluation. If you cannot describe your processing activities, you cannot reliably identify which of them are high risk.
What does this mean in Salesforce?
Three of the four Article 35(7) elements need input from the org itself.
Describing the processing requires knowing what personal data is actually there, including in custom objects and free-text fields. Personal Data Discovery produces that inventory.
Assessing risk requires knowing who can see the data, across production and every sandbox derived from it.
Documenting measures is where concrete controls belong: masked non-production data, enforced retention, audited fulfilment of privacy requests, and consent state that downstream processes actually honour. A measures section that lists policies rather than controls does not reduce risk, and a regulator reading it can tell.
What no tool does, ours included, is the assessment itself. Necessity and proportionality is a judgement about whether the processing should happen at all, and no software can answer it for you. Buy tooling for the controls you list in the measures section. Staff the thinking.
Key Takeaways
A DPIA is a documented assessment of privacy risk carried out before processing starts, required by GDPR Article 35 where processing is likely to result in a high risk to individuals.
Article 35(3) names three mandatory triggers: systematic and extensive automated evaluation including profiling, large-scale processing of special category data, and systematic large-scale monitoring of a publicly accessible area.
Supervisory authorities publish their own lists of operations that always require one. Check the list for your lead authority, not just the Article.
Timing is the obligation people miss. A DPIA written after go-live documents a decision rather than informing it, and that is visible to a regulator.
If the DPIA concludes there is high residual risk that you cannot mitigate, Article 36 requires you to consult your supervisory authority before proceeding.
Frequently Asked Questions
See how this works in your Salesforce org
30-minute demo tailored to your specific use case and data model.