A GDPR Article 30 record of processing lists the purposes, data categories, recipients, transfers, retention periods and security measures for each processing activity. Most answers already exist in code, infrastructure config and vendor settings, so engineers can fill the technical fields faster than legal can.
The fields and where they live
Article 30(1) asks a controller to record the following. Here is where to look for each.
- Controller and contact details. Legal and the privacy notice. Not an engineering field.
- Purposes of processing. Product specs and the reason a field was added. If nobody can say why a field exists, that is a finding.
- Categories of data subjects and personal data. Database schemas, API specs and event definitions.
- Recipients, including in other countries. Outbound integrations, SDK configuration and data warehouse sharing settings.
- Transfers outside the EU. Cloud region settings, vendor data location pages and CDN configuration.
- Planned erasure deadlines, where feasible. TTL settings, deletion jobs and the retention schedule.
- Security measures, where feasible. Encryption settings, access control config, logging and backup policy.
Who needs one
The text says the duty does not apply to organisations with fewer than 250 people, unless the processing is likely to risk people's rights, is not occasional, includes special categories, or covers criminal convictions data. In practice, regular processing of customer data is not occasional, so many small companies end up needing a record anyway. Confirm with counsel for your case.
Make it one record per activity, not per system
A common mistake is a row per database. Auditors and regulators think in activities: "billing customers", "sending product emails", "fraud checks". Group systems under activities. One activity may touch five systems, and one system may serve three activities.
Generate what you can
Technical fields drift. Retention periods, regions and recipients change with a config edit, so a hand written record is stale within weeks. Pull what you can from source:
- Region and encryption settings from infrastructure as code.
- Recipients from the dependency and integration list.
- Retention from the deletion job configuration.
Review the generated rows each quarter and have the activity owner sign off.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one piece of evidence can map to several framework requirements, which is the same idea as one inventory feeding several privacy records.
Quick check
Is the record a public document?
No. Article 30 says it must be made available to the supervisory authority on request, not published.
Do processors keep one too?
Article 30 sets a separate, shorter record for processors acting on behalf of a controller. Check the text for the exact fields.
Sources
Last reviewed: 19 October 2026.
