Data Retention
The scanner purges data it has kept longer than the retention window. Every day at 03:00 server time a purge deletes records whose timestamp is older than the cutoff.
The window defaults to ten years and is set with retention.window, an
ISO-8601 period - P10Y for ten years, P18M for eighteen months, P90D for
ninety days. Audit events are not purged by default.
| Setting | Default | Meaning |
|---|---|---|
retention.window | P10Y | How long retention-managed data is kept. |
retention.purge-audit-events | false | Whether the purge also deletes audit events. |
As environment variables these are RETENTION_WINDOW and
RETENTION_PURGE_AUDIT_EVENTS.
A window of zero or a negative period is rejected at startup rather than accepted: it would place the cutoff at or after the present moment and the next purge would delete every record it manages.
What is purged
| Data | Effect of the purge |
|---|---|
| Findings | Findings older than the cutoff are hard-deleted. |
| Finding occurrences | Occurrence history for expired findings. |
| Finding review events | The review history attached to expired findings. |
| Scan runs | Expired runs disappear from the scan history. |
| Scan work items | The per-issue work records of expired runs. |
| Rule versions | Superseded rule versions older than the cutoff. Current versions are never purged. |
Deletion is a hard delete, not a soft flag. Rules, scan configurations, suppressions, the Jira connection, the license, and reporting settings are not subject to retention - they persist until you remove them.
Audit events are kept
The audit log is the evidence the scanner produces: who reviewed which finding, when a rule changed, what each purge removed. It is deliberately outside the purge, so by default it is retained for as long as you keep the database, outliving both the retention window and the Jira instance the findings came from.
If your own policy requires audit entries to expire, set
retention.purge-audit-events to true. They are then purged on the same
window as everything else. There is no separate window for them.
Auditing
Every purge writes one audit event: actor SYSTEM, action RETENTION_PURGE,
target type RETENTION. Its metadata records the cutoff timestamp, the
configured window, whether audit-event purging was enabled, and the number of
rows deleted per category, so a purge is always reconstructable from the
audit log even after the data itself is gone.
Running a purge on demand
Administrators can trigger a purge immediately instead of waiting for 03:00, via the admin-only API endpoint. There is no button for this in the UI, deliberately - it is a maintenance operation, not a daily task.
curl -X POST https://riskscanner.example.com/api/retention/purge \
-H "Authorization: Bearer <admin-access-token>"
The response reports the cutoff and the deleted-row counts, and the run is audited exactly like the scheduled one.