A DPIA that does not record what was decided, by whom and on whose advice gives no evidence of compliance, however careful the analysis behind it. This is a fill-in data protection impact assessment template: a screening checklist, then worksheets for the processing description, consultation, necessity and proportionality, risk assessment, measures, sign-off with DPO advice, the Article 36 prior consultation decision and review. It follows the seven DPIA steps the ICO sets out, which the Irish Data Protection Commission's sample template also uses, covers every element GDPR Article 35(7) requires, and adds prompts for AI systems. It is for privacy, security and project teams completing a DPIA under the EU GDPR or UK GDPR. For when and why to run a DPIA, see the DPIA Guide: Running a Data Protection Impact Assessment.
How to use this template
- Replace text in square brackets, such as [Organisation] and [DPO], with your own details, and delete prompts once answered.
- Complete section 3 (screening) at the start of the project, while the design can still change. Complete sections 4 to 10 before processing starts: Article 35(1) requires the assessment "prior to the processing".
- One DPIA may cover a set of similar processing operations that present similar high risks (Article 35(1)). Record the operations covered in section 2.
- The numbered sections map to the Article 35(7) minimum content: (a) description, section 4; (b) necessity and proportionality, section 6; (c) risks, section 8; (d) measures, section 9.
- Copy the sections into Word or your privacy tool and keep the DPIA as a controlled, versioned document: it is accountability evidence and must be supplied in any prior consultation (Article 36(3)(e)).
1. Purpose
This DPIA assesses the processing of personal data in [Project] by [Organisation]. It describes the processing, tests whether it is necessary and proportionate, identifies and assesses risks to the rights and freedoms of individuals, records the measures that address those risks, and documents the advice of the data protection officer (DPO), the sign-off decision and whether prior consultation with [the ICO / lead supervisory authority] is required.
2. Project details and roles
| Field | Entry |
|---|---|
| Project name and DPIA reference | [AI complaint triage assistant]; [DPIA-2027-004] |
| Processing operations covered | [Triage, summarising and drafting replies to customer complaints] |
| Controller and joint controllers | [Organisation]; [none] |
| Processors and sub-processors | [AI platform provider, CRM provider, hosting region] |
| Project owner and DPIA author | [Name, role]; [Name, role] |
| DPO | [Name, contact details] |
| Related records | [Record of processing activities entry, information security risk assessment, supplier assessment] |
| Version and date | [0.3, 12 Feb 2027] |
3. Screening checklist
Answer each question. The Article 29 Working Party guidelines (WP248 rev.01, endorsed by the EDPB) say that in most cases "a processing meeting two criteria would require a DPIA to be carried out", and that one criterion may be enough.
| Criterion (WP248 rev.01) | Yes / No | Notes |
|---|---|---|
| 1. Evaluation or scoring, including profiling and predicting | [ ] | [ ] |
| 2. Automated decision-making with legal or similar significant effect | [ ] | [ ] |
| 3. Systematic monitoring | [ ] | [ ] |
| 4. Sensitive data or data of a highly personal nature | [ ] | [ ] |
| 5. Data processed on a large scale | [ ] | [ ] |
| 6. Matching or combining datasets | [ ] | [ ] |
| 7. Data concerning vulnerable data subjects (including children and employees) | [ ] | [ ] |
| 8. Innovative use or applying new technological or organisational solutions (including AI) | [ ] | [ ] |
| 9. Processing that prevents data subjects from exercising a right or using a service or a contract | [ ] | [ ] |
Also answer:
- Article 35(3) mandatory cases: is there systematic and extensive evaluation with legal or similarly significant effects, large-scale processing of special category or criminal offence data, or large-scale systematic monitoring of a publicly accessible area? [Yes / No]
- National list: is the processing on the supervisory authority's Article 35(4) list? For the ICO, innovative technology, biometrics, genetic data, invisible processing and tracking require a DPIA when combined with any criterion above. [Yes / No, item]
Screening decision: [DPIA required / DPIA not required]. Reason: [ ]. DPO view: [ ]. If no DPIA is carried out, WP248 rev.01 says the controller should "justify and document the reasons for not carrying out a DPIA" and record the DPO's views. The ICO's position when in doubt is that it "would always recommend that you do a DPIA".
4. Description of the processing
Article 35(7)(a) requires "a systematic description of the envisaged processing operations and the purposes of the processing", including any legitimate interest pursued. Use the ICO's four headings.
| Heading | Prompts | Entry |
|---|---|---|
| Nature | Collection, use, storage, sharing, deletion; who has access; processors; new technology; data flow diagram | [ ] |
| Scope | Data categories, special category or criminal data, volume, frequency, retention, number of individuals, geographic area | [ ] |
| Context | Relationship with individuals, their expectations and control, vulnerable people, public concern | [ ] |
| Purposes | What you want to achieve, the intended effect on individuals, benefits to [Organisation] and others, legitimate interests | [ ] |
Data inventory (one row per data set):
| Data set | Data subjects | Source | Special category? | Systems and location | Recipients and transfers | Retention |
|---|---|---|---|---|---|---|
| [Complaint text and attachments] | [Customers] | [Web form, email] | [Possibly health data] | [CRM, AI platform, [region]] | [AI provider (processor)] | [6 years] |
| [Prompts, model outputs and logs] | [Customers, staff] | [AI platform] | [As above] | [AI platform] | [ ] | [90 days] |
5. Consultation
Article 35(9) requires the controller, where appropriate, to "seek the views of data subjects or their representatives on the intended processing". Article 35(2) requires the controller to seek the DPO's advice. Record who was consulted, internally and externally.
| Stakeholder | Method and date | Views or concerns raised | How addressed |
|---|---|---|---|
| Data subjects or representatives | [Survey, focus group, customer panel] | [ ] | [ ] |
| DPO | [Meeting, date] | [ ] | [ ] |
| Information security and IAM | [Security review reference] | [ ] | [ ] |
| Processors and suppliers | [Questionnaire, contract review] | [ ] | [ ] |
| [Employee representatives, legal, ethics or AI governance board] | [ ] | [ ] | [ ] |
If you do not seek individuals' views, record why.
6. Necessity and proportionality
Article 35(7)(b) requires "an assessment of the necessity and proportionality of the processing operations in relation to the purposes". Answer each question with evidence, not a yes.
| Question | GDPR reference | Answer and evidence |
|---|---|---|
| What is the lawful basis, and the Article 9 condition for special category data? | Art. 6, Art. 9 | [ ] |
| Does the processing actually achieve the purpose? Is there a less intrusive way to achieve it? | Art. 5(1)(b), (c) | [ ] |
| How will you prevent function creep, such as reuse of data for model training? | Art. 5(1)(b) | [ ] |
| Is each data item needed? What is excluded or pseudonymised? | Art. 5(1)(c), Art. 25 | [ ] |
| How will you keep data accurate, including AI outputs? | Art. 5(1)(d) | [ ] |
| What are the retention periods and how is deletion enforced? | Art. 5(1)(e) | [ ] |
| What privacy information will individuals receive, and when? | Art. 13, Art. 14 | [ ] |
| How will individuals exercise their rights, including access and objection? | Art. 15 to 21 | [ ] |
| Are there solely automated decisions with legal or similarly significant effects? | Art. 22 | [ ] |
| Are processor contracts in place and do they require DPIA assistance? | Art. 28 | [ ] |
| Are there international transfers, and under which safeguard? | Chapter V | [ ] |
7. AI processing prompts
Complete this section where the processing uses AI models, machine learning or AI agents. The prompts follow the ICO's guidance on AI and data protection, which expects an AI DPIA to start "at the earliest stages of project development" and remain a "'live' document".
- System description: a technical version for specialists and a plain one showing how inputs relate to outputs, with the stages where AI could affect people.
- Roles: is the AI provider a processor, controller or joint controller (Article 26)? Does it use your data to train or improve its models?
- Accuracy: record "any relevant variation or margins of error" in performance, how they were measured and for which groups.
- Human involvement: at which stage, and with what authority to overturn outputs.
- Trade-offs: record trade-offs such as "statistical accuracy and data minimisation", with the rationale.
- Harms: consider allocative harms (unfair distribution of opportunities or resources) and representational harms (stereotyping or denigration).
- Agents and tools: list the tools, APIs and data stores an AI agent can reach, the identity and credentials it uses, and what it can do to personal data without approval. See the AI Agent Authorisation Guide.
- Drift: define monitoring that triggers review, such as concept drift.
- EU AI Act: if [Organisation] is a deployer required to carry out a fundamental rights impact assessment under Article 27, Article 27(4) says the assessment "shall complement that data protection impact assessment". Cross-reference the two.
8. Risk identification and assessment
Article 35(7)(c) requires "an assessment of the risks to the rights and freedoms of data subjects". Assess risk to individuals, not to [Organisation]. Consider physical, material and non-material harm, and the three security events the CNIL PIA method uses: "illegitimate access to personal data", "unwanted change of personal data" and "disappearance of personal data". The ICO says the possibility of harm must be "more than remote", but harm need not be certain.
Scales (as in the Irish Data Protection Commission's sample template): likelihood remote, possible, probable; severity minimal, significant, severe; overall risk low, medium, high. [Organisation]'s matrix:
| Likelihood \ Severity | Minimal | Significant | Severe |
|---|---|---|---|
| Probable | Medium | High | High |
| Possible | Low | Medium | High |
| Remote | Low | Low | Medium |
| ID | Source of risk and nature of potential impact on individuals | Likelihood | Severity | Overall |
|---|---|---|---|---|
| P1 | An over-privileged AI agent identity or support account exposes complaint records, including health data, to the wrong customers or staff (illegitimate access) | Possible | Severe | High |
| P2 | Inaccurate AI triage deprioritises complaints from some groups, delaying redress (allocative harm) | Probable | Significant | High |
| P3 | The AI provider reuses prompts for model training beyond the stated purpose (function creep) | Possible | Significant | Medium |
| P4 | Prompts and logs are kept longer than needed, enlarging the impact of any breach | Probable | Minimal | Medium |
| [P5] | [ ] | [ ] | [ ] | [ ] |
9. Measures to reduce risk
Article 35(7)(d) requires "the measures envisaged to address the risks, including safeguards, security measures" and mechanisms to protect personal data. Every Medium or High risk in section 8 needs a row.
| Risk | Options to reduce or eliminate risk | Effect on risk | Residual risk | Measure approved | Owner and date |
|---|---|---|---|---|---|
| P1 | Dedicated agent identity scoped to the requesting customer's records; no standing admin access; short-lived credentials; access logging and alerting | Reduced | Low | [Yes] | [IAM lead, 31 Mar 2027] |
| P2 | Accuracy testing by customer group before launch and monthly; human review of all deprioritised complaints; complaint escalation route | Reduced | Medium | [Yes] | [Head of Complaints, launch] |
| P3 | Contract terms prohibiting training on customer data; enterprise tier with training disabled; supplier assurance | Reduced | Low | [Yes] | [Procurement, before contract] |
| P4 | [90-day] log retention with automated deletion; redact identifiers from logs | Reduced | Low | [Yes] | [Platform owner, launch] |
For access measures, record the identities involved, including service accounts and agent identities. See the Privacy-Enhancing Technologies Guide for pseudonymisation options.
10. Sign-off and DPO advice
Article 39(1)(c) gives the DPO the task "to provide advice where requested as regards the data protection impact assessment and monitor its performance". The ICO says to record the DPO's advice and, if you do not follow it, your reasons.
| Item | Name and date | Notes |
|---|---|---|
| Measures approved by | [ ] | Integrate actions into the project plan, with dates and owners |
| Residual risks approved by | [ ] | If any residual High risk remains, complete section 11 before going ahead |
| DPO advice provided | [ ] | DPO advises on compliance, measures and whether processing can proceed |
| Summary of DPO advice | [ ] | |
| DPO advice accepted or overruled by | [ ] | If overruled, record reasons: [ ] |
| Consultation responses reviewed by | [ ] | If the decision departs from individuals' views, record reasons: [ ] |
| This DPIA will be kept under review by | [ ] | The DPO should also review ongoing compliance |
Outcome: [Proceed / Proceed with conditions: list / Do not proceed / Prior consultation required]. The CNIL method uses three equivalent outcomes: "validated", "conditional on improvement" and "refused".
11. Prior consultation decision (Article 36)
- Is any risk in section 9 still High after measures? [Yes / No]. If no, prior consultation is not required; record that here.
- If yes, [Organisation] must consult [the supervisory authority] before processing starts (Article 36(1)), and must not begin the processing meanwhile.
- Send the information Article 36(3) lists: responsibilities of the controller, joint controllers and processors; the purposes and means; the measures and safeguards; the DPO's contact details; the DPIA; and any other information requested.
- Plan for the timescale: under Article 36(2) the authority gives written advice within up to eight weeks, extendable by six weeks for complex processing. The ICO says it will confirm within 10 days whether it accepts the DPIA for prior consultation, with a maximum of 14 weeks for advice.
- Record the outcome: [proceed / further mitigation advised / warning / limitation or ban], date and reference.
12. Review
Article 35(11) requires a review "to assess if processing is performed in accordance with the data protection impact assessment", at least when the risk changes. WP248 rev.01 says a DPIA "should be continuously reviewed and regularly re-assessed". Review this DPIA every [12 months] and when: the purpose, data, technology, supplier or AI model changes; a personal data breach or complaint relates to the processing; monitoring shows accuracy or drift outside [threshold]; or new guidance or law applies.
| Review date | Trigger | Changes made | Residual risk | Reviewed by |
|---|---|---|---|---|
| [ ] | [Scheduled / change / incident] | [ ] | [ ] | [ ] |
13. Source references
- GDPR: Article 35, Data protection impact assessment
- GDPR: Article 36, Prior consultation
- GDPR: Article 39, Tasks of the data protection officer
- Article 29 Working Party (endorsed by the EDPB): Guidelines on Data Protection Impact Assessment, WP248 rev.01
- ICO: How do we do a DPIA?
- ICO: When do we need to do a DPIA?
- ICO: Do we need to consult the ICO?
- ICO: What are the accountability and governance implications of AI?
- Data Protection Commission (Ireland): Sample DPIA Template
- CNIL: Privacy Impact Assessment (PIA) 1, Methodology
- EU AI Act: Article 27, Fundamental rights impact assessment for high-risk AI systems
Implementation guidance
- Embed screening in change: add section 3 to the project intake, architecture review and procurement processes, so new processing and new suppliers are screened by default.
- Start from the record of processing: reuse data inventory entries rather than re-describing data. See the Data Mapping and ROPA Guide.
- Run it as a workshop: complete sections 4 to 8 with the project owner, a security architect and the DPO.
- Feed the risk register: record residual Medium and High risks in the enterprise risk register with the same owner, so treatment is tracked after sign-off.
- Close the loop: verify measures before go-live and diarise the section 12 review.
Small organisations can use sections 3 to 10 with the privacy lead as author. Large organisations should run DPIAs in a privacy or GRC tool linked to the record of processing and supplier assessments. Track four measures: the share of new projects screened before design approval, DPIAs completed before processing starts, overdue DPIA reviews, and actions from section 9 still open after go-live. For AI deployments, see the AI and Privacy Guide and the AI Governance Guide.
This guide summarises GDPR Articles 35 and 36 and related ICO, EDPB and CNIL guidance and is not legal advice. Adapt this template to your organisation and jurisdiction. Related NHI Mgmt Group resources: DPIA Guide: Running a Data Protection Impact Assessment · GDPR Compliance Guide for Security Teams · Privacy Programme Guide for Security Teams · Global Privacy Regulatory Map