Personal data breach response for universities: 72-hour plan and templates

A practical, source-backed plan for handling a personal data breach at a university: when the 72-hour clock starts, how to assess risk, what to tell the supervisory authority and the people affected, what to do when the breach happens at a vendor, and how to document it. Includes a free Word kit with a breach log, risk form, notification checklist and notice template.

Published 7 October 2026 · Sources checked 7 October 2026

1. What counts as a personal data breach

Article 4(12) GDPR defines a personal data breach as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data". Two words in that definition do a lot of work in a university setting. "Accidental" means human error is enough: no attacker is needed. "Loss" and "destruction" mean that a breach can be about availability, not just secrecy.

The EDPB's Guidelines 9/2022 use three categories, which are a useful way to describe any incident in a breach log:

A breach can fall into several categories at once. The EDPB also notes that all personal data breaches are security incidents, but not every security incident involves personal data, and that a temporary loss of availability is still a breach (planned maintenance is not), although whether to notify depends on its impact on people.

2. The 72-hour clock and when it starts

Article 33(1) requires the controller to notify the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it". If notification comes later, it must be accompanied by reasons for the delay. Two points follow from the wording: 72 hours is an outer limit, not a target, and the clock runs from awareness, not from the start of the incident.

What "aware" means

The EDPB considers a controller aware "when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised" (Guidelines 9/2022, para. 31). After an alert, the controller may carry out a short investigation to establish whether a breach has happened, and during that period it may not be regarded as aware. The investigation must start as soon as possible, and the EDPB expects these preliminary steps to be completed soon after the initial alert, taking longer only in exceptional cases.

The guidelines give examples. When a USB stick with unencrypted personal data is lost, the controller is aware as soon as it realises the stick is gone, because an availability breach has certainly occurred. When a third party reports receiving someone else's data and provides evidence, there "can be no doubt".

A 72-hour plan

Validemic's analysis Universities lose time in the first hours. Incidents reach a department head or research group leader who does not know the clock may be running. A single reporting route, open outside office hours, matters more than a perfect template.

3. Assessing the risk

The GDPR uses three levels. If the breach is unlikely to result in a risk to the rights and freedoms of natural persons, it is documented but not notified. If it is likely to result in a risk, the supervisory authority must be notified. If it is likely to result in a high risk, the people affected must also be told (Art. 34(1)).

The EDPB recommends considering the following factors together, assessing both the severity of the potential impact and its likelihood (Guidelines 9/2022, section IV):

• Type of breach. Disclosure, alteration and loss create different harms.
• Nature, sensitivity and volume of the data. Health data, identity documents and financial data are singled out. A small amount of highly sensitive data can have a high impact.
• Ease of identification. Can the people be identified from the data, directly or with other information?
• Severity of consequences, including whether the data is in the hands of people whose intentions are unknown or possibly malicious, and whether the consequences are permanent.
• Special characteristics of the individuals, such as children or other vulnerable people.
• Special characteristics of the controller, for example a medical organisation processing health data.
• Number of individuals affected.

Where the breach involves special category data (such as health, ethnic origin, religion or sex life) or criminal offence data, the EDPB says damage "should be considered likely to occur". It also gives a general instruction worth putting in every university procedure: "If in doubt, the controller should err on the side of caution and notify" (para. 119).

Validemic's analysis Universities hold several categories that push risk up: research participants promised confidentiality, disability and wellbeing records, health data in medical and psychology research, and data on international students whose residence status depends on enrolment. A DPIA is a useful starting point, but the EDPB notes that a breach assessment must look at the actual circumstances.

4. Notifying the supervisory authority

The notification goes to the authority competent under Article 55, which for a public university is normally the authority of its own Member State. Use that authority's online form. Article 33(3) sets the minimum content:

1. The nature of the breach, including where possible the categories and approximate number of data subjects and of personal data records concerned.
2. The name and contact details of the data protection officer or another contact point.
3. The likely consequences of the breach.
4. The measures taken or proposed to address the breach and mitigate its possible adverse effects.

The EDPB suggests describing categories of data subjects in terms such as students, employees, children or other vulnerable groups, and categories of records in terms such as health data or "educational records". Precise numbers are not needed at first: approximations are allowed, and lack of precise information "should not be a barrier to timely breach notification".

If not everything is known within 72 hours, Article 33(4) allows the information to be provided in phases without undue further delay. The EDPB recommends saying in the first notification that more details will follow. If the investigation later shows that no breach occurred, the controller can update the authority; the EDPB states there is "no penalty for reporting an incident that ultimately transpires not to be a breach".

5. Telling the people affected

Where a breach is likely to result in a high risk, Article 34(1) requires the controller to communicate it to the data subjects without undue delay. The communication must describe the breach "in clear and plain language" and contain at least the contact point, the likely consequences and the measures taken or proposed (Art. 34(2)). The EDPB adds practical advice: use dedicated messages, not newsletters; give concrete steps people can take, such as resetting passwords; use the language you normally use with the recipients; and avoid any channel the attacker may control.

Article 34(3) sets out three situations where individual communication is not required:

• The data was protected by measures that make it unintelligible to unauthorised people, such as encryption, before the breach.
• The controller has since taken measures that make the high risk no longer likely to materialise.
• It would involve disproportionate effort. In that case a public communication or similar measure that informs people equally effectively is required instead.

The controller must be able to show that an exception applies. The supervisory authority can also order communication (Art. 34(4)). Communication may be delayed on the advice of law enforcement where early disclosure would hamper an investigation (Recital 88), but people must be informed promptly afterwards.

Even below the high-risk threshold, contacting people may be necessary. In the EDPB's examples of misdirected post, the controller has to contact recipients and affected people anyway because their cooperation is needed to limit the damage.

6. Breaches at a vendor

Many university incidents start at a supplier: a learning platform, a survey tool, an email security service, a cloud storage provider. The June 2026 letter from the Dutch education minister to parliament on cyber resilience in higher education, for example, cites a recent cyberattack on Instructure, the supplier of the Canvas learning platform, as an example of threats to the sector.

What the GDPR requires

Article 33(2) says "the processor shall notify the controller without undue delay after becoming aware of a personal data breach". Article 28(3)(f) requires the processing contract to oblige the processor to assist the controller with Articles 32 to 36. The EDPB draws several consequences (Guidelines 9/2022, paras. 43 to 48):

• The processor does not assess risk before notifying. It only establishes that a breach has occurred and tells the controller; the risk assessment is the controller's job.
• The controller should "in principle" be considered aware once the processor has informed it. The 72 hours then run for the university.
• The GDPR sets no explicit time limit for the processor beyond "without undue delay", so the EDPB recommends prompt notification with further information in phases, and says the contract can require early notification.
• Where one incident at a processor affects several controllers, the processor must report details to each of them.
• A processor may notify the authority on the controller's behalf only if the controller has authorised it in the contract, and the legal responsibility stays with the controller.

The EDPB also notes that a controller "may find it useful to name its processor" in its own notification when the processor is the root cause, especially when many other controllers are affected.

What the DPA should say

Validemic's analysis Because the law leaves the processor's timing open, the data processing agreement is where a university secures the time it needs. We look for the following in vendor DPAs:

• A specific maximum notification time in addition to "without undue delay", short enough to leave the university room to meet its own 72 hours. Vague wording such as "within a reasonable time" or "after completing our investigation" works against the controller.
• A trigger that does not depend on the vendor's own risk assessment. Some agreements promise to notify only "material" or "confirmed" breaches. The GDPR does not let the processor filter.
• Minimum content mapped to Art. 33(3), an incident reference and a named contact, with updates in phases.
• A monitored university address for notices, not an individual's inbox or the procurement mailbox.
• Flow-down to subprocessors (Art. 28(4)), so a breach at the vendor's hosting or AI provider reaches you through the vendor.
• Cooperation: access to the logs and forensic findings needed for your own notification, and consultation before public statements that name the university.

Part 5 of our breach response kit turns this into a clause checklist, and the DPA checker maps a draft agreement against each point of Article 28(3). Breach terms belong in the vendor assessment itself; our vendor assessment guide and the European vendor questionnaire include questions on incident handling. Subprocessor changes matter here too, because each new subprocessor is another place a breach can start: the free subprocessor alerts tool helps you keep track.

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

7. Documentation under Article 33(5)

Article 33(5) requires the controller to "document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken", in a way that lets the supervisory authority verify compliance. This applies to every breach, including those that are not notified. The EDPB adds that the controller should record its reasoning, in particular why it concluded a breach was unlikely to result in a risk, or which Article 34(3) condition applied, and the reasons for any delay in notification.

The GDPR does not prescribe a format or a retention period. The EDPB says a separate register is not required if breaches are recorded in the record of processing activities in a way that can be extracted on request; most institutions find a dedicated log easier. Where the log itself contains personal data, the normal storage limitation rules apply. For the record of processing, see our ROPA template for universities.

8. Four university scenarios

The outcomes below are our own reading of the EDPB's guidance applied to typical university facts. The real answer always depends on the details, and national authorities may take different views.

Misdirected email with grades

A course administrator sends a spreadsheet with names, student numbers and marks for one module to every student on another module. The breach is a confidentiality breach, and the university is aware as soon as the mistake is spotted or reported.

The EDPB's examples are a useful guide. A list of 15 course participants with food preferences, recalled immediately, was judged unlikely to result in a risk: documentation only. A file of over 60,000 job seekers with social security numbers attached to a mass email required notification of the authority and of every person affected. Validemic's analysis Marks alone sent to a small group of fellow students, recalled quickly, may fall nearer the first example. The picture changes if the file includes disability adjustments, extenuating circumstances, disciplinary outcomes or national identification numbers, or if it went to external recipients. In every case: ask recipients to delete it, following the EDPB's suggestion of a follow-up sent in Bcc, and log the decision.

Ransomware on a faculty server

Ransomware encrypts a file server holding staff and student documents. This is at least an availability breach. The EDPB's ransomware cases turn on two questions: was there a working backup, and was data exfiltrated? With a tested backup and no evidence of exfiltration after investigation, the EDPB found the breach unlikely to result in a risk in its example; it still had to be documented. Without a backup, or with exfiltration, notification is needed, and with exfiltration of sensitive data the people affected must usually be told as well. If you cannot establish whether data was copied, the EDPB says to assume the worse scenario.

Validemic's analysis Modern ransomware groups usually steal data before encrypting it, so "no exfiltration" should be a finding of the forensic investigation, not an assumption. If the university falls under NIS2 in its country, the same incident may also need an early warning to the CSIRT within 24 hours; see section 9.

Cloud misconfiguration

A research group stores survey exports in a cloud storage bucket. A link setting or access policy is changed, and the files are publicly reachable for several weeks before a researcher notices. This is a confidentiality breach whether or not anyone downloaded the files. Ask the provider for access logs early: they may show whether the data was actually accessed, which is central to the risk assessment. If the storage is run by a vendor on the university's behalf, the vendor's notice and logs feed directly into the university's notification.

Validemic's analysis Research data raises the stakes: consent forms may promise confidentiality, and pseudonymised data can be re-identifiable through free-text answers. Involve the principal investigator alongside the DPO.

Lost laptop with research data

A researcher's laptop is stolen from a car. It holds interview transcripts. The EDPB's device cases set the line clearly. Tablets with strong passwords, full-disk encryption and a backup were judged unlikely to result in a risk: document only. An unencrypted notebook with personal data of over 100,000 customers required notification of the authority and of the individuals. Encryption is also one of the Article 34(3) grounds for not informing individuals, provided the key was not compromised.

Validemic's analysis The useful question in the first hour is therefore not "what was on the laptop?" but "can we prove it was encrypted and managed?". Device management records that show encryption status and allow remote wiping turn many of these incidents into log entries rather than notifications.

9. Other reporting regimes and pending changes

The GDPR is not the only reporting duty. Under NIS2, essential and important entities must send an early warning to their CSIRT or competent authority within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within one month (Directive (EU) 2022/2555, Art. 23(4)). Whether a university is covered depends on national transposition; see our guide NIS2 and universities: are you in scope?. Where a NIS2 authority finds that an infringement can entail a personal data breach that must be notified under the GDPR, it must inform the data protection authority (NIS2 Art. 35). The two notifications are separate and both may be required for the same incident.

Pending: the Commission's Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD), published 19 November 2025) would extend the GDPR authority notification deadline to 96 hours, align the threshold to focus on higher-risk breaches, introduce a common EU reporting template and create a single entry point for incident reporting under several laws. On 7 October 2026 the European Parliament's Legislative Observatory lists the procedure as "Awaiting committee decision". Nothing in it applies yet: plan for 72 hours.

10. Lessons and a preparation checklist

The EDPB's case examples repeat two lessons: most notifications are avoided by measures taken before the breach (encryption, tested backups, restricted mailing lists, monitoring), and the worst breaches are the ones that go undetected. Its example of mailbox rules that quietly forwarded payment emails to an attacker for three months is a reminder to monitor mail rules.

11. The free breach response kit

Download the personal data breach response kit for universities (Word, free, no sign-up). It has five parts: a breach log with the fields Article 33(5) and the EDPB expect, a risk assessment form following the EDPB's criteria, a notification checklist mapped to Article 33(3), a plain-language data subject notice built around Article 34(2), and a vendor clause checklist for breach terms in DPAs, plus a contacts sheet. Adapt it to your national law and your authority's form, and have it reviewed by your DPO.

Sources

1. Regulation (EU) 2016/679 (GDPR), Official Journal text, Articles 4(12), 28, 33, 34, 55 and Recitals 85 to 88 (retrieved 7 October 2026).
2. EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted 28 March 2023 (retrieved 7 October 2026).
3. EDPB Guidelines 01/2021 on examples regarding personal data breach notification, version 2.0, adopted 14 December 2021 (retrieved 7 October 2026).
4. Directive (EU) 2022/2555 (NIS2), Articles 23 and 35 (retrieved 7 October 2026).
5. European Parliament Legislative Observatory, procedure 2025/0360(COD), Digital Omnibus, including the summary of the legislative proposal COM(2025) 837 of 19 November 2025 (retrieved 7 October 2026).
6. Letter from the Dutch Minister of Education, Culture and Science on cyber resilience in vocational and higher education, Kamerstukken II 2025/26, 26 643, nr. 1535 (retrieved 7 October 2026).

About this page

Sources checked on 7 October 2026. We read the GDPR and NIS2 texts in the Official Journal versions published by the EU Publications Office, the EDPB guidelines in full, the European Parliament's procedure file for the Digital Omnibus and the Dutch parliamentary letter listed above. The scenario outcomes are our interpretation of the EDPB's examples, labelled as Validemic's analysis, and are not a substitute for your own assessment. This page is general information, not legal advice; national law and your supervisory authority's practice may add requirements. The Digital Omnibus may change the notification rules, and we will update this page when it does. If you spot an error or an outdated point, please contact us and we will correct it.