Security architects who see PastWipe™ for the first time often ask a reasonable question: "Isn't this rights management?" Both approaches keep protection attached to data rather than to the network it sits on. Both can follow a file outside the organisation. The overlap is real.
The difference lies in the question each one is designed to answer, and in what happens when circumstances change after access has been granted. This article sets out where the boundaries sit, so that teams can decide where each belongs in their architecture. It is written to help evaluation, not to rank products.
What information rights management does well
Information rights management (IRM), often called digital rights management for documents, applies encryption together with identity and authorisation policies to files and emails. Microsoft's documentation for its Azure Rights Management service, a widely deployed example, describes it as protecting files and emails through a combination of encryption, identity and authorisation policies, with encryption settings that remain with the data even when it leaves the organisation's boundaries. (Microsoft Learn)
In practice, IRM is strong at:
- Persistent protection. A protected document stays encrypted when it is emailed, copied to removable media or uploaded to a cloud drive.
- Permission sets. Owners can define who may view, edit, print or forward content.
- Broad integration. Mature IRM services are built into common office applications and email clients.
- Classification-driven workflows. Labels applied by users or automatically can trigger protection at scale.
For organisations that already run IRM, it remains a valuable control. Nothing in this article argues for removing it.
The question IRM is designed to answer
IRM answers a permissions question: is this identity entitled to perform this action on this item? Once an identity has been granted the right to open a document, the main conditions have been met. Revocation exists, but it is typically an administrative act on a document or a user, taken after someone has decided that something is wrong.
That design suits ordinary operation well. It is less suited to the period after trust has been lost, when the relevant question changes.
The question post-breach data control is designed to answer
Post-breach data control asks a different question: given everything we know now, should this particular use still be allowed?
That question includes the identity, but it does not stop there. In PastWipe, policy stays attached to selected high-value data, and each time protected data is used, the conditions in that policy are re-checked: identity, device, environment, time, declared purpose and the current security state. The result is to allow, deny, restrict or degrade the use, and every decision is recorded as evidence.
Three differences follow from that design.
1. Security state is part of every decision
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. A use that was allowed before the declaration can be denied or degraded afterwards, without anyone needing to identify and revoke individual documents or users first. Work outside the declared scope continues.
This mirrors the direction set out in NIST's zero trust architecture guidance, which describes moving defences "from static, network-based perimeters to focus on users, assets, and resources". (NIST SP 800-207) Post-breach data control applies that principle at the level of the data itself, and keeps applying it after the data has moved.
2. Purpose, not only permission
The Danish CPR incident announced on 5 October 2026 is a public example of the gap between permission and purpose. According to the CPR administration, unauthorised parties misused a company's lawful access to the register to obtain names, addresses and identity numbers for about 8.8 million people. (CPR administration, in Danish) The access was valid; the use was not. That case involved a register lookup service rather than documents, and it is cited here only to illustrate the principle: a permission check alone does not establish that a particular use matches the purpose for which access was granted. Declared purpose is one of the conditions PastWipe evaluates at each use.
3. Evidence as an output, not a by-product
IRM services log access, and those logs are useful. Post-breach data control treats the decision record as a primary output: what was requested, by which identity and device, under which policy and declared purpose, in which security state, and whether it was allowed, denied or degraded. After an incident, those records answer the questions regulators, insurers and boards ask: who used this data after trust was lost, and what happened when they tried?
Side by side
| Question | Information rights management | Post-breach data control (PastWipe) |
|---|---|---|
| Core question | Is this identity entitled to this action? | Should this use still be allowed, here, now, for this purpose? |
| Conditions evaluated | Identity and assigned rights | Identity, device, environment, time, declared purpose, security state |
| Response to an incident | Administrative revocation of documents or users | Declared security state applied to later requests in scope |
| Outcomes | Permit or refuse an action | Allow, deny, restrict or degrade |
| Evidence | Access logs | Decision record for every use |
| Typical scope | Broad document and email protection | Selected high-value data and workflows |
Where the boundaries are shared
Both approaches have the same honest limits, and buyers should hear them plainly:
- Displayed content can be photographed. No document or data control prevents a camera.
- Plaintext outside protection is outside control. Data exported in clear form before protection was applied cannot be governed afterwards.
- Unsupported applications fall outside the boundary. Each control works only where it is integrated.
These limits are a reason to scope carefully, not a reason to avoid either control.
How they fit together
For most enterprise and government teams, the realistic answer is "both, in different places":
- Keep IRM for broad document and email protection across the organisation.
- Apply post-breach data control to a small number of high-value data classes where the cost of a copy being used after an incident is highest: case files, identity records, financial extracts, partner data exchanges.
- Use the PastWipe decision records alongside existing logs in incident response and supervisory reporting.
A sensible evaluation starts with one data class and one workflow, keeps every existing control in place and asks one question: after we declare an incident, what happens to the next request for this data, and can we show it?
Compare approaches: https://pastwipe.com/compare/ Try it on fictional data: https://pastwipe.com/sandbox
PastWipe technology is US patent pending.
Sources
- Microsoft Learn, "What is Azure Rights Management?": https://learn.microsoft.com/en-us/azure/information-protection/what-is-azure-rms
- NIST, SP 800-207 "Zero Trust Architecture": https://csrc.nist.gov/pubs/sp/800/207/final
- CPR-administrationen, "Omfattende uautoriseret adgang til borgeres CPR-oplysninger", 5 October 2026 (Danish): https://www.cpr.dk/cpr-nyt/nyhedsarkiv/2026/okt/omfattende-uautoriseret-adgang-til-borgeres-cpr-oplysninger