Files
agentic-dev-template/docs/compliance/data-map.example.yml
Danijel Martinek 879b0215c3 docs(compliance): add docs/compliance reference examples and README
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>
2026-05-18 20:22:01 +00:00

80 lines
4.1 KiB
YAML

# docs/compliance/data-map.example.yml — annotated reference for the data-map schema
#
# This file is NOT generated. It shows every possible field that can appear in
# compliance/data-map.yml and explains what each field means.
#
# Generated artifact : compliance/data-map.yml
# Generator : pnpm compliance:data-map
# Source of truth : packages/*/src/integrations/cms/collections/*.ts
# (custom.pii field tags + auth: true defaults)
# PII types : packages/core-shared/src/payload/pii-types.ts
collections:
# ── Non-auth collection with manually tagged PII fields ───────────────────────
profiles:
auth: false # true only for Payload auth-enabled collections (auth: true in collection config)
slug: profiles # matches the Payload collection slug; used as the map key
piiFields: # empty array ([]) when no PII fields are declared on the collection
# ── Minimal field tag (no retention override) ─────────────────────────────
- category:
identification-name # PiiCategory — see packages/core-shared/src/payload/pii-types.ts
# e.g. contact-email | identification-username | network-ip | …
exportable: true # GDPR Art. 15 — include in data-export responses
field: fullName # The Payload field name as declared in the collection
purpose: # DataProcessingPurpose[] — why we collect and process this value
- service-delivery # e.g. account-authentication | transactional-notifications |
# marketing-communications | analytics-aggregation |
# legal-compliance | service-delivery
restrictable: true # User can request restriction of processing under GDPR Art. 18
source: field-tag # Origin: "field-tag" — custom.pii tag on the collection field
# ── Field tag with a per-field retention override ─────────────────────────
# Use when a field needs a stricter retention window than the collection default.
- category: network-ip
exportable: false
field: lastIpAddress
purpose:
- legal-compliance
restrictable: false
retention: # Optional. Per-field retention window (overrides collection schedule).
action: hard-delete # RetentionAction: "hard-delete" | "pseudonymize"
duration: P6M # ISO 8601 duration (P6M = 6 months, P1Y = 1 year, P90D = 90 days)
trigger: from-last-access # RetentionTrigger: "from-creation" | "from-last-access" | "after-deletion"
source: field-tag
# ── Auth-enabled collection: defaults + overrides ─────────────────────────────
# When a collection sets auth: true, PAYLOAD_AUTH_PII_DEFAULTS are applied
# automatically. Each default can be overridden via custom.authPii in the
# collection config without adding custom.pii to every field individually.
members:
auth: true # Activates PAYLOAD_AUTH_PII_DEFAULTS (email injected, password/salt/hash excluded)
slug: members
piiFields:
# Injected automatically because auth: true — no field tag needed on the collection
- category: contact-email
exportable: true
field: email
purpose:
- account-authentication
- transactional-notifications
restrictable: true
source: auth-default # From PAYLOAD_AUTH_PII_DEFAULTS; not declared in collection fields
# The collection supplied custom.authPii.phone to extend or change the auth defaults
- category: contact-phone
exportable: true
field: phone
purpose:
- transactional-notifications
restrictable: true
source: auth-override # Collection explicitly overrode or extended the auth default
# Regular custom.pii tag on a field inside an auth collection
- category: identification-username
exportable: true
field: username
purpose:
- service-delivery
restrictable: true
source: field-tag