Evidence retention

fremforge keeps six kinds of evidence about your organisation. Each has its own retention setting with bounds, and a documented default that is what every organisation had before the settings existed. An owner changes them under Reports → Evidence retention in the admin console, or with the API.

The classes

Class	What it is	Default	You can set	Deleted by
`audit_payload`	The actor and fields of each audit log event. After the cutoff the event, its time and its hash-chain entry remain.	90 days (365 on enterprise, custom-trial and internal plans)	90, 180, 365 or 730 days	the daily audit payload redaction
`access_log`	The registry access log: who downloaded, uploaded or deleted which package, from which IP address.	follows `audit_payload`	30 to 730 days	the daily access log retention job
`findings_history`	Findings that were resolved: package, malicious-dependency and SHA-pinning findings. Open and dismissed findings are current state and are not affected.	kept for as long as the organisation exists	365 to 3650 days	the nightly retention reaper
`sbom`	SBOMs of builds that were not released. Release SBOMs, the default branch head’s, current images’ and package files’ SBOMs are kept.	14 days	0 to 3650 days	the daily SBOM prune
`attestation`	SLSA provenance attestations and their Sigstore bundles. One bound to an immutable release is kept with the release, whatever its age.	kept for as long as the organisation exists	365 to 3650 days	the daily SBOM prune
`export_bundle`	How long a data export stays offered for download. The file itself is deleted after 7 days.	7 days	1 to 7 days	the nightly retention reaper; the file by the storage rule

Why these bounds. The two classes that hold personal data, the audit payload and the access log (actor, IP address), stop at 730 days, the longest period the Privacy notice §6 and the DPA Annex A.7 state for security audit events. Export downloads stop at the 7 days §6 states for exports. The other classes hold no personal data beyond what an audit event already records and run to 10 years, the retention the EU Cyber Resilience Act sets for technical documentation.

The export file itself is deleted 7 days after it was made, in eu-de and in its eu-nl disaster-recovery copy (since 2026-10-08; it was 90 days, and 13 months for the DR copy). export_bundle can withdraw the download sooner. Under a legal hold the file is kept in both regions, and once the hold is released it is deleted 7 days after it was made. The export’s record (what was exported, when, by whom, its manifest) is kept under a legal hold too.

Legal hold

While your organisation is under a legal hold, deletion of every class is suspended: the audit payload is not redacted, access log rows, resolved findings, SBOMs, attestations and export records are not deleted, and pull-request findings are not cleared when the pull request closes. Your settings are kept and apply again the night after the hold is released. The console page and the API both say when a hold is active.

API

# read
curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  https://frem.sh/_app/api/v1/orgs/acme/evidence-retention

# set two classes, reset one to its default
curl -X PATCH -H "Authorization: Bearer ${FREMFORGE_PAT}" -H 'Content-Type: application/json' \
  -d '{"access_log_days": 180, "findings_history_days": 1095, "attestation_days": null}' \
  https://frem.sh/_app/api/v1/orgs/acme/evidence-retention

Reading needs policy:read, changing needs policy:write. The fields are audit_payload_days, access_log_days, findings_history_days, sbom_non_release_days, attestation_days and export_bundle_days; null resets a class to its default, and a value outside the bounds is refused with 400. The answer lists each class with configured_days (what you set, or null), effective_days (what the job applies now; null means kept for as long as the organisation exists), default_days, min_days, max_days and whether it holds personal data, plus legal_hold.active.

Every change is in the audit log as tenant.evidence_retention.updated, with each changed class’s value before and after. The data export carries the same list in policy/settings/retention.ndjson.

The older audit retention setting under Authentication policy → Audit log retention and the SBOM setting on the SBOM page are the same values as audit_payload and sbom here; either place changes them.

What retention does not cover

The 3-year tamper-evident audit chain archive (WORM), which no setting shortens. See Audit log retention.
Backups, which expire on their own schedule (DPA §9).
What happens after your organisation is cancelled: that follows the lifecycle.

Access log Pulled versions