Skip to content

Data retention policy

Last updated: 2026-05-03

This policy explains how long Secruna retains each category of data we hold on your behalf, and the legal basis for those retention periods. It applies to data processed by the Secruna control plane (api.secruna.com) and the data plane connectors described under connectors/.

Summary table

Category Default retention Trigger that starts the clock Legal / operational basis
Audit log entries (audit_log_entries) 7 years Event timestamp EU AI Act Article 12 (logging obligation for high-risk systems); GDPR Article 30 (records of processing)
System artefacts (system_artifacts) 90 days post-disconnect of the source connection Connection move to disconnected status Operational — once a connector is gone, the artefact is no longer evidence
Discovery runs (discovery_runs) 90 days Run completion timestamp Operational — long enough for SLO measurement, short enough to keep PII surface small
Verdicts (verdicts) 7 years Verdict creation Co-resident with audit log; verdicts are evidence of compliance decisions
Session data (Redis) 24 hours Last activity (sliding) SESSION_TTL_SECONDS = 86400 per code; matches expected daily-use pattern
Impersonation requests (impersonation_requests) 7 years Request creation Audit-significant: every platform-admin-as-tenant-admin event must be reviewable
Personal data (user accounts, tenant memberships) Lifetime of tenant + 30 days Tenant closure Operational grace; allows recovery after accidental closure
Email notifications (Resend logs) 30 days Send time Resend's default; we don't extend this
Sentry error events 90 days Event time Sentry free tier default
Better Stack uptime data 30 days detail / 12 months aggregated Probe time Better Stack free tier defaults
Container Apps runtime logs (Log Analytics) 30 days Log time Log Analytics workspace default; we have not extended
Azure PostgreSQL backups (PITR) 7 days Backup time Azure managed service default for Flexible Server

Per-category notes

Audit log entries — 7 years

The audit log captures every action that changes tenant state: verdict approvals, artefact deletions, connection adds, role changes, impersonation events, exports. Each entry includes actor, action verb, target, request id, IP address, and a JSON context blob.

Why 7 years. EU AI Act Article 12 requires high-risk AI system providers to retain automatically generated logs for the duration of the system's lifetime, and at least 6 months — but because Secruna is the audit substrate for our customers' high-risk AI systems, we adopt the longer 7-year window aligned with banking record-keeping (Polish Act on Accounting Article 74, analogous Czech and German rules).

What this looks like in practice. Audit log rows accumulate indefinitely through year 7. After year 7, a monthly cron purges rows whose created_at < now() - interval '7 years'.

Status note: the cron purge is on the roadmap; today no automated purge runs, which means we currently retain more than 7 years (since the platform is younger than that). The eventual purge is a planned change, not a regression. Documented here so the law firm sees it.

System artefacts — 90 days post-disconnect

A system artefact is the JSON blob describing one AI system we discovered (e.g., one Bedrock model, one Vertex endpoint, one Copilot seat). While the source connection is active, the artefact is refreshed on every discovery run.

When the connection moves to disconnected, every artefact sourced from it enters a 90-day grace window. After 90 days, the artefact is hard-deleted from Postgres.

Why 90 days. Two reasons: 1. Customers occasionally re-enable a connection that was disabled by accident; 90 days is enough breathing room. 2. The matched verdict references the artefact ID; immediate deletion would dangle the verdict's evidence pointer. After 90 days the verdict still exists (it's audit-relevant) but the artefact reference becomes a tombstone.

Discovery runs — 90 days

discovery_runs rows are the per-run history (start/end time, status, error counts, error JSON). Useful for diagnosing flaky connectors and computing the SLO defined in docs/ops/slos.md. After 90 days the rolled-up error_rate_7d and runs_7d aggregates have no use, so we purge.

Session data — 24 hours

Sessions live in Redis. The TTL is set by SESSION_TTL_SECONDS (default 86400). On every authenticated request the TTL is not slid (we issue a fixed-TTL session); a user inactive for 24h must reauthenticate. This is intentional — it caps the blast radius of a stolen cookie.

Impersonation requests — 7 years

When a platform admin needs to act inside a tenant for support (troubleshooting, incident response), they file an ImpersonationRequest, which is approved by a second admin under the 2-eyes rule. Every approved request and every action taken under impersonation is audit-logged. Because these events authorise a Secruna employee to view tenant data, they sit in the same 7-year retention bucket as the audit log itself.

Personal data of users — tenant lifetime + 30 days

User accounts (email, display name, Entra ID object ID) and tenant memberships persist while the tenant is active. When a tenant is closed, accounts that were attached only to that tenant enter a 30-day grace window. After 30 days:

  • The user account is anonymised in audit_log_entries (we replace the actor's email with deleted-user-<uuid-hash> and drop their display name).
  • The tenant membership row is deleted.
  • The Microsoft Entra ID linkage is dropped.

If the user is still active in another tenant, the account is retained for that tenant.

Right of erasure (GDPR Article 17)

Any data subject (an end-user of your AI systems whose data might appear in our audit logs — uncommon but possible if you ingest user identifiers via the audit context) may request erasure through their employer (the controller). Upon receipt of a verified request from the controller, we will:

  1. Identify all audit log rows referencing the data subject.
  2. Pseudonymise (preferred) or, where pseudonymisation is impossible without breaking referential integrity, delete the rows.
  3. Confirm completion within 30 calendar days.

We do not honour erasure requests that come directly from a data subject without controller verification, because we cannot verify the relationship between the requester and the controller without your cooperation. This is consistent with GDPR Article 12(6).

Backups

Azure PostgreSQL Flexible Server retains point-in-time backups for 7 days by default. We have not extended this. Restoring from PITR is a manual operation documented in docs/ops/incident-response.md §4.2.

Implication for retention: if you delete data and then ask us to restore from a backup more than 7 days old, that data is unrecoverable. We document this so you can size your own backup policy if you need longer recovery horizons.

We do not copy the database to long-term cold storage. Any expansion of the backup horizon would be visible on this page and on subprocessors.

How we destroy data

When a retention window expires, the destruction method depends on storage tier:

  • Postgres rows. Hard DELETE with VACUUM afterwards; no soft delete, no recoverable tombstone.
  • Azure Key Vault secrets (connector credentials). On disconnect we issue DELETE against Key Vault; the soft-delete retention on our vault is 7 days by default after which the secret is unrecoverable.
  • Redis sessions. TTL-driven eviction; Redis does not persist sessions to disk in our deployment.
  • Log Analytics entries. Retention is 30 days at the workspace level; entries roll off automatically.

Cross-references

TODO: review by counsel before sending to any customer.