PastWipe™ adds post-breach data control inside existing environments. It complements existing security tools and does not replace them: prevention, detection and response remain essential. PastWipe adds control over how selected protected data may be used after it moves, and reduces its usable value outside approved conditions.
How PastWipe relates to your existing controls
| Existing control | What it does | What PastWipe adds |
|---|---|---|
| Identity and access management (IAM) | Authenticates users and grants access | Uses identity signals to re-check whether a specific use is still authorised at the point of use |
| Endpoint detection and response (EDR) / device management | Detects threats and reports device posture | Uses device context as a condition for releasing protected content |
| Data loss prevention (DLP) | Detects and blocks data leaving approved channels | Addresses the copy that has already left, in supported workflows |
| SIEM / SOAR | Collects events and runs response playbooks | Supplies evidence records of control decisions to your monitoring and response workflows |
| Key management (KMS / HSM) | Protects cryptographic keys | Works with organisation-controlled keys |
| Incident response / DFIR | Contains, investigates and recovers | Adds a post-breach control stage and evidence for review |
| Encryption | Protects confidentiality while keys and access stay controlled | Asks whether data should still be usable when conditions are no longer trusted |
For a longer comparison with DLP, DRM/IRM, encryption, CASB and DSPM, see Compare approaches.
Integration patterns
- Identity: enterprise identity providers supply identity signals.
- Monitoring: evidence records and control events can be streamed to SIEM/SOAR.
- Storage and applications: connectors for selected storage, databases and applications.
- APIs: for embedding policy checks into applications. Evaluation API documentation is on the PastWipe portal.
Named products and connectors are confirmed per evaluation, against your environment, rather than listed here.
What integration depth means for results
Enforcement depends on integration depth, supported applications, connectivity, device trust and identity signals. A scoped evaluation defines the data class, workflow and signals in advance, so that results can be measured.
Deployment options
PastWipe is deployed on-premises, in hybrid environments or in the customer's own cloud account, next to the systems that hold the selected protected data. PastWipe is not delivered as a shared, multi-tenant hosted service. Evaluation environments are set up per customer.
Client-controlled data and keys
PastWipe's architecture is built around a strict zero-access operating model:
- Client data remains in the client's own infrastructure, cloud account, virtual private cloud or approved trusted environment.
- Encryption and decryption take place inside that client-controlled environment.
- Cryptographic keys stay under the client's control through its own key-management system, hardware security module or equivalent.
- PastWipe does not require access to client plaintext, client decryption keys or the underlying protected information.
The zero-access operating model is scoped per evaluation, and the arrangements that apply to your evaluation are written into its scope.
A defined protection boundary
A deployment identifies where encryption occurs, where authorised processing may take place, which systems may request access and which routes must pass through the enforcement layer. This makes it possible to measure how much of the relevant workflow is actually covered.
Authorisation based on more than identity
Access decisions consider the requesting user or workload, the protected object, the permitted operation, the declared purpose, the applicable policy and the current security state. Where supported, workload and environment attestation confirms that a request comes from an approved, current execution environment.
Incident and recovery
- Scoped response: security-state changes that apply to an object, dataset, application, workload, key family, tenant, region or jurisdiction, configured per evaluation.
- Controlled recovery: revalidation, credential replacement and reauthorisation of approved workloads restore legitimate operations, with authority for the process kept by the client.
Offline and legacy environments
Offline operation is designed for defined periods and policies. Because it changes the trust model, local validation, cached authority, device integrity, expiry, reconciliation and failure behaviour are designed and tested for the specific environment. Enforcement in legacy, offline and third-party workflows is defined per deployment.
Data residency
Because PastWipe runs in the environment you choose, protected data is processed where you deploy it: in your own data centre, region or cloud account. PastWipe does not need to move protected data into a PastWipe-operated service.
- Residency and processing locations for an evaluation or contract are agreed in writing before processing starts.
- Where PastWipe staff need support access, the route, location and approvals are part of that agreement.
- UK incorporation of PastWipe Ltd is not a promise of UK-only processing.
Website data (forms, analytics after consent) is handled separately, as set out in the Privacy Policy and the Trust Centre.