PastWipe™ is built on one principle: protected data should not be treated as permanently trusted merely because access was valid when it was first obtained. It reduces the usable value of stolen or exfiltrated data outside approved conditions, and it works alongside the security tools you already run.
The control cycle
1. Protect selected data
Start with information and workflows where post-breach misuse would cause material financial, operational, legal or public harm. Examples include customer records, regulated files, contracts, intellectual property and sensitive exports. PastWipe is not meant to protect every file in the same way.
2. Attach policy
Define the conditions under which the data may be opened, validated, rendered, transferred or relied upon: authorised purpose, identity, device, environment, time and other approved conditions.
3. Evaluate context at the point of use
Before protected content is released, rendered or accepted, PastWipe checks whether current conditions still satisfy the policy. It uses available identity, device, environment, time, purpose and attestation signals.
4. Enforce and record
The control decision is to allow, deny, restrict or degrade. Each decision creates an evidence record showing what was requested, what was evaluated and what was allowed, denied, restricted or degraded. The record supports operational review, audit and incident investigation.
Core capabilities
| Capability | What it does |
|---|---|
| Policy | Defines the conditions for use: authorised purpose, identity, device, environment, time and other approved conditions. |
| Validation at the point of use | Re-checks those conditions before protected content is released, rendered or accepted, not only when access was first granted. |
| Identity and device context | Uses signals already available from your identity provider, device management and environment controls. |
| Purpose-bound, time-limited use | Ties use to a declared purpose and time window, and can restrict, expire or withdraw use where the workflow remains under supported control. |
| Control decisions | Allows, denies, restricts or degrades the result according to policy. |
| Evidence records | Records what was requested, evaluated, allowed, denied, restricted or degraded, for audit, investigation, legal and insurance review. Evidence records |
How the parts fit together
- Policy engine: applies your rules and conditions.
- Validation and attestation: checks identity, device and environment context at the point of use.
- Key integration: works with the organisation's own key-management systems.
- Evidence layer: produces verifiable records of decisions.
- Connectors: work with existing storage, applications and security tooling. Integrations and deployment
- RepSec™ protocol (optional): consistent policy and evidence exchange across participating systems. RepSec
When trust changes
If an incident is declared, a device or identity is no longer trusted, or a policy changes, subsequent requests are evaluated against the new state. Controls can be scoped to the affected data, workload or environment so that unaffected operations continue.
Scoped incident states change the security state for one object, dataset, workload or environment at a time. Their scope is agreed for each evaluation. Scope an evaluation
What shapes the outcome
The result in a given deployment is shaped by:
- the protected format and supported applications
- integration depth and how much of the workflow the organisation controls
- the quality and availability of identity, device and context signals
- connectivity, and how offline operation is designed
- whether an unrestricted plaintext copy already exists
Enforcement scope
PastWipe is evaluated against a defined data class and workflow, with success criteria agreed before deployment. The full enforcement scope is set out in the Trust Centre.
Where RepSec fits
RepSec™ is an optional protocol framework for expressing policy, validation and evidence consistently across participating systems. PastWipe operates without it. About RepSec
Common questions
Do we need RepSec? No. PastWipe works on its own.
Does PastWipe replace our existing tools? No. It sits after prevention and detection and works with IAM, EDR, DLP, SIEM and incident response.
What happens during a breach? Requests for protected data are evaluated against the current security state. Uses that no longer meet policy can be denied, restricted or degraded, and those decisions are recorded. Copies that have already become unrestricted plaintext are outside enforcement.
Next step
Scope an evaluation · Compare approaches · Integrations and deployment
