Keeping your record of processing activities

If you came here because a supervisory authority, an auditor or a large customer has asked for your record of processing activities and you do not have one, that is the ordinary state of affairs for a small business, and it is the first thing they ask for precisely because it is the cheapest thing for them to check. This page is where you write it.

Find it at Govern → Records of processing (/compliance/gdpr/ropa).

Whether you need one at all

Article 30 obliges controllers and processors to maintain a written record of their processing. There is an exemption for organisations under 250 employees, but it is narrower than most people assume: it falls away if the processing is not occasional, or if it risks the rights of the people involved, or if it touches special categories of data such as health, or criminal-conviction data. Employing people and running payroll is not occasional. In practice, most businesses with staff fall back inside the obligation.

The register does not decide this for you and does not ask. It assumes you have concluded that you need one.

The eight elements, and what each actually asks

Article 30(1) enumerates the content of a record. The product counts eight elements, because it splits paragraph (c) into its two genuinely different questions — who the data is about and what data is held about them. That is why the column reads N/8 rather than N/7.

Controller and DPO contact — Art. 30(1)(a)

Your organisation's name and contact details, any joint controller, your representative if you have one, and your data protection officer if you have designated one.

Purposes — Art. 30(1)(b)

Why this processing happens. "Administering employment contracts and payroll" is a purpose. "Business operations" is not.

Categories of data subjects — Art. 30(1)(c)

Who the data is about: employees, contractors, job applicants, customers, website visitors.

Categories of personal data — Art. 30(1)(c)

What is actually held: name, contact details, bank account, employment history. A different question from the one above, and the one people most often conflate with it.

Categories of recipients — Art. 30(1)(d)

Everyone the data is disclosed to, including processors and including recipients in other countries. Your payroll bureau is a recipient. So is the tax authority.

Third-country transfers — Art. 30(1)(e)

Transfers outside the EEA, naming the country and the safeguard relied on. If there are none, write that it is none — silence does not satisfy the element.

Erasure time limits — Art. 30(1)(f)

The envisaged retention period, per category of data where they differ. "Payroll records: 7 years after employment ends."

Security measures — Art. 30(1)(g)

A general description of your technical and organisational measures under Article 32(1). General is the word the Regulation uses; you are not being asked for a network diagram.

The Lawful basis — Art. 6(1) dropdown sits in the middle of the form and is deliberately not counted towards the N/8, because Article 30 does not list it. It is there because a record that does not say on what ground you process is not much use to anybody reading it, and because the register's No lawful basis counter is the fastest way to find your weakest records. The choices are the six Article 6(1) grounds — consent, contract, legal obligation, vital interests, public task, legitimate interests — plus Not stated, which is the default.

Writing a record

1. 1

   Press Add record

   Top right of the panel, or from the middle of the empty state if this is your first one.

2. 2

   Name the processing activity

   This is the only required field on the form, and it is more consequential than it looks — it is the key the record is stored under. "Employee onboarding", "Customer support", "Marketing email". Name it the way you would describe it out loud, because you will have to retype it exactly to amend it later.

3. 3

   Fill in what you can, honestly

   Each element has a hint under it saying what it is asking for. Where the true answer is "none", write "none" — the element counts as present once there is any text in it, and an explicit "none" is a statement whereas an empty box is a gap.

4. 4

   Save record

   The record is stored, the server counts the elements, and the result comes back as a toast telling you where you stand.

The nine long fields are all free text and nothing validates their contents. Only two things can make a save fail: leaving the activity name blank, and a lawful basis the server does not recognise — which the dropdown makes impossible from the interface.

Why an incomplete record saves anyway

You can save a record that states one element out of eight. That is a decision, not an oversight. Refusing the save would mean the register only ever contains finished records, which in practice means it contains nothing at all for months while somebody chases the answers, and a register that does not exist cannot be improved.

What the product will not do is let you or anybody else mistake a partial record for a finished one. Save an incomplete record and you get a warning toast:

The same judgement is attached to the record permanently. The Art. 30(1) elements column shows the count and a sentence written by the server that travels with the record wherever it goes, including into the evidence bundle handed to an auditor:

The check behind that count is emptiness, not adequacy. Typing a full stop in the security-measures box makes the counter read one higher, and nothing in the product can tell the difference between that and a real answer. The N/8 measures whether you answered the question, never whether the answer is any good. Do not treat 8/8 as a verdict.

Amending a record — the part nobody tells you

So to amend a record today: open Add record, retype the activity name character for character, and re-enter every field including the ones you are not changing. Anything you leave blank becomes blank. If you mistype the name by a single character you will not overwrite the old record — you will create a second one, and the register will show both.

There is also no way to delete a record, from this screen or otherwise. A record created by mistake stays in the register. The practical workaround is to overwrite it with something that says plainly it was created in error, which is unsatisfying and which engineering knows about.

Every write, including every overwrite, is entered in the hash-chained compliance audit log with the record id, the activity, and which elements were present and missing at the time. That log is how a prior version is recovered, and it is not reachable from this page — see Verifying the audit chain.

If a save reports Saved, but the audit receipt was not written, the record was stored and its entry in that log was not. The change is real but sits outside the integrity proof, so it cannot later be shown to have happened when it did. This should never occur. Report it with the record name and the time, and do not assume the change is covered by the chain.

Reading the register

The counters appear only once there is at least one record; an empty register shows the empty state instead, which says what it means — this register is empty because nothing has been recorded, not because the platform looked and found nothing. The table itself sorts by activity, completeness or last updated, and has a search box. There are no row actions, no row click and no detail view: everything a record contains beyond its summary lines is visible only in the evidence bundle.

Getting the register out of the product

There is no export button on this page. The register leaves the product through the evidence bundle at Govern → Evidence, in two forms, and the difference between them matters a great deal here.

What this register does not do

• No edit and no delete. Amendment is overwrite-by-retyping the activity name, as above.
• No version history in the interface. Records are described as versioned, and the audit log does hold the history, but this page shows only the last writer and the last write time and does not link to the log.
• Nothing highlights the missing fields. The server knows exactly which elements are absent and names them in a toast that disappears; when you reopen the form nothing is marked.
• No approval, review date or owner. There is no reviewer, no sign-off, no annual review reminder, and no way to record that a record was checked and found still accurate.
• No link to anything else. A record of processing is not connected to the DPIA covering the same processing, to an asset, to a vendor, or to a data flow, even though Articles 30 and 35 describe the same activity from two angles.
• No template library and no starter records. Every register begins genuinely blank.
• No reminder that the register exists. Nothing prompts you when a record has gone stale or when you have added a new integration that plainly processes personal data.

What to do next

1. Write down the four or five activities you would name if somebody stopped you in the corridor. Employing people. Paying people. Selling to customers. Supporting customers. The website.
2. Create each one with only the activity name and the purpose. Accept the partial-record warning — it is a truthful description of where you are on day one.
3. Fill in lawful basis next, across all of them, in one sitting. It is a dropdown, it takes minutes, and it clears the counter that reads worst.
4. Then do retention and third-country transfers, which are the two that need someone to actually go and find out.
5. Leave security measures until last. It is the same answer for most activities and you will be copying it.
6. When a record is finished, save it once more with everything filled in, and check the column reads 8/8. Then read What an auditor will ask for, which is what happens to it next.

For what an auditor does with this once it exists, see What an auditor will ask for. For the parallel Article 35 register, see Data protection impact assessments.