Does Your Course Evaluation Need a DPIA? The GDPR Article 35 Question Vendors Rarely Raise

The short answer: Under Article 35 of the GDPR, a Data Protection Impact Assessment (DPIA) is mandatory before any processing "likely to result in a high risk to the rights and freedoms of natural persons." The European Data Protection Board's predecessor, the Article 29 Working Party, set out nine criteria (guidance WP248 rev.01) for spotting such processing; meeting two or more normally means a DPIA is required. A modern course-evaluation programme — systematic across a whole institution, producing evaluative scores, sometimes AI-moderated, collecting free-text that can reveal special-category data, and involving students who sit in a position of imbalance toward the institution — typically satisfies several of them at once. If your evaluation vendor has never mentioned a DPIA, that is a gap in due diligence, not a sign you are exempt.

Why this is not box-ticking

Universities tend to treat course evaluation as low-stakes administrative data — anonymous forms, aggregate averages, nothing sensitive. That framing is comfortable and increasingly wrong. Three things have changed. Evaluation is now institution-wide and continuous rather than occasional. It increasingly feeds consequential decisions about staff and programmes. And it increasingly runs through AI systems that moderate, summarise, or score. Each of those shifts pushes evaluation toward the "high risk" territory that Article 35 was written for. A DPIA is the GDPR's structured way of asking, before you deploy, whether the processing is necessary, proportionate, and adequately safeguarded — and of documenting that you asked.

Getting it wrong is not costless. Failure to carry out a required DPIA is an infringement of a controller obligation under Article 35, which falls within the lower fine tier of Article 83(4): up to €10 million or 2% of total worldwide annual turnover, whichever is higher. For a public university the reputational and regulatory exposure usually bites harder than the number, but the number is real.

The WP248 criteria, read against a course-evaluation system

The Working Party's nine indicators of likely-high-risk processing map onto evaluation more closely than most administrators expect. At least four routinely apply:

1. Evaluation or scoring. The first criterion is explicitly "evaluation or scoring, including profiling and predicting." A system that produces teaching-quality scores, ranks modules, or flags "courses of concern" is doing exactly this. When those scores attach to identifiable instructors, the profiling is of staff as well as students.

2. Systematic monitoring. Continuous, mid-cycle, or repeated evaluation of every course across an institution is systematic monitoring of behaviour — of teaching staff whose performance is observed term after term, and arguably of students whose engagement is tracked.

3. Data processed on a large scale. A faculty pilot may not qualify; an institution-wide roll-out covering tens of thousands of students and thousands of staff clearly does. The GDPR asks you to weigh the number of data subjects, the volume of data, its duration, and its geographical extent.

4. Data concerning vulnerable data subjects. WP248 names employees and, by extension, anyone in an imbalanced relationship with the controller. Students are the textbook case: they depend on the institution for grades, progression, and references, so their consent is rarely "freely given" in the GDPR sense. Staff being evaluated by their employer are the other vulnerable group in the same dataset.

Two further criteria often apply depending on design: sensitive data or data of a highly personal nature, because free-text comments regularly disclose health, religion, sexual orientation, or ethnicity — the special-category problem we cover here — and innovative use of technology, if the system deploys AI moderation or large-language-model analysis whose risks are not yet well understood. Meeting two criteria triggers the requirement; a serious evaluation platform frequently meets four to six.

"But our evaluations are anonymous — surely GDPR does not even apply?"

This is the objection every administrator raises, and it is where most DPIA conversations quietly die. Three responses.

First, genuine anonymity is harder than it looks. If a course has twelve students and the report breaks down by demographic, or if free-text can be re-identified by writing style — the stylometric re-identification risk — the data may be pseudonymous rather than anonymous, and GDPR still applies. True anonymisation must be irreversible in practice, not just intended.

Second, the instructor is a data subject too. Even if student responses were perfectly anonymous, a report that scores and profiles a named lecturer is processing that lecturer's personal data. The teaching-quality profile is personal data about an identifiable person, full stop.

Third, the DPIA is about risk, not certainty of harm. Article 35 is triggered by processing likely to be high-risk, assessed in advance. Concluding "we looked and the residual risk is low because of these specific safeguards" is a valid DPIA outcome. Skipping the assessment because you assumed the answer is not. The point of the exercise is to force the analysis and record it — including, where residual high risk remains, the Article 36 duty to consult your supervisory authority before proceeding.

A fair counter-caveat: not every evaluation activity needs its own DPIA. A single small-cohort survey with no AI, no profiling of named staff, and robust anonymisation may fall below the threshold, and national supervisory authorities publish their own mandatory-DPIA lists that you should check against. The claim here is not "always" — it is "far more often than universities assume, and you must actually check."

What a good evaluation DPIA covers

A defensible DPIA for course evaluation works through, at minimum: a systematic description of the processing and its purposes; an assessment of necessity and proportionality (do you need free-text at module and programme level; do you need to retain it for years — the storage-limitation question); the risks to students and staff, including re-identification, chilling effects on honest feedback, and misuse of scores in personnel decisions; and the safeguards — data minimisation, access controls, EU data residency, retention limits, transparency to respondents, and human oversight of any automated analysis. Where the processing is AI-assisted, the DPIA should sit alongside your analysis of whether the system is high-risk under the EU AI Act; the two assessments overlap but are not the same instrument.

Where Koji fits

Koji for Education is built so that the DPIA is a shorter, calmer document rather than a list of unresolved risks. Data is handled in a GDPR/AVG-compliant, EU-appropriate way, which addresses the data-residency and transfer questions that dominate the Schrems II analysis. AI moderation is standardised and bias-aware, and — crucially for the necessity-and-proportionality test — Koji is designed to surface themes and quality signals rather than to make automated decisions about individuals, keeping a human in the loop for any consequential judgement. Structured question types and thematic analysis reduce the volume of unstructured free-text that most often carries special-category risk, supporting genuine data minimisation. None of this removes your obligation to run the DPIA — the controller is always the university — but it means the honest answer to most of the DPIA's hard questions is "yes, that is designed for," rather than "we will have to build a control for that."

The same EU-appropriate, privacy-considered interview engine underpins general user research on the main Koji platform, where the same DPIA logic applies whenever you profile or systematically monitor identifiable people at scale.

Who owns the DPIA, and when

Two practical points are worth stating plainly. First, the DPIA belongs to the university, not the vendor. The institution is the data controller under the GDPR; a supplier is typically a processor and can provide information and safeguards, but cannot discharge the controller's Article 35 duty on its behalf. Ask a vendor to support the DPIA with documentation — data flows, sub-processors, residency, retention — but do not accept "we have already done a DPIA" as covering your own obligation. Second, the DPIA must come before the processing, not after a complaint. Article 35 is a prior-assessment instrument: it is meant to shape the design of the evaluation while changes are still cheap, and your Data Protection Officer must be consulted. Retrofitting one after a system is live still helps, but it forfeits the whole point — catching disproportionate data collection, over-long retention, or unnecessary free-text before students ever answer a question. Build the DPIA into procurement, and revisit it whenever the system materially changes, such as when AI analysis is switched on.

The takeaway

Ask your evaluation vendor one question: have you helped an institution complete a DPIA for this system, and can you show me which WP248 criteria you assume it triggers? The answer tells you whether they understand the regulation their product operates under. Course evaluation has quietly become the kind of processing Article 35 was written to govern — systematic, evaluative, AI-touched, and aimed at people who cannot easily say no. A DPIA is how you prove you noticed.