Data Retention & Deletion
Last updated
On this page
There is no automatic retention
Most retention policies open by stating a period. This deployment has not set one, so nothing is deleted on a schedule: scans, findings, audit entries and agent telemetry accumulate until an operator or a user removes them.
The enforcement exists — it is off. Setting SCAN_RETENTION_DAYS turns on an hourly sweep that deletes scan history past that age. It is deliberately opt-in: a default would have started destroying history on upgrade, on the strength of a number nobody chose, with no undo.
Until you set it, retention on your deployment is whatever you enforce yourself. If you are operating this for other people and telling them you apply a retention period, that statement will not be true until you configure one.
What is stored, and for how long
| Data | Kept until | Notes |
|---|---|---|
| Scans and findings | Deleted by you | Includes raw scan evidence — response headers, discovered paths, masked secret matches |
| Finding triage decisions | Deleted with the asset | Status, owner and justification, per user |
| Assets | Deleted by you | Deleting an asset removes its scans, findings and triage history |
| Audit log | Never deleted | Deliberately — an audit log you can delete is not an audit log. Entries are redacted rather than removed when a user is erased |
| Agent sessions and events | Deleted with your account | Arguments are stored as a hash, never as their contents |
| Sessions and API keys | Until expiry or revocation | Sessions expire; API keys last until revoked |
| Account | Until you erase it | See below for what erasure does and does not remove |
How to delete things
Deletion is real and immediate — rows are removed, not flagged.
- A single scan — removes that scan and its findings. Triage history for the asset survives, since it belongs to the asset rather than to one scan.
- An asset — removes the asset, every scan of it, every finding, and the triage history. Requires confirming the hostname, because it is not recoverable.
- Your account — removes your sessions, API keys, agent telemetry and triage decisions, and every scan you triggered. Assets you created that nobody else has scanned are deleted; assets others have also scanned are kept but disassociated from you.
What deletion does not remove
Stated plainly, because each of these surprises somebody:
- Audit log entries survive account erasure. They are redacted — your email is replaced with a marker and the user reference removed — but the record that an action happened remains. An audit log that disappears when the person responsible deletes their account provides no accountability at all.
- Shared assets survive. If a colleague has also scanned an asset you created, deleting your account does not delete their scan history.
- Database free pages may retain deleted content until reclaimed. Deleting a row marks its space reusable rather than overwriting it. Run
VACUUMif you need the bytes genuinely gone. - Backups and snapshots are outside this application entirely. Whatever deletion removes here, it cannot reach a copy your infrastructure made yesterday.
Exporting your data
A complete JSON export of everything associated with your account is available from your account page: assets, scans, findings, triage decisions, agent sessions, API key metadata (never the keys themselves), and your audit entries. It is generated on request from live data rather than a periodic dump, so it is current at the moment you ask for it.
Backups and copies
This application takes no backups. Whatever backup regime exists is one your infrastructure provides, and its retention is governed by your configuration, not by anything here. If you are making a retention commitment to anyone, your backups are the part most likely to break it.