Skip to content

Data Retention

Statement

ClaimGuard retains data only for as long as it serves a documented purpose: operating the application, supporting customers, satisfying audit requirements, or meeting legal obligations. Different data classes have different retention rules — some are governed by infrastructure policies (cloud audit logs, disk snapshots), others by application defaults that customer agreements may override.

The retention story today is partial: infrastructure-side retention is in place and verifiable; application-side retention is mostly "until manually deleted," which is fine at current scale but needs a written policy per data class before SOC 2 fieldwork.

Implementation

Retention by data class

Data class Retention Mechanism
Cloud audit logs (_Required bucket) 400 days, immutable GCP _Required bucket with locked: true. See Audit logging (cloud).
Cloud operational logs (_Default bucket) 30 days GCP default.
VM boot disk snapshots (claim-guard-daily) 7 days Snapshot resource policy. See Backups.
Application user accounts Until disabled or deleted is_active = false is the soft-delete state; rows persist.
Claims and evidence rows Until manually deleted Application has no automatic claim aging or archive flow today.
Uploaded files in GCS Until manually deleted No lifecycle policy on the buckets today.
Review notes Until claim is deleted Cascaded with parent claim.
review_notes-driven analyst history Until manually deleted Same as above.
API keys Until revoked No automatic expiry today.
JWTs Until exp (default 24h) Stateless; not persisted server-side.
pm2 application logs (stdout) pm2 default rotation (~10MB × 10 files) Local to the VM; not aggregated.
.snyk deferral entries 1 year, then renewal expires: field per entry. See SCA.

Retention defaults vs customer overrides

Today every customer-facing retention default in the table above is the same across the fleet. Customer-specific retention requirements (e.g., "delete all our claims older than 18 months") are not yet supported by configuration — they would require a code change. This is a known limitation, not a deliberate policy.

Deletion mechanics

  • Soft delete is the default for users (is_active = false) and is reversible.
  • Hard delete of a user / claim / evidence is supported via the appropriate DELETE route. This is destructive and is not reversible at the application layer; recovery would require a disk snapshot restore (see Backups).
  • GCS object deletion is immediate; uploaded buckets do not have retention locks today.

What's not in place

  • No automatic data aging. Old claims, evidence, audit-trail rows, and uploaded files persist indefinitely until a human runs a delete.
  • No customer-facing retention configuration. Per-org policies ("delete claims older than N days") would require a feature.
  • No structured audit_log table (see Application audit logging), so no retention policy on it either.
  • No retention enforcement on uploaded GCS objects (no GCS lifecycle rule today).

Status

partial — verified 2026-04-29.

What's in place:

  • Infrastructure-side retention is documented and enforced for cloud audit logs (400d, immutable) and disk snapshots (7d).
  • Per-data-class retention is enumerated (this page is the first written record of those defaults).
  • .snyk deferrals carry an expires: field that forces annual re-review.

Known gaps

  • No written customer-facing retention policy distinct from this page. Before SOC 2 fieldwork, this page (or a successor) needs to graduate from "current state of the world" to "policy with a named owner and a review cadence."
  • No data aging / archival for claims, evidence, or uploaded files at the application layer.
  • No GCS bucket lifecycle policy — uploaded files persist until a caller runs a delete.
  • No customer-configurable retention per org.
  • Structured audit_log retention is unwritten because the table itself doesn't exist yet (cross-listed on Application audit logging).

Roadmap

  • GCS lifecycle policies on the upload buckets — start with delete-after-N-days for unreferenced objects.
  • Per-org retention configuration (a single retention_days field on organizations, defaulting to "no expiry").
  • audit_log table retention documented to match the cloud audit log default (400 days) once the table ships.
  • Written policy ownership — a single named owner and a quarterly review of this page.