Data processing records: Implementation and evidence

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 none automatically.
• 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.yaml are an adoption profile, not universal defaults.
• The adopting team must map actors, data classes, error vocabulary, and ownership to its system.

References

• gdpr