DPIA template for universities: how to carry out a data protection impact assessment under GDPR Article 35

Universities run more high-risk processing than most organisations: AI tools for staff and students, online exam proctoring, learning analytics and research with sensitive data. This guide explains when Article 35 GDPR requires a data protection impact assessment (DPIA), what it must contain, how to run one step by step, four worked university examples, when to consult the supervisory authority, and how the DPIA links to the AI Act's fundamental rights impact assessment. A free Word template is included.

Published 7 October 2026 · Sources checked 7 October 2026

1. When a DPIA is required

Article 35(1) GDPR requires the controller to carry out a DPIA "prior to the processing" where a type of processing, "in particular using new technologies", is likely to result in a high risk to the rights and freedoms of natural persons. One assessment may cover a set of similar processing operations with similar high risks [1]. Three tests help a university decide.

Test 1: the three Article 35(3) cases

A DPIA is always required for [1]:

1. 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;
2. large-scale processing of special category data (Article 9(1)) or criminal offence data (Article 10);
3. systematic monitoring of a publicly accessible area on a large scale.

Test 2: your supervisory authority's list

Each supervisory authority publishes a list of processing types that need a DPIA (Article 35(4)), and may publish a list of types that do not (Article 35(5)) [1]. These lists differ by country, so use the one for your establishment. For example, the French CNIL's list includes constant monitoring of employees' activity, HR profiling such as algorithms that propose personalised training, and biometric identification involving vulnerable people, with pupils given as an example [3]. Some authorities also publish method guidance: the Swedish IMY, for example, offers a practical guide to carrying out a DPIA in ten steps, with templates for the screening and the assessment itself [4].

Test 3: the nine WP248 criteria

The Article 29 Working Party's DPIA guidelines (WP248 rev.01, endorsed by the EDPB) set out nine criteria [2]. The university examples are ours.

WP248 says that in most cases processing meeting two criteria will require a DPIA, the more criteria met the more likely a high risk, and in some cases one criterion is enough [2]. WP248 lists employees among possible vulnerable data subjects because of the power imbalance with the employer [2]. Validemic's analysis Students depend on the university for grades and progression in a similar way, so we suggest treating them as potentially vulnerable too. Many university processing activities therefore start with one criterion already met.

If you decide a DPIA is not needed, WP248 says the controller should justify and document why [2]. Our free DPIA screening tool walks through the Article 35(3) cases and the WP248 criteria and gives a recorded result, and section 1 of the template does the same on paper.

2. What Article 35(7) requires

The GDPR sets a minimum. A DPIA must contain at least [1]:

Three further paragraphs shape the work. Compliance with an approved code of conduct is to be taken into account (Article 35(8)). Where appropriate, the controller shall seek the views of data subjects or their representatives (Article 35(9)). And the controller must review the processing against the DPIA "at least when there is a change of the risk" (Article 35(11)) [1]. WP248 adds that a DPIA should be continuously reviewed and regularly re-assessed as good practice [2].

3. Running a DPIA step by step

WP248 describes the DPIA as an iterative process that should start "as early as is practicable" in the design of the processing [2]. A practical sequence for a university:

1. Screen. Apply the three tests above. Record the result either way.
2. Set up the team. A named owner from the unit that wants the processing (for example the head of examinations or the principal investigator), plus IT security, the system owner, procurement if a vendor is involved, and the DPO as adviser.
3. Describe the processing (35(7)(a)). Data categories, data subjects, sources, recipients, systems, vendors and subprocessors, storage locations, retention. Link to the matching entry in your record of processing activities.
4. Collect the vendor evidence. DPA, subprocessor list, hosting and transfer information, security documentation, and for AI tools the model and training terms. Under Article 28(3)(f) the processor must assist with the DPIA, taking into account the information available to it [1]. Our vendor assessment guide lists what to ask for.
5. Assess necessity and proportionality (35(7)(b)). Lawful basis, minimisation, alternatives, retention, transparency, rights, transfers.
6. Identify and rate risks (35(7)(c)). For each risk, describe the harm to people, then rate likelihood and severity.
7. Choose measures (35(7)(d)). Technical, organisational and contractual. Rate the residual risk after each measure.
8. Seek views (35(9)). Where appropriate: the student union, staff representatives, a works council where national law requires one, or a pilot group. Record the views and how you responded.
9. DPO advice (35(2)). Record the advice and the decision taken on it.
10. Decide. Proceed, proceed with conditions, redesign, or consult the supervisory authority if high residual risk remains (Article 36).
11. Sign off and integrate. Feed the measures into the project plan and contract, and update the ROPA entry.
12. Review. Set a review date, and review earlier if the vendor, the features or the purpose change.

Reviewing a vendor right now? Validemic checks the vendor's documents against GDPR and the EU AI Act and cites every finding. Try the demo workspace

4. Worked university examples

These are illustrations written by Validemic to show the reasoning, not assessments of any real deployment. Your facts, national list and vendor terms decide the outcome.

Example 1: rolling out a generative AI assistant to staff and students

Screening. Innovative technology (criterion 8), large scale (criterion 5), and users who may type in personal data about others, including sensitive data (criterion 4). A DPIA is required in our view.

Key risks to individuals. Personal data in prompts and uploaded files being retained or used to train models; inaccurate output about people (for example a generated summary of a student's case); transfers outside the EEA through subprocessors; output being relied on in decisions about students or staff.

Typical measures. An education or enterprise contract with a DPA and no training on customer data; EEA processing where available; access via single sign-on; a clear acceptable use policy and AI literacy measures; prohibited uses (for example grading or disciplinary decisions without human review); retention settings reviewed.

A public example. SURF, the Dutch education and research IT cooperative, has published DPIAs on Microsoft 365 Copilot for education. In its second update, published on 27 May 2026, SURF reported that two risks remained rated medium (orange) and advised institutions to "determine suitable use cases and carefully assess the risks for each such use case" [6]. That is a useful model: one DPIA for the platform, plus a short assessment per use case. See also our Microsoft Copilot fact sheet.

Example 2: online exam proctoring

Screening. Systematic monitoring (criterion 3), evaluation (criterion 1), possibly biometric data if facial recognition verifies identity (criterion 4), innovative technology (criterion 8), students as a dependent group (criterion 7), and potentially blocking access to the exam (criterion 9). A DPIA is required in our view, and some national lists will reach the same result directly.

Key risks. Intrusion into the home; recording of family members; false flags leading to misconduct allegations; discrimination where detection works less well for some groups; biometric data processing; long retention of video.

Typical measures. The CNIL's recommendation on remote exam surveillance says exam formats that validate skills remotely without surveillance should be preferred, that taking a proctored exam remotely should be an option rather than an obligation, that data should not be used for any purpose other than the remote exam, and that automatic analysis of candidates' behaviour should be excluded [5]. Add human review of every flag before any consequence, short retention, and no biometric identification unless a valid Article 9 exception applies.

AI Act angle. AI systems intended for monitoring and detecting prohibited behaviour of students during tests are listed as high-risk in Annex III point 3(d) [9]. AI systems that infer emotions in education institutions have been prohibited since 2 February 2025, except for medical or safety reasons (Article 5(1)(f)) [10]. Our proctoring fact sheet shows what one vendor documents publicly.

Example 3: learning analytics and early warning

Screening. Evaluation and prediction (criterion 1), combining datasets such as learning platform logs, attendance and grades (criterion 6), large scale (criterion 5), students (criterion 7). A DPIA is required in our view. If the model's output triggers automatic consequences, consider Article 22 and Article 35(3)(a).

Key risks. Students being labelled on the basis of proxies; bias against groups that engage differently online; function creep into assessment or discipline; students not knowing they are profiled.

Typical measures. A narrow, written purpose (support, not sanctions); outputs seen only by named advisers; human contact before any action; transparency to students, including how to object where the lawful basis allows it; testing for disparate error rates; no sensitive data as model inputs unless strictly justified. If the system is used to evaluate learning outcomes or steer the learning process, check whether it falls under Annex III point 3(b) of the AI Act [9]; our AI Act education checker helps.

Example 4: research interviews with recording and transcription

Screening. It depends on the topic and participants. Interviews with teachers about workload may meet no criterion or only one. Interviews with refugees about their health, or with patients, meet sensitive data (criterion 4) and vulnerable participants (criterion 7). A DPIA is then required in our view. A cloud transcription service with AI features may add criterion 8.

Key risks. Re-identification from quotes; recordings retained by the transcription vendor; vendor use of recordings to train models; transfers to non-EEA subprocessors; participants not understanding how long data is kept.

Typical measures. An approved transcription service under a DPA, or on-premise transcription; recordings deleted once transcripts are checked; pseudonymisation with the key held separately; storage only in approved research storage; a clear participant information sheet. Article 89(1) requires appropriate safeguards for research, in particular data minimisation, and favours pseudonymisation where it does not defeat the purpose [1]. Reuse the DPIA for similar projects: Article 35(1) allows one assessment for a set of similar operations with similar risks. See our guide on GDPR and AI tools in research and fact sheets on Otter.ai and Trint.

5. Consulting the DPO and others

Article 35(2) requires the controller to seek the advice of the DPO "where designated" when carrying out a DPIA, and Article 39(1)(c) makes it a DPO task to advise on the DPIA where requested and monitor its performance [1]. WP248 adds that the DPO's advice, and the decisions taken by the controller, should be documented within the DPIA [2].

Validemic's analysis Three habits keep this clean in a university:

• The owner writes, the DPO advises. If the DPO drafts and approves the DPIA, there is nobody independent left to advise or monitor. The template has a separate DPO advice box.
• Record disagreement. If the decision-maker does not follow the DPO's advice, write down why. Supervisory authorities can ask for the DPIA.
• Involve the DPO early. Advice at the screening stage is cheaper than advice on a signed contract.

WP248 also suggests involving the information security officer, independent experts where appropriate, and the processor, whose role must be contractually defined [2]. For data subjects' views under Article 35(9), WP248 mentions generic studies, questions to staff representatives or surveys, and says the controller should document its reasons if it decides not to seek views or departs from them [2].

6. Prior consultation under Article 36

Article 36(1) requires the controller to consult the supervisory authority before processing where the DPIA indicates that the processing "would result in a high risk in the absence of measures taken by the controller to mitigate the risk" [1]. WP248 reads this as applying when the residual risk remains high, that is, when the controller cannot find sufficient measures to reduce it [2]. Its examples of unacceptable residual risk include significant or irreversible consequences for individuals, or a risk that is obviously going to occur.

If the authority considers that the processing would infringe the GDPR, it gives written advice within up to eight weeks of receiving the request, extendable by six weeks for complex processing, and may use its corrective powers under Article 58 [1]. The controller must provide, among other things, the allocation of responsibilities between controller, joint controllers and processors, the purposes and means, the safeguards, the DPO's contact details and the DPIA itself (Article 36(3)). Member State law may also require prior consultation or authorisation for some public-interest processing (Article 36(5)).

Validemic's analysis Prior consultation is rare in practice, and it should be. If a university DPIA ends with high residual risk, the first question is whether the processing can be redesigned: a different vendor, fewer data, a narrower purpose, or an alternative to the technology. Do not start processing while waiting for the authority's advice.

7. The AI Act FRIA (Article 27)

The AI Act adds a separate assessment for some AI deployments. Before deploying a high-risk AI system under Article 6(2), deployers that are bodies governed by public law or private entities providing public services must carry out a fundamental rights impact assessment (FRIA), with an exception for critical infrastructure systems [7]. For a university this matters where an AI system falls under Annex III point 3 (education), which covers admission and assignment, evaluating learning outcomes, assessing the appropriate level of education and monitoring students during tests [9].

Points to get right:

• Timing. After the AI Omnibus (Regulation (EU) 2026/1744), the high-risk rules for Annex III systems, including Article 27, apply from 2 December 2027. Our AI Act guide for universities sets out the timeline. The GDPR DPIA obligation applies now.
• Scope. The DPIA covers risks from processing personal data. The FRIA covers the AI system's impact on fundamental rights more broadly (for example non-discrimination, or the right to education), and Article 27(1) asks for the processes in which the system is used, the period and frequency of use, affected groups, specific risks of harm, human oversight and the measures if risks materialise [7].
• Reuse. As amended in 2026, Article 27(4) says that where an obligation is already met through a GDPR DPIA, the FRIA may cross-reference the relevant sections of that DPIA or include relevant parts of it [7]. Article 26(9) tells deployers to use the provider's Article 13 information when carrying out their DPIA [8].
• First use and updates. The FRIA applies to the first use of the system, may rely on earlier FRIAs in similar cases, and must be updated when elements change (Article 27(2)) [7].

Validemic's analysis The efficient approach is one assessment file per AI use case: the DPIA now, with an AI Act annex that is completed if the system is high-risk. The template includes a short section 9 for this, so the FRIA can later point to the DPIA sections instead of repeating them. Not every AI tool is high-risk: a general writing assistant is usually not an Annex III system, while an AI tool that grades essays may be.

8. Common mistakes

1. DPIA after the contract. Article 35(1) says prior to the processing. After signature, the measures you can still negotiate are few.
2. Risks to the university, not to people. "Reputational damage" and "fines" are not Article 35(7)(c) risks. Describe what happens to the student or employee.
3. No alternatives considered. Necessity and proportionality means asking whether a less intrusive option would do, as the CNIL's proctoring recommendation shows.
4. Vendor claims copied without evidence. "EU hosted" in a sales deck is not a subprocessor list. Ask for the documents and check support access and transfers.
5. No owner for measures. A measure without an owner and date is a wish.
6. Never reviewed. Article 35(11) requires review when risk changes. AI products change monthly; set a review trigger for vendor changes.
7. DPO advice not recorded, or the DPO acting as author and approver.

9. The template

The DPIA template for universities is a Word document containing:

• Basic information: processing name, owner, team, DPO, version and review dates.
• Section 1: screening against Article 35(3), the WP248 criteria and your national list, with a box to record a decision not to carry out a DPIA.
• Sections 2 to 4: description of the processing (35(7)(a)), vendors and transfers, and necessity and proportionality (35(7)(b)).
• Section 5: consultation with data subjects or their representatives (35(9)).
• Sections 6 and 7: a risk register (35(7)(c)) and a measures plan with residual risk (35(7)(d)), each with example rows for a proctoring deployment.
• Section 8: DPO advice, decision, sign-off and the Article 36 prior consultation check.
• Section 9: an AI Act annex for high-risk systems, mapping Article 27(1) to the DPIA sections.
• A review log.

The template follows Articles 35 and 36 GDPR and the WP248 guidelines as read on 7 October 2026. Some supervisory authorities publish their own templates and expect particular methods; check yours. It is not legal advice.

Sources

1. Regulation (EU) 2016/679 (GDPR), Articles 6, 9, 22, 28, 35, 36, 39 and 89, Official Journal text (retrieved 7 October 2026).
2. Article 29 Working Party, Guidelines on DPIA (WP248 rev.01), revised 4 October 2017, endorsed by the EDPB (retrieved 7 October 2026).
3. CNIL: Liste des types d'opérations de traitement pour lesquelles une AIPD est requise (retrieved 7 October 2026).
4. IMY: Konsekvensbedömningar och förhandssamråd (retrieved 7 October 2026).
5. CNIL: Télésurveillance des examens en ligne, la CNIL publie une recommandation (retrieved 7 October 2026).
6. SURF: Privacy risks Microsoft 365 Copilot remain 'orange' despite improvements, 27 May 2026 (retrieved 7 October 2026).
7. AI Act (as amended by Regulation (EU) 2026/1744), Article 27: Fundamental rights impact assessment, European Commission AI Act Service Desk (retrieved 7 October 2026).
8. AI Act, Article 26: Obligations of deployers of high-risk AI systems (retrieved 7 October 2026).
9. AI Act, Annex III: High-risk AI systems, point 3 (retrieved 7 October 2026).
10. AI Act, Article 5: Prohibited AI practices (retrieved 7 October 2026).

About this page

Sources checked on 7 October 2026. The GDPR was read in its Official Journal version and the AI Act through the European Commission's AI Act Service Desk, which shows the text as amended by Regulation (EU) 2026/1744. The four worked examples are illustrations written by Validemic, and statements labelled as Validemic's analysis are our interpretation. This page is not legal advice. If you spot an error or know of a change, please contact us and we will correct it.