Records of processing activities

UK GDPR Article 30 requires controllers and processors to keep a written record of their processing activities: what data, about whom, for what purpose, shared with whom, sent where, kept how long and protected how. Organisations under 250 people are exempt only for occasional, low-risk processing without sensitive data, which rarely covers much. EU GDPR has the same article.

The requirement in plain English

The record of processing is your organisation’s map of its personal data. It is the main way you show accountability (UK GDPR Article 5(2)), and you must give it to the regulator on request (UK GDPR Article 30(4)). The same article applies in EU GDPR, and the Data (Use and Access) Act 2025 left its substance unchanged in the UK.

As a controller (UK GDPR Article 30(1)), the record holds:

your name and contact details, and those of any joint controller, representative and data protection officer;
the purposes of the processing;
the categories of people and of personal data;
the categories of recipients, including any abroad;
transfers abroad and, where needed, the safeguards relied on;
where possible, the time limits for erasing each category;
where possible, a general description of your security measures.

As a processor (UK GDPR Article 30(2)), the record is shorter: your details and those of each controller you act for, the categories of processing for each, any transfers abroad, and your security measures.

The exemption (UK GDPR Article 30(5)) applies to organisations with fewer than 250 employees, but not to processing that is likely to result in a risk to people, that is not occasional, or that includes special category or criminal offence data. Any one of the three is enough to bring the processing back in.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 20-person e-commerce business keeps its record in a shared spreadsheet with one row per processing activity: payroll, recruitment, customer orders, newsletter, customer support, website analytics. The operations manager owns it.

Each row carries the Article 30 fields plus the extras that make the record useful: the lawful basis, the source of the data, the system it lives in, the processor that hosts it, whether a data protection impact assessment was needed, and the link to the privacy notice paragraph that describes it. Retention periods are copied from the retention schedule rather than typed fresh.

The record changes with the business. A new supplier, a new form or a new market triggers an update the same week, through the supplier approval and change processes. Once a year the owner walks the record with each team lead and asks one question per row: is this still true? Superseded rows are kept, dated, so the business can show what it did at any point. An auditor can open the record, pick a row and follow it to the notice, the contract and the retention schedule.

Evidence an auditor expects

The record itself: required unless every activity is exempt; the auditor checks each Article 30 field is present for each activity.
Processor record: required where you act as a processor; the auditor checks it lists each controller you serve.
Lawful basis per activity: not an Article 30 field, but usual; the auditor uses it to test the notice and the record against each other.
Retention schedule: usual; the auditor checks the periods in the record match it.
Review history: usual; the auditor looks for dated reviews and updates after changes.
Exemption reasoning: required if you rely on the exemption; the auditor checks why each excluded activity is occasional, low risk and free of sensitive data.

Common mistakes

Claiming the exemption for routine processing

Payroll runs every month, and staff records hold health data. A small organisation that skips the record because it has under 250 people usually fails at least one of the three conditions for most of what it does.

A record built once for an audit

A record written in a week before certification and never touched again describes the business as it was then. Tie updates to the events that change processing: new suppliers, new systems, new purposes.

Systems instead of activities

A list of applications is an asset register, not a record of processing. The unit is the purpose: “payroll” uses three systems, and one system can serve five purposes.

Retention left blank

UK GDPR Article 30(1) asks for erasure time limits where possible, and regulators read that narrowly. If you can set a period or a rule for erasure, you are expected to, yet it is often the field left empty.

Categories so broad they say nothing

“Customer data” on every row tells nobody anything. Name the categories, such as contact details, order history, payment tokens and support transcripts, so that a request, a breach or a retention review can use the record.

Forgetting the processor side

Software companies record their own staff and customer data as a controller, and forget the data their clients put into the product. That needs a processor record too.

How Sted helps

Onboarding asks about the personal data you process, activity by activity (its purpose, who it is about, how long it is kept and whether you act as controller or processor), and about transfers abroad with their safeguard; Summary’s Data and privacy card lists the processing activities by name and status and each transfer’s recipient, role and destination.
The card is a summary of what onboarding recorded, not a record of processing activities.
Sted treats UK GDPR, and separately EU GDPR, as applying when you process any personal data and are established in that territory or offer goods or services to, or monitor, people there; it reads your controller and processor roles from your processing activities, notes when an Article 27 representative is needed, and holds its confidence at medium until a processing activity is recorded.
Sted’s Personal Data Protection Policy (POL-PDP) has its own sections on lawful basis, special category data, individuals’ rights, security, processors and international transfers, records of processing and the data protection officer, each tagged to the UK GDPR and EU GDPR requirements it meets.
Sted’s knowledge base includes a Data Retention Schedule (REC-DRS) under the Data Retention and Erasure Policy (POL-DRE), recording for each category of data its purpose, legal basis, retention period and trigger, and how it is erased at the end.
Records are part of the Full Management System plan.

Your record of processing stays your own document. Onboarding answers and Summary are a starting point for it.

UK GDPR and EU GDPR: why the record sits at the end of the accountability chain.
Lawful basis for processing: the basis each row of the record should name.
Processors and data processing agreements: the contracts behind the recipients in your record.
Records of processing: the term defined.
Data protection officer: one of the contacts the record names.
Onboarding: where Sted asks about your processing activities.
Personal data breaches: the record tells you whose data and which systems a breach touched.

Frequently asked questions

Do I need a record of processing if I have fewer than 250 employees?

Almost certainly, at least in part. The exemption falls away for any processing that is not occasional, and payroll, HR and customer data are processed every week. Most small organisations therefore keep a record covering those activities, and the exemption saves them little.

Can a spreadsheet be my record of processing?

Yes. The law asks for a written record, which can be electronic, and says nothing about the tool. What matters is that it holds every required field for every activity, has an owner, and is kept up to date when processing changes.