When I review identity risk with a management team, I want to understand what an account allows someone to do after they sign in. A login policy is only part of that discussion. The permissions behind it determine how much of the business an attacker could reach.
DTU's breach notice is a useful starting point for that conversation. It also shows why public incident analysis needs to stay close to what the organization has actually reported.
What DTU has confirmed
On October 2, 2026, the Technical University of Denmark said attackers used compromised DTU profiles to access DTUBasen, its identity and access management system, and download data. Up to 200,000 current and former users may be affected. DTU could not establish exactly what was downloaded or how many people were affected.
The notice does not establish the initial method of account compromise. I would not use it to claim that credential stuffing, an exposed login page, or a particular software vulnerability caused the incident.
The recommendations that follow are the review I would suggest for another organization. They are not findings about DTU's internal controls.
Start with one account and follow its access
For a US company considering what this incident means for its own operations, I would start with a practical exercise. Choose an account with a business reason to access personal information. Bring together the person responsible for the application, the security team, and the owner of that information.
Ask them to demonstrate what the account can see and do. Can it read individual records, search across departments, download attachments, or export an entire dataset? Does it inherit permissions through a group that nobody has reviewed recently? Can an integration use the same access without the employee opening the application?
Use a controlled test account and non-sensitive test data where possible. The purpose is to understand effective permissions without creating another copy of sensitive information.
I would compare each capability with the task the employee is expected to perform. Where the two do not match, identify who can approve a narrower permission and what business process might be affected. That makes the discussion specific enough to resolve.
Look beyond successful authentication
I would still examine how the account is protected: multifactor authentication, recovery procedures, session controls, and the process for removing access. But I would also ask what the organization records after a login succeeds.
Can the application show which records were accessed? Are exports logged? Can investigators connect an action to an account, a session, and a time? Does anyone receive an alert when access changes significantly from that account's normal work?
An alert needs an owner and a response. If the team can identify an unusual export but cannot say who reviews it or how quickly access can be restricted, the exercise has uncovered work that management can assign.
I would test that response safely. Agree on an authorized scenario, carry it out with test data, and check whether the expected records and notifications appear. Document missing evidence as well as successful detection. The result should explain what the organization could reconstruct if an account were misused.
Review the information you continue to hold
Access reviews should include retained information about former employees and partners. Disabling a person's account does not, by itself, remove the records about that person from applications, archives, or integrations.
I would ask the data owner to explain the purpose of retaining each category of information, the applicable retention requirement, and who still needs access. Where deletion is appropriate, check that it can be carried out and verified across the relevant systems. Legal holds and other retention obligations need to be resolved before records are removed.
Historical data may have a legitimate business purpose. The decision should be deliberate and documented, with a review date. Otherwise, information can remain accessible simply because nobody owns the decision to remove it.
Give management a decision it can make
A useful report from this exercise can fit on one page. I would include the account or role reviewed, the information it can reach, the business reason for that access, the evidence available to investigate misuse, and the unresolved questions.
Each proposed change should have an owner and a date. For example, an application owner might narrow export permissions, security might test an alert, and the data owner might confirm a retention schedule with legal. These are recommendations to assess in context, not a claim that every organization needs the same configuration.
If a limitation cannot be fixed immediately, record the temporary controls and who accepts the remaining risk. Management then has a clear choice about priorities and resources.
Where I would begin
I would put one sensitive application on the agenda for the next risk discussion and ask its owner to demonstrate what a compromised account could reach. Follow that with a second question: what evidence would we have of what it did?
Those answers give the team a starting point for reducing access, improving investigation capability, and reviewing retained data. They also give management a way to check whether the agreed work actually changed the exposure.
If you want to work through that review in your organization, you can book a 30-minute introductory call with me. It is free and carries no obligation; it is a conversation about your needs, not a technical assessment.
Book an introductory call
Sources
DTU, October 2, 2026: Cyberattack notification. Incident facts checked October 6, 2026. The management recommendations are my assessment.
DTU: official breach notification