# AI Data Protection Impact Assessment (DPIA) Template

**Organisation:** [ORGANISATION NAME]
**Owner:** [NAME / ROLE]
**Date:** [DATE]
**Version:** 1.0

---

## Purpose

A Data Protection Impact Assessment (DPIA) is required under Article 35 of the GDPR whenever processing is likely to result in a high risk to the rights and freedoms of individuals, particularly where new technologies are involved. AI systems trip that threshold more often than almost any other category of processing: they are innovative technology by definition, they frequently evaluate or score people, and they often process personal data at scale during training, fine-tuning, retrieval, and inference.

This template gives you a complete, AI-specific DPIA: a screening checklist to decide whether a DPIA is required, a processing description shaped around how AI systems actually handle data, a necessity and proportionality assessment, a pre-seeded risk register focused on risks to data subjects, mitigation and residual-risk tracking, and the consultation and sign-off records a supervisory authority expects to see.

It is written for the EU GDPR but works with minimal adaptation under the UK GDPR, and the structure maps cleanly onto OAIC Privacy Impact Assessment practice in Australia (see the final section).

---

## How to Use

1. Complete Part 1 (Screening) as early as possible in the project, before any personal data is used for training, testing, or retrieval. If the outcome is "DPIA required", do not start processing until the DPIA is complete.
2. Fill in Part 2 (Description of the Processing) with the project team and the vendor. Push the AI provider for specifics: hosting regions, retention of prompts and outputs, and whether your data is used to train their models.
3. Work through Part 3 (Necessity and Proportionality) honestly. If a less intrusive approach would achieve the purpose, document why you did or did not choose it.
4. Score every risk in Part 4 from the data subject's perspective, not the organisation's. Reputational damage to the company is not a DPIA risk; harm to an individual is.
5. Assign mitigations in Part 5 and re-score the residual risk. Any residual high risk triggers prior consultation with your supervisory authority under Article 36.
6. Record the DPO's advice, obtain sign-off in Part 6, and diarise the review schedule in Part 7.
7. Store the completed DPIA with your records of processing (Article 30 register) and link it to the AI system's entry in your AI inventory.

---

## Part 1: Screening: Is a DPIA Required?

### 1.1 Mandatory triggers under GDPR Article 35(3)

A DPIA is always required if any one of the following applies. Tick all that apply.

| # | Article 35(3) trigger | AI example | Applies? |
|---|----------------------|------------|----------|
| A | Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based | AI-driven candidate screening, credit or insurance scoring, automated benefit eligibility decisions | [YES / NO] |
| B | Large-scale processing of special categories of data (Article 9) or criminal conviction data (Article 10) | Training or fine-tuning a model on health records; a clinical triage chatbot; biometric identification | [YES / NO] |
| C | Systematic monitoring of a publicly accessible area on a large scale | AI video analytics in retail spaces, smart CCTV, footfall and behaviour analysis | [YES / NO] |

### 1.2 EDPB nine criteria

The EDPB guidelines on DPIAs (WP248 rev.01, endorsed by the EDPB) list nine criteria that indicate likely high risk. As a rule of thumb, a DPIA is required when the processing meets **two or more** criteria; in some cases one is enough. Assess each criterion against your AI project using the AI-specific interpretation column.

| # | EDPB criterion | AI-specific interpretation | Applies? |
|---|---------------|----------------------------|----------|
| 1 | Evaluation or scoring, including profiling and predicting | The model rates, ranks, classifies, or predicts anything about identifiable people: performance, risk, behaviour, interests, creditworthiness | [YES / NO] |
| 2 | Automated decision-making with legal or similarly significant effect | Model outputs feed decisions about hiring, firing, lending, pricing, benefits, or access, with no meaningful human review | [YES / NO] |
| 3 | Systematic monitoring | AI-powered employee monitoring, endpoint or communications surveillance, always-on transcription, behavioural analytics | [YES / NO] |
| 4 | Sensitive data or data of a highly personal nature | Training or prompt data includes health, biometric, financial, location, or communications content; or the model can infer such attributes | [YES / NO] |
| 5 | Data processed on a large scale | Training corpora, embeddings, or logs covering large numbers of individuals, long durations, or wide geography | [YES / NO] |
| 6 | Matching or combining datasets | Feeding a model or RAG pipeline with data joined from separate systems (CRM plus HR plus support tickets) in ways people would not expect | [YES / NO] |
| 7 | Data concerning vulnerable data subjects | Employees, children, patients, asylum seekers, or anyone with a power imbalance relative to the controller | [YES / NO] |
| 8 | Innovative use or new technological or organisational solutions | Generative AI, foundation models, AI agents, and novel ML applications are innovative technology per the EDPB and the ICO | [YES / NO] |
| 9 | Processing that prevents data subjects from exercising a right or using a service or contract | Model gatekeeps access to a service, or its architecture makes access, rectification, or erasure requests impracticable | [YES / NO] |

### 1.3 AI-specific screening prompts

These common AI patterns almost always engage multiple criteria above. Tick any that describe your project.

- [ ] **Model training or fine-tuning on personal data.** Building or fine-tuning a model on data about identifiable people. The CNIL treats constituting a training database as capable of creating high risk on its own, and considers a DPIA presumptively necessary for developing foundation or general-purpose models on personal data. (Criteria 4, 5, 8)
- [ ] **Automated decision-making or decision support.** Model outputs determine or heavily influence decisions with real consequences for individuals. (Criteria 1, 2)
- [ ] **Systematic monitoring of employees or customers.** AI reviewing messages, screens, calls, movement, or productivity signals. (Criteria 3, 6, 7)
- [ ] **Inference of sensitive attributes.** The model can derive health status, emotional state, political views, religion, or sexual orientation from apparently non-sensitive inputs, whether or not you intend it to. (Criteria 1, 4)
- [ ] **RAG or search over personal data stores.** Retrieval-augmented generation indexed over mailboxes, CRM records, HR files, support tickets, or document repositories containing personal data. Retrieval can surface records outside their original access controls and purpose. (Criteria 5, 6)
- [ ] **Third-party AI tools processing personal data.** Staff submitting personal data to external AI services (including unapproved, shadow AI tools) where retention, reuse, and hosting are outside your control. (Criteria 5, 8)

### 1.4 Screening outcome

| Field | Record |
|-------|--------|
| Article 35(3) triggers met | [None / list A, B, C] |
| EDPB criteria met | [Count and numbers, e.g. 3 (criteria 1, 5, 8)] |
| Screening outcome | [DPIA required / DPIA not required / DPIA conducted voluntarily] |
| Rationale | [Short justification. If no DPIA is done, keep this record as evidence of the decision] |
| Assessed by / date | [NAME, DATE] |

> If in doubt, do the DPIA. The ICO's position on AI is that the innovative-technology criterion combined with any other criterion requires a DPIA, which captures the large majority of AI projects involving personal data.

---

## Part 2: Description of the Processing

### 2.1 Project and purpose

| Field | Record |
|-------|--------|
| Project / system name | [NAME] |
| Description of the AI system | [What it is: e.g. LLM-based support assistant with RAG over the knowledge base and CRM] |
| Purpose(s) of processing | [Specific, explicit purposes. Avoid "improve efficiency"; state the actual decision or output] |
| Controller | [ENTITY] |
| Processor(s) | [AI provider, hosting provider, integrators] |
| Role of your organisation | [Controller / joint controller / processor] |
| Lawful basis (Article 6) | [e.g. legitimate interests, contract, consent, legal obligation; record the assessment reference] |
| Condition for special category data (Article 9), if any | [e.g. explicit consent, employment law, substantial public interest; or N/A] |
| Automated decision-making under Article 22? | [YES / NO. If yes: legal basis under 22(2) and safeguards, including human intervention] |

### 2.2 Data categories, subjects, and sources

| Data category | Data subjects | Source | Special category? | Volume / scale |
|---------------|--------------|--------|-------------------|----------------|
| [e.g. Customer support transcripts] | [Customers] | [Helpdesk platform] | [No, but may contain incidental health mentions] | [~40,000 tickets/yr] |
| [e.g. Employee HR records] | [Employees] | [HRIS] | [Yes: sick leave] | [800 staff] |
| [e.g. Prompts and uploads to AI tool] | [Staff, third parties mentioned] | [User input] | [Unknown until scanned] | [Estimate] |
| | | | | |

### 2.3 Training vs inference data flows

Describe each stage separately. Training and inference raise different risks and often involve different data, locations, and retention.

| Stage | Personal data involved | Where processed | Retained for | Used to train provider models? |
|-------|-----------------------|-----------------|--------------|-------------------------------|
| Training / fine-tuning | [Datasets, provenance, whether scraped or collected directly] | [Region / provider] | [Duration] | [YES / NO / N/A] |
| Retrieval index (RAG) | [Document stores indexed, embedding storage] | [Region / provider] | [Duration] | [YES / NO / N/A] |
| Inference (prompts and outputs) | [What users submit and receive] | [Region / provider] | [e.g. 30 days for abuse monitoring] | [YES / NO: cite contract clause] |
| Logs, telemetry, feedback | [Prompt logs, thumbs up/down, error traces] | [Region / provider] | [Duration] | [YES / NO] |

### 2.4 Model provider and hosting

| Field | Record |
|-------|--------|
| Model / provider | [e.g. GPT-4 class model via provider X, or self-hosted open-weights model] |
| Deployment type | [Provider API / private cloud endpoint / self-hosted] |
| Hosting location(s) at rest | [Countries / regions, per tier if they differ] |
| Hosting location(s) in transit / inference | [Regions where inference runs] |
| International transfers and mechanism | [e.g. SCCs Module 2, adequacy decision, or none needed] |
| Contractual commitments | [DPA signed? Zero-retention or limited-retention option? Training opt-out?] |

### 2.5 Subprocessors

| Subprocessor | Role | Location | Personal data accessed | Safeguards |
|--------------|------|----------|------------------------|-----------|
| [Name] | [e.g. GPU hosting] | [Country] | [Categories] | [DPA, SCCs, certification] |
| | | | | |

### 2.6 Retention and deletion

| Data set | Retention period | Deletion method | Notes |
|----------|------------------|-----------------|-------|
| Training datasets and derived sets | [Period] | [Method] | [Include intermediate and augmented copies] |
| Embeddings / vector index | [Period] | [Re-index after source deletion] | [Embeddings of personal data are personal data] |
| Prompts, outputs, logs | [Period] | [Method] | [Confirm provider-side deletion] |
| Model checkpoints containing personal data influence | [Period] | [Retrain / decommission policy] | [See risk R9] |

### 2.7 Consultation with data subjects

Under Article 35(9), seek the views of data subjects or their representatives where appropriate.

| Field | Record |
|-------|--------|
| Views sought? | [YES / NO] |
| Method | [e.g. works council consultation, customer survey, user panel] |
| Outcome | [Summary of feedback and how it changed the design] |
| If not sought, why | [Justification, e.g. disproportionate effort, commercial confidentiality; document it] |

---

## Part 3: Necessity and Proportionality

Answer each question with evidence. "Yes" answers without evidence will not survive regulator scrutiny.

| # | Question | Assessment |
|---|----------|------------|
| N1 | Is the AI system necessary to achieve the purpose, or could a less intrusive method achieve it? | [Compare against non-AI or lower-data alternatives] |
| N2 | Could the purpose be achieved with less personal data, or with anonymised, pseudonymised, or synthetic data? | [What was tested; why rejected if rejected] |
| N3 | Is each data category demonstrably needed for training or inference (data minimisation)? | [Field-level justification for high-risk categories] |
| N4 | Is the lawful basis valid for BOTH training and inference? If legitimate interests, has a balancing test been completed? | [Reference the LIA document] |
| N5 | Are individuals told their data is used in or by an AI system (Articles 13 and 14), in clear language? | [Privacy notice sections updated; date] |
| N6 | Can the organisation honour access, rectification, erasure, and objection requests across training data, indexes, and logs? | [Describe the mechanism for each store] |
| N7 | For any Article 22 decision-making: is there meaningful human review, the right to contest, and an explanation of the logic involved? | [Describe safeguards; who reviews and with what authority] |
| N8 | Is output accuracy monitored, and are error and bias rates measured and acceptable for the decisions being made? | [Testing results, monitoring plan] |
| N9 | Are retention periods for each data flow justified and enforced, including provider-side? | [Cross-reference 2.6] |
| N10 | Is the processing within the reasonable expectations of the data subjects concerned? | [Consider context of original collection vs AI reuse] |

---

## Part 4: Risk Assessment

Score risks **to data subjects**: physical, material, or non-material harm to individuals, not harm to the business. Score likelihood (Remote / Possible / Probable) and severity (Minimal / Significant / Severe), then assign an overall risk (Low / Medium / High). The ten pre-seeded risks below are common in AI processing; edit, remove, or add rows to fit your project.

| ID | Risk to data subjects | Likelihood | Severity | Overall |
|----|----------------------|------------|----------|---------|
| R1 | Personal data memorised during training is reproduced in model outputs and disclosed to unrelated users | [Possible] | [Significant] | [Medium] |
| R2 | Individuals never learn their data was used for training (scraped or repurposed), so they cannot exercise any data subject rights | [Probable] | [Significant] | [High] |
| R3 | The model generates inaccurate or fabricated statements about an identifiable person, causing reputational, financial, or decision-based harm | [Possible] | [Severe] | [High] |
| R4 | Biased model behaviour produces discriminatory outcomes in hiring, lending, pricing, or service access for protected groups | [Possible] | [Severe] | [High] |
| R5 | The system infers sensitive attributes (health, sexuality, political opinions) that the individual never disclosed, and acts on them | [Possible] | [Severe] | [High] |
| R6 | RAG retrieval surfaces personal records beyond their original access controls or purpose, exposing them to staff or users with no need to know | [Probable] | [Significant] | [High] |
| R7 | Prompt injection or compromise of the AI system causes unauthorised disclosure or exfiltration of personal data | [Possible] | [Significant] | [Medium] |
| R8 | Personal data is transferred to, retained in, or reused for provider model training in jurisdictions without adequate protection or contractual safeguards | [Possible] | [Significant] | [Medium] |
| R9 | Erasure and rectification requests cannot be fully honoured because personal data has influenced model weights or persists in embeddings and backups | [Probable] | [Significant] | [High] |
| R10 | Function creep: data collected for one purpose is silently reused for new AI purposes, and systematic AI monitoring chills legitimate behaviour of employees or users | [Possible] | [Significant] | [Medium] |
| R11 | [Project-specific risk] | | | |

> Scoring aid: Remote = would require unusual circumstances. Possible = plausible in normal operation. Probable = expected to occur without intervention. Severity considers the worst realistic harm to an affected individual, including to vulnerable people.

---

## Part 5: Mitigation Measures and Residual Risk

For every Medium or High risk, record the measures that eliminate or reduce it, then re-score. Options for treating each risk: reduce, eliminate, transfer, or accept (acceptance of a high risk requires Article 36 consultation; see Part 6).

| Risk ID | Mitigation measure(s) | Effect | Residual risk | Owner | Status |
|---------|----------------------|--------|---------------|-------|--------|
| R1 | [Deduplicate and filter training data; test for memorisation / regurgitation before release; output filters] | [Reduced] | [Low] | [Owner] | [Planned] |
| R2 | [Document data provenance; publish transparency information; provide opt-out and rights channels for training data] | [Reduced] | [Medium] | [Owner] | [Planned] |
| R3 | [Human review for consequential outputs; accuracy disclaimers where lawful; rapid correction workflow] | [Reduced] | [Medium] | [Owner] | [Planned] |
| R4 | [Bias testing pre-deployment and in production; representative evaluation sets; fairness thresholds with rollback] | [Reduced] | [Low] | [Owner] | [Planned] |
| R5 | [Prohibit sensitive-attribute inference in system design and prompts; filter such outputs; restrict downstream use] | [Reduced] | [Low] | [Owner] | [Planned] |
| R6 | [Enforce source-system ACLs at retrieval time; index-level permission trimming; purpose-scoped collections] | [Reduced] | [Low] | [Owner] | [Planned] |
| R7 | [Input/output filtering; least-privilege agent permissions; red-team testing; incident response playbook] | [Reduced] | [Low] | [Owner] | [Planned] |
| R8 | [EU/UK region hosting; SCCs plus transfer impact assessment; contractual training opt-out and zero-retention tier] | [Reduced] | [Low] | [Owner] | [Planned] |
| R9 | [Keep personal data out of fine-tuning where possible; deletion-aware index rebuilds; document Article 17 limits and compensating controls] | [Reduced] | [Medium] | [Owner] | [Planned] |
| R10 | [Purpose compatibility assessment before any reuse; works council / staff consultation; monitoring proportionality review] | [Reduced] | [Low] | [Owner] | [Planned] |

**Residual risk summary:** [After mitigation, list any risks that remain Medium or High and state whether the processing will proceed, be modified, or be abandoned.]

---

## Part 6: Consultation, Sign-off, and Outcomes

### 6.1 DPO consultation record (Article 35(2))

| Field | Record |
|-------|--------|
| DPO consulted | [NAME], on [DATE] |
| DPO advice | [Summary of the DPO's advice on the DPIA, risks, and mitigations] |
| Advice accepted? | [YES / NO / PARTIALLY] |
| If overruled, reasons | [Document the business justification; the DPO's advice must be recorded even if not followed] |

### 6.2 Supervisory authority consultation trigger (Article 36)

If any residual risk remains **High** and cannot be reduced further, you must consult your supervisory authority **before** processing begins. The authority provides written advice within 8 weeks, extendable by a further 6 weeks for complex processing. Processing must not start while consultation is pending.

| Field | Record |
|-------|--------|
| Prior consultation required? | [YES / NO] |
| Authority and reference | [e.g. CNIL / Irish DPC / other lead authority; case reference] |
| Submission date and outcome | [DATE; summary of the authority's advice] |

### 6.3 Sign-off

| Role | Name | Decision | Date | Signature |
|------|------|----------|------|-----------|
| Project owner | | [Proceed / proceed with conditions / do not proceed] | | |
| DPO | | [Advice given, see 6.1] | | |
| CISO / Security | | | | |
| Accountable executive (SIRO or equivalent) | | | | |

### 6.4 Outcomes integrated into the project

- [ ] Mitigation measures added to the project plan with owners and dates
- [ ] Privacy notice and transparency information updated
- [ ] Records of processing (Article 30) updated
- [ ] AI inventory entry created or updated with a link to this DPIA
- [ ] Vendor contract / DPA updated to reflect required safeguards

---

## Part 7: Review Schedule

A DPIA is a living document. Review it at least every [12 months] and immediately upon any of these triggers:

- [ ] Model change: new base model, major version upgrade, or new fine-tuning run
- [ ] New data categories, data sources, or connected systems (including new RAG sources)
- [ ] Change of AI provider, hosting region, or subprocessor
- [ ] New purpose or user population for the system
- [ ] A relevant incident, complaint, near miss, or adverse audit finding
- [ ] Material regulatory change (e.g. new EDPB or supervisory authority guidance)

| Review date | Reviewer | Changes made | Next review |
|-------------|----------|--------------|-------------|
| | | | |

---

## Outside the EU: Equivalent Assessments

**UK GDPR.** Article 35 applies in near-identical form. Follow ICO DPIA guidance: the ICO's list of high-risk operations means the use of innovative technology such as AI or machine learning, combined with any other high-risk criterion, requires a DPIA, and the ICO expects a DPIA in the large majority of AI projects that process personal data. This template can be used as-is, with the ICO as the consultation authority.

**Australia (Privacy Act 1988).** There is no general statutory DPIA duty for the private sector, but the OAIC's Privacy Impact Assessment guide sets out a ten-step PIA process that this template maps onto, and the Information Commissioner can direct an Australian Government agency to provide a PIA for high-privacy-impact projects. OAIC guidance on commercially available AI products recommends a privacy-by-design approach including a PIA before adoption, and new APP 1 transparency obligations for computer-made decisions that significantly affect individuals commence on 10 December 2026. Completing this template substantially satisfies OAIC PIA practice; relabel it "Privacy Impact Assessment" and assess against the APPs instead of GDPR articles.

**Elsewhere.** Many regimes (Canada's PIPEDA practice, Brazil's LGPD relatorio de impacto, several US state laws requiring data protection assessments for profiling) expect a comparable documented assessment. The screening logic and risk register in this template transfer directly.

---

*Provided free by [Aona AI](https://aona.ai). Aona discovers every AI tool in use across your organisation, monitors what data flows into them, and keeps your AI inventory audit-ready.*