How Long Should You Keep Course-Evaluation Data? The Storage-Limitation Question

The short answer: The GDPR does not tell you to keep course-evaluation data for three years, or five, or ten. It tells you (Article 5(1)(e), the storage-limitation principle) that you may keep personal data in identifiable form only for as long as is necessary for the purpose you collected it — and that you must decide, document, and periodically review what "necessary" means. For most course evaluation, the honest necessary period for identifiable data is short, while the analytical value of the data is long. The resolution is not to keep everything forever; it is to keep the anonymised trend and dispose of the identifiable original. Universities that never make that distinction are carrying legal risk for data whose personal form they no longer need.

The principle, precisely

Article 5(1)(e) of the GDPR requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." Recital 39 adds the operational duty: controllers should establish time limits for erasure or periodic review. The UK Information Commissioner's Office, whose storage-limitation guidance is among the clearest, summarises the obligation as: do not keep personal data longer than you need it, be able to justify how long you do keep it, and have a policy setting standard retention periods.

Crucially, there is no statutory number. This is a feature, not a gap. The regulation refuses to set a universal period because necessity depends on purpose, and it pushes the accountability onto you: you must be able to point to the purpose, name the period, and defend the link between them. "We have always kept it" is not a defensible link. Neither is "storage is cheap." Retention is a decision the GDPR requires you to make deliberately, and to write down.

The same logic applies under national implementations across the EU — the Dutch AVG, the German BDSG, and others all inherit the storage-limitation principle. So this is not a UK question dressed up as a European one; it is a genuinely pan-European obligation that every quality-assurance office processing student feedback already sits under.

Why course evaluation is a hard case

Course-evaluation data has an awkward property: its identifiable value decays fast, but its analytical value compounds. Consider the competing pulls.

On the "dispose sooner" side: once an evaluation cycle has closed, its action has been taken, and any appeal window has passed, there is rarely an ongoing purpose that requires knowing which student said what. The individual identifiability is spent. Holding it creates risk — re-identification of open-text comments, subject-access complications, and a larger breach surface — for no live purpose.

On the "keep longer" side: the aggregate trend is where the value lives. You cannot detect whether a redesigned module improved over five cohorts, whether a bias pattern is stable, or whether an intervention worked, if you throw the data away each year. Longitudinal comparison is the whole point of a quality system, and it argues for long retention.

These pulls are only in conflict if you treat "the data" as a single indivisible object. They are reconciled the moment you separate the identifiable record from the anonymised analytical dataset. Under Recital 26, data that is genuinely anonymised — so that no individual can be re-identified by any means reasonably likely to be used — falls outside the scope of the GDPR entirely. Anonymisation is therefore not just a nicety; it is the mechanism that lets you honour storage limitation on the personal data while keeping the longitudinal signal indefinitely.

What good practice actually looks like

Real institutions already model the pattern. Sector guidance in the UK, for instance, expects providers to retain records of students' assessed work for a defined period after a course ends — commonly around five years — and, where possible, to retain them in an anonymised form by removing personal identifiers. University retention schedules express periods relative to the student lifecycle: a common formulation is "student's final year + N years" (for example, the University of Brighton's schedule uses constructions such as SFT + 6 years for certain records). Some module-evaluation systems anonymise responses a fixed number of academic years — often two — after the student stops participating in the programme.

The specific numbers matter less than the structure they share. Defensible retention practice has four moving parts:

1. A named purpose for each retention period — improvement analysis, appeals and complaints, accreditation evidence, statutory reporting. Different purposes justify different clocks.
2. A short clock on identifiable data, tied to the last purpose that genuinely needs identifiability (typically the appeals/complaints window plus a margin).
3. A longer — potentially indefinite — clock on anonymised aggregates, which are outside GDPR scope once anonymisation is robust.
4. A scheduled review and erasure trigger, so disposal actually happens rather than defaulting to "keep forever" through neglect.

Two cautions. First, anonymisation of open-text feedback is genuinely hard: free-text comments can re-identify a student through phrasing, references to specific incidents, or small-cohort context. Stripping a name is not anonymisation. Second, retention interacts with the anonymity and confidentiality promises you make to students at collection time — you cannot promise anonymity and then hold re-identifiable records for a decade. Retention policy and the participation-information notice have to tell the same story.

"Isn't this over-lawyering a low-risk dataset? It's just course feedback."

This is the reasonable sceptic's objection, and it deserves a straight answer. Course feedback can feel innocuous next to health or financial data. But three things make it higher-risk than it looks. Open-text comments frequently contain special-category or sensitive disclosures — about disability, mental health, harassment, or an instructor by name — that students did not expect to be stored for years. Small cohorts make re-identification trivial: in a seminar of nine, "the mature student who missed the first weeks" is a name. And the asymmetry of harm is real: the institutional benefit of keeping identifiable data past its purpose is negligible (the aggregate suffices), while the downside — a breach, a subject-access request that surfaces a decade-old complaint, a chilling effect on candour once students realise records persist — is not. Storage limitation is not bureaucratic caution here; it is proportionate to a genuinely underestimated risk. Doing it well also protects the quality of your data: students are more candid when they believe, correctly, that the identifiable record is short-lived.

How Koji is built for this

A modern evaluation platform should make the compliant path the default path, not an afterthought bolted on by the data-protection office. Koji is designed for EU-appropriate, GDPR/AVG-aware data handling, and the storage-limitation problem shapes several of its choices:

• Anonymised, thematic outputs as the durable artefact. Koji's automatic thematic analysis produces aggregate themes and trends that are the natural long-term retention object — the longitudinal signal you want to keep, in a form whose analytical value does not depend on identifying any individual.
• Structured collection that limits accidental identifiers. Because Koji's AI moderator guides students through six structured question types rather than an unbounded free-text box, it can steer feedback toward the evaluative substance and away from the incidental personal detail that makes open text so hard to anonymise later.
• Separation of the live record from the analytical trend, so that a short clock on identifiable interview data and a long clock on anonymised insight are architecturally distinct rather than a manual clean-up job.

Koji does not claim to make your retention schedule for you — that is a governance decision only your institution can own, and it should sit alongside your wider EU AI Act and data-protection posture. What it claims is narrower and honest: to make the anonymised trend the thing you keep and the identifiable original the thing you can safely let go, which is precisely what storage limitation asks. The main Koji platform applies the same data-minimising design to customer research, where retention discipline is just as neglected.

The bottom line

The right retention period for course-evaluation data is not a number you can copy from a blog post — it is a decision you must make, document, and review, against the specific purposes you actually have. But the shape of the answer is stable: keep identifiable responses only as long as a live purpose needs identifiability, keep the anonymised trend for as long as it is useful, and never confuse the two. "We keep everything" is not caution. Under the GDPR it is the one position you cannot defend.