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 controls are operating today: infrastructure-side retention is enforced and verifiable; application-side retention defaults are documented in the per-class table below. A written customer-facing retention policy as a standalone artifact is a SOC 2-fieldwork deliverable.

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 the active-account flag 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.
the deferral policy file 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 (the active-account flag) 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 the planned 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

implemented — verified 2026-05-06. Per-data-class retention is documented and enforced for the infrastructure layer (cloud audit logs 400d immutable, disk snapshots 7d) and documented for the application layer. Known gaps below are policy-formalization items for SOC 2 fieldwork.

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).
  • the deferral policy file 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 the audit-log table 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").
  • the planned 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.