Article 30(1) lists what a controller's record has to contain. Here's each field, what belongs in it, and the way each one usually gets filled in wrongly.
Article 30(1) is a list. That is the useful thing about it: unlike most of the regulation, it tells you exactly what to write down. The difficulty is not knowing the fields, it is filling them in at a level of detail that survives being read by someone who was not in the room.
The ICO publishes a template that follows the article's structure. What follows is each field with the failure mode attached.
The fields
| Field | Article | How it goes wrong |
|---|---|---|
| Name and contact details of the controller, any joint controller, representative and DPO | 30(1)(a) | Left as a job title after the person leaves. This is the field a regulator uses to contact you. |
| Purposes of the processing | 30(1)(b) | Written so broadly that necessity cannot be tested against it. "Business operations" is not a purpose. |
| Categories of data subjects and categories of personal data | 30(1)(c) | Describes the fields the system was designed to hold, not what has accumulated in it. |
| Categories of recipients, including those in third countries or international organisations | 30(1)(d) | Names the contracted processor and stops. Sub-processors and internal onward sharing get missed. |
| Transfers to a third country or international organisation, and the safeguards | 30(1)(e) | Left blank because the transfer is invisible: a SaaS tool with support staff outside the UK still transfers. |
| Envisaged time limits for erasure of the different categories | 30(1)(f) | States a policy period that nothing enforces. See the retention post for what to write instead. |
| General description of technical and organisational security measures | 30(1)(g) | Describes the measures on the primary system and ignores the copies elsewhere. |
The three fields that carry the most weight
Purposes, because everything else is scoped to them
The purpose determines the lawful basis, the necessity test, the retention period, and whether a DPIA is needed. Write it specifically enough that someone could disagree with it. "Processing job applications to assess suitability for advertised roles" can be tested. "Recruitment" cannot.
Categories of personal data, because this is where drift shows
This field is usually completed from the system specification. The specification says name, email and phone. Two years later the same folder holds scanned passports, bank details from an expenses process, and a sickness note somebody attached to an email.
Article 30 asks what categories you process, not what categories you intended to process. The honest version of this field is written from observation.
Security measures, because it is scoped to the data not the system
A general description is all Article 30(1)(g) asks for, so this field does not need to be long. It does need to be true of all the places the data in this record actually sits, which is a different question from what protects the main system.
One record per processing purpose, not one per system. A single CRM can appear in three records with three different purposes, bases and retention periods. Merging them into one row loses the distinctions the record exists to hold.
Making it maintainable
A record that takes a week to build and is never touched again is worse than a shorter one that gets reviewed. Two habits keep it alive:
- Give each record a named owner in the business, not in legal. The person who runs the process knows when it changes.
- Attach a review date and treat a passed review date as a finding, the same way you would treat an overdue patch.
How EmberHound fits
Two fields in that table decay faster than the rest: categories of personal data, and the locations implied by the security measures field. Both are claims about reality that get written once from a design document.
EmberHound scans enrolled company devices and reports personal data by category and location, so those fields can be written from evidence and re-checked on a schedule. The ROPA capability is available inside the GDPR plans, and a standalone ROPA Workspace is in early access.
This article is general information, not legal advice. Confirm the obligations that apply to your organisation before acting on it.
Sources & references
- Article 30 - Records of processing activities, UK GDPR - legislation.gov.uk
- Documentation - ICO
