After a security incident, response teams follow a familiar sequence. They contain the intrusion, then rotate everything that can be rotated: passwords, API keys, session tokens, certificates and service-account secrets. Rotation works well, and for a good reason. Those secrets were designed to be replaced. Once a new key is issued, the stolen one stops working.
Much of the data organisations hold was never designed that way. A national identity number, a date of birth, a medical history, a court case file, a biometric template or a home address cannot be reissued after an incident. These records stay valid, and sensitive, for decades. This article looks at why rotation stops short, what levers remain for data that cannot change, and how to start mapping that data in your own estate.
Why rotation works, and where it stops
Rotation is effective because it removes the value of a stolen secret without needing to find every copy. It does not matter how many times a leaked password was shared. After a reset it opens nothing.
Long-lived personal and case data behaves differently. Its value does not depend on a system accepting it. A copied identity record can be used for impersonation, social engineering or fraud whether or not the original system still exists. A copied case file can cause harm simply by being read. For this kind of data the useful life of a stolen copy is measured in years, while the incident that produced it is usually closed within weeks.
Notification, monitoring and support for affected people remain essential. But they address the consequences for individuals. They do not change what a copy that has already left can still be used for.
The questions that remain
For data that cannot change, response planning has to move from "how do we stop the stolen copy from working?" to a different set of questions:
- Where can a protected copy of this record still be opened or used?
- By whom, on which devices and in which environments?
- For what declared purpose?
- What happens to those answers when the organisation's security state changes, for example during or after an incident?
- What evidence exists of each use, so that responders and data protection officers can see what actually happened?
Traditional controls answer some of these questions inside the systems an organisation runs. Perimeter controls, access management and encryption at rest all matter. What they rarely do is keep answering once a copy of the record has moved somewhere else.
Control that travels with the data
Answering those questions after a copy has left needs control that stays attached to the data itself, and that is re-evaluated each time the data is used rather than once at the moment of access. The decision should reflect the current situation, not only the situation when the copy was made.
That is the approach behind PastWipe™, which provides post-breach data control for enterprise and government. Policy stays attached to selected high-value data. Every use of a protected copy is re-checked against identity, device, environment, declared purpose and the current security state. The answer is allow, deny or degrade, for example a reduced view, and every decision is recorded as evidence. PastWipe technology is US patent pending.
Two design choices matter here. First, PastWipe is intended for selected high-value records, not every file an organisation holds, which keeps the approach proportionate. Second, it sits alongside existing controls. Your rotation playbook stays exactly as it is. This covers the data that rotation was never able to reach.
What this approach does not do
Being clear about limits matters as much as describing capability. Per-use control applies to protected copies; it does not retroactively protect data that was never placed under policy. Decision records show what was decided and on what basis; they are technical control evidence, not a complete account of every possible exposure. And no control removes the need for good security hygiene, sound incident response and honest communication with affected people.
Start with a map
A practical first step costs nothing but time. With your security, data protection and records teams, list the categories of data you hold that cannot be rotated. Typical candidates include:
- identity data such as national ID, passport and tax numbers
- health and social care records
- legal, investigation and case files
- biometric data
- records about vulnerable people, including addresses
For each category, ask a simple question: if a copy left our systems tomorrow, what control would we still have over it, and what evidence would we have of its use? Where the honest answer is "none", you have found the gap.
Try it on fictional data
You can see per-use decisions and evidence records for yourself, with no integration and no real data, in the PastWipe sandbox: https://pastwipe.com/sandbox