Defines a versioned processing-activity inventory connected to real systems, data flows, purposes, recipients, retention, controls, and change evidence so records do not decay into isolated questionnaires.
Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.
Decision
Maintain one governed processing-activity record per coherent purpose and system flow, linked to service ownership and deployable inventories. Changes to data categories, purposes, recipients, regions, or retention create reviewable versions.
Scope
- Activity identity, roles, purposes, subjects, data categories, systems, sources, recipients, transfers, retention, security controls, legal basis references, risks, ownership, and review evidence.
- Technical generation and reconciliation of processing records.
- Regional/legal fields as configurable expert-reviewed data.
Outside this block
- Automating legal conclusions from source code.
- Combining unrelated purposes merely because they share one database.
Contract
- Each activity has a stable ID, version, owner, status, applicable regions, purpose, and links to systems and data-flow evidence.
- Data subject/category, source, destination/recipient, location, and retention are explicit rather than hidden in prose.
- Legal basis and transfer mechanism fields reference reviewed records; engineering automation cannot invent them.
- Automated evidence reports drift such as unregistered event fields, recipients, stores, or retention jobs.
- Historical versions remain available with effective and review dates.
- Access is restricted because the inventory can reveal sensitive architecture and vendor relationships.
Implementation guidance
- Ingest candidates from data catalogs, event schemas, infrastructure, vendor registers, and retention configurations, then require owner review.
- Use stable identifiers so one system or recipient can be referenced across activities.
- Attach evidence digests and source timestamps instead of copying entire secret configurations.
- Create change triggers in architecture and privacy review workflows.
Failure handling and safeguards
- Missing evidence marks a field unknown or stale; it never becomes
noneautomatically. - Conflicting inventories create a review task and preserve both observations.
- If an owner leaves, ownership transfer is a governed record change rather than silent orphaning.
Verification and operations
- Measure unowned/stale activities, drift findings, evidence age, unresolved recipients, retention mismatch, and review completion.
- Reconcile at release for material data-flow changes and on a scheduled basis.
- Have privacy/legal specialists approve conclusions and jurisdictional fields.
The executable-looking examples in this package are fixtures and acceptance contracts. Run
python tools/validate.py from the collection root to check package structure and metadata; then
implement and execute the scenarios in the target repository.
Adoption assumptions
- Names and numeric values in
example.yamlare an adoption profile, not universal defaults. - The adopting team must map actors, data classes, error vocabulary, and ownership to its system.