Post-breach data control
PastWipe™ addresses the stage conventional cybersecurity cannot guarantee: what happens after protected data is copied, exposed or exfiltrated.
It combines policy-aware control, cryptographic validation, identity and device context, and evidence records to reduce the usable value of stolen or exfiltrated data outside approved conditions.
PastWipe complements existing identity, endpoint, network, DLP, monitoring and incident-response systems. It does not replace them.
Scope a controlled evaluation · Explore capabilities · Contact PastWipe
Post-exfiltration focus · Policy-aware control · Evidence records · RepSec optional
Control follows the protected data
At the point of use, PastWipe asks one question: is this use still authorised under the declared conditions?
- Policy: define acceptable use. Associate protected data with rules covering authorised purpose, identity, device, environment, time or other approved conditions.
- Validation: re-check at the point of use. Evaluate whether current conditions still satisfy the policy before protected content is released, rendered or accepted.
- Evidence: record the control decision. Support review, audit and incident analysis with records showing what was requested, evaluated, permitted, denied or degraded.
The precise decision model depends on the deployment, data type, workflow and level of integration. How PastWipe works
Prevention matters. It is not the final control point.
Firewalls, EDR, IAM, DLP, SIEM and incident response are essential. But once a usable copy leaves the protected environment, the organisation can lose practical control over how long it remains useful, where it is used and who can rely on it.
PastWipe sits after prevention, not instead of it. The objective is not to promise that every breach can be stopped. It is to reduce the consequences when prevention, detection or human behaviour fails.
| Stage | Controls | Role |
|---|---|---|
| 1. Prevent | Identity, endpoint, network, DLP and access controls | Essential |
| 2. Detect | Monitoring, telemetry, analytics, SIEM and SOC | Essential |
| 3. Respond | Containment, investigation, recovery and notification | Essential |
| 4. Control after movement | Policy validation, restricted use, degradation and evidence | PastWipe |
- Keep the existing security stack in place.
- Add control to selected high-value data and workflows.
- Re-evaluate use after copying, movement or loss of trust.
- Generate evidence for technical, legal, compliance and insurance review.
How the control cycle works
Protected data should not be treated as permanently trusted merely because access was valid when it was first obtained.
- Protect selected data. Apply PastWipe to information and workflows where post-breach misuse would cause material financial, operational, legal or public harm.
- Attach policy. Define the conditions under which the data may be opened, validated, rendered, transferred or relied upon.
- Evaluate context. Use available identity, device, environment, time, purpose and attestation signals to test whether the use remains legitimate.
- Enforce and evidence. Permit, deny, restrict or degrade the result, then create evidence suitable for operational review and investigation.
PastWipe and RepSec
Product layer and protocol direction, clearly separated.
PastWipe is the deployable post-breach control product. It is designed to work within existing environments and can be integrated into selected applications, data flows and enterprise controls without waiting for a new internet-wide standard.
RepSec™ is an optional protocol framework intended to help different systems express policy, validation and evidence in a more interoperable way. RepSec-Q is a development direction toward post-quantum resilience.
- RepSec is optional. It is not required to deploy PastWipe.
- RepSec is not presented as a universally adopted standard.
- Post-quantum claims depend on the selected cryptography and implementation.
What PastWipe cannot do
Credible security requires clear boundaries. PastWipe reduces risk in supported, policy-aware workflows. It does not claim to remove every form of copying, disclosure or misuse.
- It cannot guarantee that data will never be stolen. PastWipe is not a substitute for access control, endpoint protection, network security, DLP, monitoring, backup or incident response.
- It cannot stop photographs, screenshots or manual retyping in every case. An authorised viewer may still photograph a screen or retype content.
- It cannot reliably revoke copies that have already become independent plaintext. The strongest control applies before or during authorised use. Once data is exported into an unsupported, unrestricted format, enforcement may be reduced or lost.
- It cannot offer identical enforcement across every legacy, offline or third-party workflow. Results depend on integration depth, supported applications, connectivity, device trust, identity signals and how much control the organisation retains over the workflow.
The practical objective is to materially reduce the value, reliability and legitimate usability of protected data after trust is lost, without pretending that software can defeat every human or physical copying method.
Priority environments
PastWipe is most relevant where copied data stays valuable long after the breach itself: regulated information, financial records, citizen data, intellectual property, operational documentation and sensitive evidence.
- Enterprise and corporate
- Insurers
- Government and public sector
- Banking and financial services
- Law firms
- Healthcare
- Education and research
- Legal and intellectual property
- Marine
Technical evaluation
The right question is not "Does it stop every breach?" The useful question is whether PastWipe can reduce exposure for a defined data class, within a defined workflow, under measurable operating conditions.
- Scope: which data genuinely needs post-breach control? Data class and sensitivity, expected users and systems, consequences of unauthorised reuse.
- Conditions: which signals are available and trustworthy? Online and offline operation, legacy and third-party dependencies, failure and recovery behaviour.
- Evidence: what result can be measured and defended? Allow, deny and degradation outcomes, false-positive and availability impact, logs and review evidence.
Frequently asked questions
Does PastWipe replace DLP, EDR, IAM or incident response? No. Those controls remain essential. PastWipe adds a separate layer aimed at maintaining control after protected data has already moved beyond the original trust boundary.
Does PastWipe stop every stolen file being used? No universal claim is credible. The achievable outcome depends on the protected format, integration, workflow, policy, available context signals and whether an unrestricted plaintext copy already exists. The objective is measurable reduction of utility and legitimate acceptance under unsupported conditions.
Is RepSec required? No. PastWipe can operate without RepSec.
Can PastWipe work offline? Offline operation may be possible for defined periods and policies, but it changes the trust model. Local validation, cached authority, device integrity, expiry, reconciliation and failure behaviour must be designed and tested for the specific environment.
Is this a replacement for encryption? No. Encryption protects confidentiality when keys and access remain controlled. PastWipe addresses whether data should still be usable when the surrounding conditions, identity, device or purpose are no longer trusted.
Evaluate post-breach control against a real workflow
Define the data, threat, operating conditions and measurable outcome. PastWipe can then be assessed as an additional control layer, without replacing the security systems already in place.
Scope a controlled evaluation · Request an executive briefing
