51 lines
2.7 KiB
Markdown
51 lines
2.7 KiB
Markdown
|
# Tenant registry retention and deletion policy
|
||
|
|
|
||
|
|
Status: implemented policy for the current data model; reviewed 2026-08-18.
|
||
|
|
|
||
|
|
This policy is the authoritative `deletionPolicyRef` for tenant-engine. It
|
||
|
|
separates business-record retention from PostgreSQL backup retention; a backup
|
||
|
|
window never silently decides when an authoritative tenant fact may be erased.
|
||
|
|
|
||
|
|
## Primary records
|
||
|
|
|
||
|
|
Tenant records are canonical registry facts. `retire` is reversible and is not
|
||
|
|
deletion. Tenants, plan assignments, grant/revocation history, domain events
|
||
|
|
and guardrail changes are retained without an automatic expiry while the
|
||
|
|
registry remains authoritative. There is deliberately no hard-delete API.
|
||
|
|
|
||
|
|
Contact email and display name are the only mutable person-attributable fields.
|
||
|
|
An authorized erasure request is an attended maintenance change: remove or
|
||
|
|
replace those fields while preserving the tenant id, identifier, lifecycle,
|
||
|
|
version and audit trail needed to explain prior authorization decisions. Until
|
||
|
|
that operator procedure has run, tenant-engine makes no claim that retirement
|
||
|
|
erases personal data.
|
||
|
|
|
||
|
|
Idempotency receipts currently have no automated primary-store expiry. They
|
||
|
|
therefore share the indefinite primary retention above. Introducing an expiry
|
||
|
|
requires a forward-only migration plus proof that the maximum client retry
|
||
|
|
window is shorter; it must not be inferred from the backup window.
|
||
|
|
|
||
|
|
## Copies outside the primary database
|
||
|
|
|
||
|
|
- `platform-pg` physical backups and WAL have a 30-day retention window shared
|
||
|
|
across all databases on the cluster. After a primary-row redaction or future
|
||
|
|
deletion, physical copies can remain recoverable for at most that declared
|
||
|
|
window, subject to a successful and verified backup-policy deployment.
|
||
|
|
- The per-consumer encrypted logical export is retained for 30 days. Its
|
||
|
|
declaration is `rapp-postgres/consumers/tenant-engine.yaml`.
|
||
|
|
- Scratch restores are operator-created evidence environments and must follow
|
||
|
|
the platform scratch-restore policy; they are not production read replicas.
|
||
|
|
- The stopped SQLite PVC retained during cutover is a rollback copy. It must be
|
||
|
|
access-restricted, named in the cutover record, and destroyed only after the
|
||
|
|
PostgreSQL soak and rollback decision. It is not a second live source of
|
||
|
|
truth.
|
||
|
|
|
||
|
|
## Assurance position
|
||
|
|
|
||
|
|
Publishing this policy does not raise tenant-engine above R0 by itself. The
|
||
|
|
service has policy-driven backup-copy windows, but no automated primary-row
|
||
|
|
expiry or verified personal-field erasure workflow. `tenancy.yaml` therefore
|
||
|
|
keeps current R0 and target R2. A customer-facing “deleted data is gone” claim
|
||
|
|
is prohibited; any future claim must disclose the effective erasure horizon
|
||
|
|
and be backed by dated deletion plus backup-expiry evidence.
|