On 23 April 2025, the Legal Aid Agency spotted an attack on its online digital services. By 16 May it knew the attack was worse than first thought and told anyone who had applied for legal aid since 2010 to be on their guard. On 14 October 2026, almost eighteen months after the first detection, it published an update. The stolen data now goes back to 1978.
The LAA's update is candid about why. The affected systems held "unstructured, fragmented, or incomplete" data, which made analysis complex. As it got better at identifying what was there, the picture changed, and earlier updates no longer reflected it. Most of the data covers applications, claims and payments from January 2007 onwards. About 250,000 records predate 2007, and the earliest verified record is from 1978. Probation data from 2010 to 2017 was also taken, along with information about judges, solicitors, court reporters and opponents in civil cases.
This isn't a post about the LAA. Most organisations would struggle in the same way. It's about the question every breach comes down to, what did they take, and whose was it?, and why so few organisations can answer it quickly.
Scoping is the slow part of every breach
Containing an intrusion is usually measured in hours or days. Scoping it is measured in weeks or months, and the scope is what everything else waits on: notifying the ICO and the people affected, briefing the board, dealing with regulators, contracts and insurers, and deciding how worried to be.
Under UK GDPR you have 72 hours to report a personal data breach to the ICO where feasible, and you can provide information in phases if you don't yet have it all. That's a sensible rule, but it makes the gap obvious. You know quickly that something happened. Knowing what it touched can take much longer.
Scoping is slow for the same reasons almost everywhere:
- Nobody has a full map of the data. Inventories cover the systems someone thought to register. They miss the exports, the shared drives, the legacy database kept "just in case" and the data a migration brought along without anyone asking.
- Old data never left. Records from 1978 were still within reach in 2025. Retention schedules exist on paper far more often than deletion happens in practice.
- Unstructured data resists search. Scanned forms, free-text fields, attachments and spreadsheets don't come with a column that says whose data they are. Working out who is in a stolen file share means reading it.
- The logs don't go back far enough, or don't say enough. If file and database access wasn't logged, or was logged with 30-day retention, the forensic team ends up reconstructing what was taken from what was reachable. That always produces a bigger, vaguer answer.
- Legacy systems are hard to investigate. The LAA says it has since retired or isolated higher-risk technology and begun modernising legacy systems. Old platforms are often the ones with the weakest logging and the least documentation.
You can't scope a breach of data you never mapped
The useful lesson here is that how fast you can scope a breach is decided long before the breach. By the time a forensic team arrives, nearly everything that determines how long the job takes is already fixed: what data exists, where it lives, how long you've kept it and what was logged about access to it.
Investment in detection and response focuses, reasonably, on catching intrusions quickly. The investment that shortens the months that follow is less exciting, and it's mostly governance.
Five things that shorten the months after a breach
1. Know where the personal data is, including the old stuff
Map the systems that hold personal and sensitive data, and include the legacy ones, archives and file shares. For each, record whose data it is, roughly how much, and the date range. Then you can answer "which systems could the attacker reach?" and "whose data is in them?" without starting from scratch.
2. Delete what you no longer need
Data you deleted years ago can't be stolen. Retention schedules only reduce risk when deletion actually happens, so check it, especially on systems that predate the current schedule.
3. Log access to the data, not just to the network
Network and sign-in logs tell you an attacker was present. Data access logs tell you what they touched. Turn on auditing for the databases, file shares and SaaS platforms that hold personal data, including Microsoft Purview audit for Microsoft 365, and send it to your SIEM.
4. Keep logs long enough to cover how long attackers stay hidden
Intrusions are often found weeks after they began. If your retention is shorter than that, the evidence you need will be gone before you go looking. Keep high-value logs for long enough to look back across the likely dwell time. Long-term or archive tiers in Microsoft Sentinel make this affordable for the logs that matter.
5. Rehearse the scoping question
Tabletop exercises usually stop at containment. Run one that keeps going: an attacker had access to a given system for three weeks, so what data was in it, whose was it, and how would you prove what was taken? If the answer is "we'd have to find out", you've found your gap without having a breach first.
The wider point
The LAA deserves some credit for publishing a frank update rather than leaving the earlier, smaller picture in place. Most organisations never find out how far back their exposure really went. The ones that get through a breach best aren't always the ones that stopped the attacker fastest. They're the ones that could quickly say, with evidence, what was taken and whose it was, then tell those people and move on.
That ability is built in peacetime. It comes from an inventory, a retention policy that is actually enforced, and logs that cover the data and are kept long enough to be useful.
If you'd like help working out how quickly you could scope a breach today, or need an investigation now, talk to our team.