The field list for a record of processing activities is short and public. Article 30 of the General Data Protection Regulation (GDPR) sets out what each record must contain, and any competent template reproduces it. Yet first attempts at a register routinely stall, and the reason is almost never the fields.
Building a register is a discovery problem wearing a documentation problem's clothes. The hard parts are finding the processing nobody wrote down, deciding what counts as one activity, and getting information out of people who do not think of their work as "processing personal data". This article is about that work. What each field must contain is covered separately in what Article 30 actually requires.
Start from the business, not from the systems
The instinct is to open the software inventory and write one record per tool. It produces a register quickly and a bad one, because a tool is not a purpose. Your helpdesk platform might carry customer support, recruitment correspondence, and an internal whistleblowing channel. One record covering "helpdesk" describes none of them: the data subjects differ, the retention differs, the legal basis differs, and the recipients differ.
Work from activities instead. An activity is something the organisation does that involves personal data, described the way the people doing it would describe it: paying staff, running a recruitment pipeline, handling support requests, sending a customer newsletter, screening suppliers. Systems then attach to activities, which is the direction the Article 30(1) field list expects — purposes first, then the data, then the recipients.
This also determines who can answer your questions. Nobody owns "the helpdesk platform" in a way that lets them explain retention for recruitment correspondence. The recruiting lead owns that.
Deciding what counts as one activity
This is the decision that shapes the whole register, and there is no rule in the Regulation to settle it. Too coarse and the record becomes unfalsifiable; too fine and you have four hundred records nobody maintains.
The workable test is whether the Article 30 fields would differ. Split an activity when any of these changes:
- the purpose, stated in a way a reviewer could judge as proportionate or not;
- the categories of data subjects;
- the legal basis relied on;
- the retention period or the criteria that set it;
- the recipients, including whether the data leaves the European Economic Area.
If none of those differ, you are describing one activity even when several teams or tools are involved. If any of them differ, one record will have to hedge, and hedged records are the ones that fall apart under questioning.
Two patterns are worth naming. Do not create a record per system, for the reason above. And do not create a record per department, because departments do several unrelated things and reorganise, which orphans the register. Records that follow purposes survive reorganisations; records that follow org charts do not.
For a small or mid-sized company, a complete first register usually lands somewhere in the low tens of records. If your draft has three, it is too coarse. If it has two hundred, you have split on tooling rather than on the fields.
Finding the processing nobody wrote down
Interviews surface the activities people think of as their job. They reliably miss the rest. These sources surface the rest, and they are all things you already have:
- Payroll and HR systems. Employee data is the processing most often left out of a first register, because it feels like administration rather than data processing.
- The identity provider's application list. Every application anyone has signed into with a work account, including the ones procurement never saw.
- Vendor spend. Card statements and the accounts payable ledger surface tools bought on expense, which is where unreviewed processing concentrates.
- The website itself. Analytics, advertising pixels, chat widgets, embedded video, and form handlers are all processing, and they are usually configured by whoever built the page.
- Existing Data Processing Agreements. A signed DPA is an admission that personal data flows somewhere. If you hold one for a tool that appears in no record, you have found a gap.
- Shared drives and inboxes. A shared recruitment mailbox or a spreadsheet of leads is processing with no system of record behind it, and it will not appear in any inventory.
Run these before the interviews, not after. Arriving with a list of things you already know exist changes the conversation from "can you think of anything" to "tell me about this", which is a far more productive question.
The interview that works
Twenty to thirty minutes per activity owner is enough if you do not use the vocabulary of the Regulation. Asking someone for the categories of data subjects and the legal basis produces confusion or, worse, confident guesses. Ask about the work instead:
- Walk me through what you do, from the point where information about a person arrives.
- Where does it arrive from, and what do you get?
- What do you do with it, and what do you produce?
- Who else sees it, inside and outside the company?
- What tools are involved, including spreadsheets and shared inboxes?
- How long do you keep it, and what happens at the end?
- Has any of this changed in the last year?
Translate the answers into Article 30 fields yourself. That is your job, not theirs, and the translation is where you catch the mismatch between what a policy says and what actually happens. Where an answer conflicts with a documented process, record what the person told you and flag the conflict, because the register's value depends on describing reality rather than intention.
The last question is the most useful and the most often skipped. It tells you which records will need a shorter review cycle.
Sequencing a first register
Trying to complete every record before finishing any produces a register that is uniformly half-done and cannot be used. Sequence it instead.
Pass one: name the activities. No fields yet, just a list with an owner against each. Aim to be complete here even if nothing else is. A named activity with an owner is already useful; it can be assigned, questioned, and prioritised.
Pass two: fill the fields for the highest-exposure activities first. Anything involving special categories under Article 9, children's data, large volumes, or transfers outside the EEA. These are the records most likely to be asked about and the most likely to reveal problems that need time to fix.
Pass three: fill the remainder, accepting shorter entries for low-risk activities. A three-line record for an internal room-booking tool is proportionate. Article 30 qualifies both the retention and the security fields with "where possible", which is room the Regulation gives you deliberately.
Pass four: review the whole thing as a set. Reading twenty records together surfaces inconsistencies invisible one at a time: the same vendor described three ways, two records that are really one activity, retention periods that contradict each other.
Where the first version is always wrong
Expect three specific errors, because nearly every first register has them.
Purposes written as departments. "Marketing" is not a purpose. "Sending a monthly product newsletter to subscribers" is. The test is whether a reader could disagree with you about proportionality; if not, the purpose is too vague to be one.
Retention stated as an aspiration. "As long as necessary" repeats the Regulation back at itself. Where a fixed period genuinely depends on external factors, record the criteria instead, which is what the field asks for.
Recipients listed as your direct vendors only. The processors your processors use are recipients too, and they determine which countries appear in your third-country transfer field. This is the gap that makes a register drift after it is finished, since those lists change without you. Which vendor changes force an update is covered in keeping RoPA records accurate, and building the underlying picture is covered in vendor subprocessor inventory.
Keeping it alive after the first pass
A finished register starts decaying immediately, in two different ways, and they need different mechanisms.
Your own changes need interval review with named owners. Set a next-review date per record, weighted by exposure, and route it to the activity owner rather than to the privacy team. An unowned record is one nobody updates.
Your vendors' changes need event-driven review, because they happen on someone else's schedule. When a processor adds a subprocessor or moves a workload, your recipients and transfers fields become inaccurate that day. Interval review will find it eventually, which means the register was wrong for some unknown fraction of the interval.
The distinction matters more than the cadence. A quarterly cycle with event triggers beats a monthly cycle without them, because the monthly cycle is still discovering vendor changes by accident.
Common mistakes
- One record per tool. Fast to produce, and it describes purposes badly enough to be unusable.
- Waiting for completeness before publishing anything. A named list of activities with owners is more useful in week one than a perfect quarter of the register in month three.
- Using Regulation vocabulary in interviews. It produces guesses that read as facts once they are written down.
- Skipping the processor record. If you process on behalf of customers, Article 30(2) is a separate obligation with its own shorter field list.
- Assuming small organisations are exempt. Article 30(5) excludes occasional processing, not small organisations, and the Article 29 Working Party position paper confirms the narrow reading. Payroll and customer records are not occasional.
- Treating the register as a deliverable. It is a maintained artefact. A register with no owners and no review dates is a snapshot that will be quietly wrong within a quarter.
Frequently asked questions
How long does a first register take?
For a company with a few dozen employees and a normal software estate, a focused effort over two to four weeks usually produces a defensible first version: a few days on discovery, a week of interviews, and the rest on writing and review. It takes longer when the discovery step is skipped, because activities surface late and the whole structure gets revised.
Who should own the work?
One person should own the register and drive it; individual activity owners should own their own records. A data protection officer, where one is designated, monitors compliance under Article 39 rather than maintaining every entry personally. The failure mode is a privacy team that owns all the records, because it cannot know when the business changes something.
Do we need a separate register for each legal entity?
The obligation sits with each controller, so a group with several controllers technically owes several records. Most groups keep one register with the controller identified per activity, which satisfies Article 30(1)(a) and avoids maintaining parallel documents that drift apart. What matters is that any given record makes clear which entity is the controller.
Should the register include processing we plan but have not started?
Article 30(1)(d) refers to recipients to whom data "have been or will be disclosed", so forward-looking entries are contemplated. In practice, drafting a record while a project is being designed is the cheapest time to notice a problem, and it makes the go-live an update rather than a discovery.
Is the register the same as a data flow diagram?
No, and neither replaces the other. A diagram traces data through systems and is useful for security and architecture conversations. A register documents activities against the Article 30 fields and is what Article 30(4) obliges you to produce for a supervisory authority.
Where DPAFlow fits in
DPAFlow does not provide legal advice and does not decide what your records should say. It holds them and keeps the vendor half current.
The RoPA builder stores each activity with its purposes, data categories, data subjects, retention, security summary, recipients, and third-country transfers, plus an owner, a review state, and next-review dates, and exports any record or the whole register as a review-ready document. Because the review state lives on the record, the sequencing described above is visible rather than tracked in a side spreadsheet.
The recipients on a record can be linked to vendors your workspace already monitors. Since DPAFlow checks vendor subprocessor and legal pages on a recurring schedule and keeps dated evidence of what changed, a detected change on a linked vendor flags the affected activities for re-review and records which monitored event caused the flag. That is the event-driven half of maintenance, running without anyone remembering to check. What the change means for the record stays a judgement for your team.