Danijel Martinek
879b0215c3
Adds docs/compliance/ as the canonical onboarding reference for the compliance module, covering every field in each generated YAML artifact with inline annotations and explaining the docs/compliance/ (examples) vs compliance/ (live artifacts) split. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
60 lines
3.1 KiB
YAML
60 lines
3.1 KiB
YAML
# docs/compliance/retention-policy.example.yml — annotated reference for the retention-policy schema
|
|
#
|
|
# This file is NOT generated. It shows every possible field that can appear in
|
|
# compliance/retention-policy.yml and explains what each field means.
|
|
#
|
|
# Generated artifact : compliance/retention-policy.yml
|
|
# Generator : pnpm compliance:retention-policy
|
|
# Source of truth : packages/*/src/integrations/cms/collections/*.ts
|
|
# (custom.retention block inside each collection config)
|
|
# PII types : packages/core-shared/src/payload/pii-types.ts
|
|
|
|
collections:
|
|
# ── Collection with all optional retention fields populated ───────────────────
|
|
# This represents a user-identity collection with the strictest schedule.
|
|
profiles:
|
|
slug: profiles # matches the Payload collection slug; used as the map key
|
|
purgeSchedule:
|
|
daily # Required. Cadence for the background purge job.
|
|
# Allowed values: "daily" | "weekly" | "monthly"
|
|
# Set via custom.retention.purgeSchedule in the collection config.
|
|
|
|
# Optional. How long to keep an active record before it enters the delete flow.
|
|
# Omit if records should live indefinitely until a user-deletion request is received.
|
|
activeRetention:
|
|
duration: P2Y # ISO 8601 duration (P2Y = 2 years, P1Y = 1 year, P6M = 6 months, P90D = 90 days)
|
|
trigger:
|
|
from-last-access # RetentionTrigger: when the clock starts
|
|
# "from-creation" — counted from record creation date
|
|
# "from-last-access" — resets on every authenticated session
|
|
|
|
# Optional. Long-term cold-storage window before final purge.
|
|
# Use when regulatory obligations require records to survive deletion requests for a fixed term
|
|
# (e.g. financial records under EU accounting law, seven-year AML retention).
|
|
coldArchive:
|
|
duration: P7Y
|
|
trigger: from-creation # Usually from-creation for regulatory fixed-term obligations
|
|
|
|
# Required. What happens after a user submits a deletion request (DSR erasure / account closure).
|
|
postDeletion:
|
|
action:
|
|
pseudonymize # RetentionAction: "hard-delete" | "pseudonymize"
|
|
# hard-delete — row is permanently removed at the end of the grace period
|
|
# pseudonymize — PII columns are replaced with opaque tokens; row is kept
|
|
# (use when the record must survive for aggregate analytics)
|
|
duration: P30D # Grace period before the action executes (ISO 8601 duration)
|
|
trigger: after-deletion # Fixed value — clock starts when the deletion request is accepted
|
|
|
|
# ── Collection with only the required minimum fields ─────────────────────────
|
|
# Most content collections (articles, pages, media) use this minimal form.
|
|
articles:
|
|
slug: articles
|
|
purgeSchedule: monthly # Low-sensitivity content; monthly sweep is sufficient
|
|
|
|
# postDeletion is required even for non-PII collections.
|
|
# For content without PII, hard-delete with a short grace period is the default.
|
|
postDeletion:
|
|
action: hard-delete
|
|
duration: P90D
|
|
trigger: after-deletion
|