PastWipe

Insights

What remains usable after a data breach?

Containment ends the incident, not the exposure. How to judge which copied records stay useful, for how long, and what you can still control after a breach.

By Ralph Ehlers · Published

What remains usable after a data breach?

Most incident timelines end with three words: contained, recovered, notified. The attacker is out, systems are restored, the regulator and affected people have been told. For the organisation, the incident is closed.

For the data that left, nothing has closed. A copy taken during the incident does not expire when the ticket does. It can be searched, merged with other datasets, resold, used for targeted fraud or simply kept until it becomes useful. The question that matters after a breach is therefore not only "what left?" but "what remains usable, for how long, and by whom?"

This article sets out a practical way to answer that question, using three public cases from 2026 as reference points. It also describes, with its limits, where post-breach data control fits.

Three public reference points

Records that outlive their systems. On 14 October 2026 the Legal Aid Agency published an update on the cyber-attack it identified in April 2025. Further analysis found that about 250,000 exfiltrated records predate 2007, mostly from the 1990s and 2000s, with the earliest verified record dating from 1978. Some probation data was also found in the material. The agency notes that the data was often unstructured, fragmented or incomplete, which made the analysis complex, and that it has no indication the stolen data has been published or shared. (GOV.UK)

Copies that do get published. In May 2026 the ICO fined South Staffordshire Plc and South Staffordshire Water Plc following an attack that began with a phishing email in 2020 and went undetected for about 20 months. Between August and November 2022, the company detected more than 4.1 terabytes of data published on the dark web, including personal information about 633,887 people: names, addresses, dates of birth, bank account numbers and, for some customers on the Priority Services Register, information from which disabilities could be inferred. (ICO news release, ICO enforcement notice)

Lawful access, unlawful use. On 5 October 2026, Denmark's central population register (CPR) announced that unauthorised parties had misused a Danish company's lawful access to the register and obtained names, addresses and CPR numbers for about 8.8 million registered people. The company's access was stopped, the Danish data protection authority was notified and the police are investigating. (CPR administration, in Danish, ministry press release, in Danish)

These cases differ in cause, sector and outcome, and none of them is used here to suggest what any organisation should have done. What they share is the shape of the exposure: once data leaves, its usefulness is governed by its own lifetime, not by the incident's.

Four questions that define post-breach exposure

A breach report normally counts records and categories. To understand what remains usable, add four questions.

1. Which copied records are still useful?

Not every record carries the same exposure. A national identifier, a date of birth or a bank account number stays useful for years. A session token may lose its value within hours. Health, legal and financial records are useful for both fraud and coercion. Start by grouping the exfiltrated data into classes by how long each stays valuable to someone who should not have it.

2. For how long?

The Legal Aid Agency update is a reminder that organisations hold records for decades. Retention schedules, archive migrations and legacy systems all extend the window in which a copy can do harm. The useful life of stolen data is set by the data, and some of it is measured in decades.

3. Through which workflows?

Data becomes harmful when someone can use it: open it, search it, join it with another dataset, feed it into a fraud script or a model. Mapping those workflows shows where control is still possible. A spreadsheet opened in an office application, a record retrieved through an API and a file pushed into a cloud service are different paths with different control points.

4. Under whose authority?

The Danish case turns on this question. The access was lawful; the use was not. Many controls verify that an identity is allowed in. Fewer verify, at the moment of each use, that the request still matches the purpose and conditions under which access was granted.

What can still be controlled after the copy exists

Honest answers matter here, because the limits are real.

  • Plaintext is plaintext. Data exported in clear form, outside any protected workflow, cannot be called back. Prevention, minimisation and encryption remain the first line.
  • Screens can be photographed. No technical control stops someone photographing content once it is displayed.
  • Unsupported applications are outside the boundary. Any post-breach control works only in the workflows it supports.

Within those limits, there is a meaningful category of data that can still be governed after it has been copied: selected high-value data that stays protected, with policy attached, and that can only be opened or used through supported workflows. For that data, each use is a decision point.

Where post-breach data control fits

PastWipe™ provides post-breach data control for enterprise and government. Policy stays attached to selected high-value data. Each time protected data is used, PastWipe re-checks the conditions in that policy: identity, device, environment, time, declared purpose and the current security state. The result is to allow, deny, restrict or degrade the use, and each decision is recorded as evidence.

When an organisation declares an incident, it can change the security state for the affected data, workload or environment. Later requests in that scope are judged against the new state, while unaffected work continues. The decision records then show what was requested after the incident, by which identity and device, and what the answer was.

This does not replace prevention, detection or response, and it does not change what happened to data that left in plaintext. It adds a control for the part of the exposure that would otherwise be left to chance: protected copies that are used after trust has been lost.

A practical next step

If you want to apply these four questions to your own estate, begin with one data class and one workflow:

  1. Choose the data class that would cause most harm if copied and kept for ten years.
  2. Map how it is used and where copies end up, including partners and cloud services.
  3. Decide which uses should still be allowed after an incident, and which should not.
  4. Decide what evidence you would need to show a regulator, an insurer or the people affected.

You can explore this on fictional data in the PastWipe sandbox, including the "Steal this file" challenge, where your team attempts to misuse a protected file and reviews the evidence each attempt leaves. Each request is reviewed individually.

Request sandbox access: https://pastwipe.com/sandbox

PastWipe technology is US patent pending.

Sources

All insights · Get the quarterly Post-Breach Briefing