Keep the processing-activity register (GDPR Art. 30) current

When to use

Every quarter, and immediately after any change that adds, stops or materially alters a processing activity (new CRM, new payroll provider, new camera system, a product starts collecting end-customer data). Not for answering an individual's access or deletion request — that is support.data-subject-request. Not for the technical side (access rights, backups, device security) — that is tech.security-audit. Not for the annual company filings — that is money.annual-report-lv and company.registry-watch.

Before you start

• The previous register version is in the documents module, or the owner has confirmed this run creates it.
• A named person is the data-protection contact; if a DPO is designated, their details are known
• The quarter's change list exists: ask each module owner what tools, suppliers and data flows changed.

What a run requires1

The trail8 steps

1. S1

   Collect the quarter's changesagent

   Ask each module owner (in one message, one deadline): new tools, new suppliers touching personal data, stopped activities, changes in what data is collected or why.

   Done when every module owner has answered or the deadline has passed and the silence is recorded.

2. S2

   Inventory what actually runsagent

   List from the tools themselves, not from memory: which SaaS services hold personal data (mail, CRM, accounting, support, HR, analytics), which suppliers receive it, which backups hold it.

   Done when there is one list of systems that nobody disputes, dated today.

3. S3

   Diff the register against realityagent

   Compare the current register rows to the S2 list. Mark each row: unchanged · changed (what) · missing (system with no row) · dead (row with no live system).

   Done when every row has a mark and every unmatched system has a proposed new row.

4. S4

   Decide the changesownerneeds approval · owner

   Approval · S4 · owner — the run stops until a named person records the decision

   Present the diff: proposed new rows, changed rows, rows to retire. For each new activity the owner confirms purpose, legal basis, data categories, retention, and the named internal owner.

   Done when the owner has approved or corrected each proposed change, with the date recorded.

   ⛔ An activity without a named owner and a retention period does not go into the register — it goes back.

5. S5

   Update the registeragent

   Apply the approved changes: one row per activity with purpose, categories of data subjects and data, recipients, transfers outside the EU/EEA (if any, and the safeguard), retention, security measures in short, named owner. Version the file; never overwrite the previous version.

   Done when the new version is saved in the documents module and the diff between versions matches S4.

6. S6

   Check processorsagent

   For every supplier in the register: is a data-processing agreement (Art. 28) on file, and does it name the same supplier entity that actually holds the data? List any gap.

   Done when each supplier has "DPA on file — dated" or "missing — task created".

7. S7

   Create follow-up tasksagent

   For each gap from S5 and S6: a task with an owner and a due date (missing DPA → chase the supplier; dead activity → confirm data deleted or anonymised; new transfer → check the safeguard).

   Done when every gap has a task id, and none is assigned to "someone".

8. S8

   Record the runagent

   Write the review note: date, register version now in force, changes approved, gaps found, tasks opened, the owner's approval in S4. Link the note to the register file.

   Done when the note exists, is linked, and next quarter's date is in the calendar.

Checks — how we know it worked

• Pick three rows at random and verify each against the live system: the tool exists, the data it holds
• Every supplier in the register appears in the DPA check from S6 with a status — none "unknown".
• The register file is versioned: the previous version is still retrievable, and the diff equals S4's decisions.
• The review note names the approver and the date; the register states the version it describes.

If it goes wrong

What each step leaves behind

1. S1every module owner has answered or the deadline has passed and the silence is recorded.
2. S2there is one list of systems that nobody disputes, dated today.
3. S3every row has a mark and every unmatched system has a proposed new row.
4. S4the owner has approved or corrected each proposed change, with the date recorded.
5. S5the new version is saved in the documents module and the diff between versions matches S4.
6. S6each supplier has "DPA on file — dated" or "missing — task created".
7. S7every gap has a task id, and none is assigned to "someone".
8. S8the note exists, is linked, and next quarter's date is in the calendar.

Evidence to keep

Register version id and its diff · the S2 inventory list with date · S4 approval (who, when, what) · S6 DPA statuses with document links · task ids opened in S7 · the review note.

How this playbook improves

After four runs ask: did any activity surface that had run unregistered for more than one quarter, and where did it come from (a tool nobody owned, a supplier nobody listed)? Did any S6 gap repeat — if so the fix is in ops.new-supplier (make the DPA a step there), not in more chasing here. How long did S1 take, and would a standing checklist per module owner shorten it? A new version changes the step that let the gap through, and says so in its change note.