Why retention periods are also a security factor: 600,000 records affected after cyberattack

A cyberattack – and suddenly decades-old data becomes an issue

On September 16, 2026, Ludwig-Maximilians-Universität München noticed an unauthorized attack on one of its IT systems. Only a few days later did it become clear how large the affected data set is. According to the forensic findings of LMU dated September 28, 2026, the entire data set of the admissions system was affected. LMU estimates around 600,000 records of current and former students. Some of the enrollment data they contain go back about 50 years.

The case therefore shows not only what consequences a cyberattack can have. It also draws attention to a question that easily fades into the background in everyday data protection:

Which personal data are actually still stored in our systems, and do we really need them?

Which data are affected?

According to information from LMU, the affected data set comprises around 600,000 records of current and former students. Depending on the period, they include identity and contact data, information on the course of studies and, in some cases, bank details, health insurance or BAföG numbers. In individual cases, information on reasons for leave of absence – and thus possibly special categories of personal data under Art. 9 GDPR – may also be affected.

According to LMU, passwords, examination information, specific course content and individual performance are not affected. As of the published status, there were no indications that the data had been published or misused.

Why were data from around 50 years stored at all?

The LMU explains in its information on the data protection incident: certain study information is needed in the long term, for example as later proof for the pension insurance. According to its own statements, the university therefore follows a retention period of around 50 years, which is common in higher education. After all, data stored for a long time are not automatically stored unlawfully.

It is not the age of a record that determines whether it must be deleted. What matters is whether there is still a reason to store it. Companies should therefore be able to answer for their own data holdings: Why do we still need these data, and for how long?

The GDPR does not prescribe a uniform retention period

The GDPR contains no general retention period such as “personal data must be deleted after five or ten years”. Art. 5(1)(e) GDPR instead contains the principle of storage limitation. Personal data may, in principle, only be kept in a form that permits identification of the data subjects for as long as is necessary for the purposes of processing.

The appropriate retention period depends on the data in question. Certain documents must be kept for years due to legal requirements. Other personal data may only be needed for the duration of a contract or a specific process. And still other data lost their original purpose long ago. What matters, therefore, is not how old a record is. What matters is whether there is still a legitimate purpose or a retention obligation for keeping it.

Why deletion is also a security measure

Retention periods are often seen only as a data protection obligation. The LMU case, however, shows another aspect. Every personal record that remains stored in a system can, in principle, also be affected by a security incident.

This does not mean that data may be deleted merely out of fear of cyberattacks if there is a statutory retention obligation. Conversely, however, companies should not keep personal data indefinitely just because storage space is cheap or the information “might be needed again someday”.

A consistently implemented deletion concept reduces the data stock to what is actually still needed. In an emergency, this can make a considerable difference: what has been lawfully deleted and is no longer present in the attacked system cannot be exfiltrated from it in a later cyberattack. The connection follows from the principle of storage limitation under Art. 5(1)(e) GDPR and the requirements for the security of processing under Art. 32 GDPR.

Old data holdings quickly slip out of sight

Historically grown systems are particularly relevant here. A new system is introduced, data are migrated and the old system is kept just in case. A former customer has long been inactive, but their data are still in the CRM. Application documents are still in old folders. Mailboxes of former employees are kept for years.

Such holdings often go almost unnoticed in day-to-day work. In a security incident, however, they can suddenly become relevant.

That is why it is not enough to define retention periods once in a table. Companies should also check whether the planned deletions are actually implemented technically and whether there are legacy holdings for which no one is responsible anymore.

What companies should now consider

The incident is a good opportunity to look at your own data holdings from a different perspective. A few simple questions can help:

The last point in particular is important. A deletion concept that is created once and then never looked at again is of little help in practice.

Systems change, new processing activities are added and legal requirements can change. Retention periods should therefore be reviewed regularly and adjusted where necessary.

The incident also shows how important a prepared emergency process is

After the first signs of the attack, the university isolated, according to its own statement of September 19, 2026, the affected server from the network. Further systems were shut down and checked as a precaution. In addition, IT forensic experts, security specialists and the competent investigative and supervisory authorities were called in. Security monitoring was extended.

In accordance with Art. 34 GDPR LMU also provided information about the data protection incident and published guidance for potentially affected persons. Among other things, it advises particular caution with suspicious e-mails, calls or messages relating to the university.

Companies should define in advance who is involved in a security incident, how affected systems are secured, who carries out the data protection assessment and when a report to the supervisory authority or a notification of the data subjects is required.

Conclusion

The cyberattack on LMU Munich vividly shows how large the affected data stock can become when a system contains information from many years. However, this does not mean that old data were automatically stored unlawfully. What matters is whether there is still a comprehensible purpose or a legal basis for storing them further.

For companies, it is therefore worth taking a regular look at their own data holdings:

A functioning deletion concept therefore does more than fulfill a data protection requirement. At the same time, it can help to reduce the amount of personal data that could be affected by a later security incident at all.