← Insights

Data protection

Records of processing: the Article 30 document you cannot skip

July 2026 · 7 min read

If you only ever produce one data-protection document, make it this one. A Record of Processing Activities - a RoPA - is the plain answer to the first question any assessment asks: what personal data do you handle, and why? Everything else in your compliance stack refers back to it. Your Privacy Notice is drawn from it. Your retention rules attach to it. When a subject access request lands, the RoPA is how you know where that person's data might be.

It is also the requirement most small organisations assume does not apply to them. It usually does.

What Article 30 asks for

Article 30 of the UK GDPR requires controllers to maintain a record of their processing activities. There is a widely repeated belief that organisations under 250 people are exempt. Read the exemption carefully and it mostly evaporates: it falls away if your processing is more than occasional, if it could risk people's rights and freedoms, or if it involves special-category data. A business that processes staff payroll, holds a customer database and runs marketing is doing regular processing of ordinary and often sensitive data - which is to say, the exemption rarely covers a real operating business. Treating the RoPA as mandatory is the safe and honest assumption.

The record does not have to be elaborate. It has to be complete, current, and genuinely reflective of what you do. A spreadsheet is entirely adequate; a spreadsheet that lists your processing activities honestly beats a beautiful document that describes an organisation you are not.

What each column actually captures

A RoPA is a table, one row per processing activity, and the columns are the substance. Each one answers a specific question a regulator or an individual might put to you.

• Purpose. Why you process this data - "administer payroll", "fulfil customer orders", "send marketing to people who opted in". Vague purposes are where accountability leaks away, so be concrete.
• Data subjects and categories. Whose data (employees, customers, suppliers) and what data about them (contact details, financial, health). This is what tells you, during a DSAR, where to look.
• Lawful basis. The ground you rely on to process at all - consent, contract, legal obligation, legitimate interests and the rest. Every activity needs one, named, before the processing starts, not reverse-engineered afterwards.
• Source. Where the data came from - directly from the person, or from somewhere else.
• Recipients. Who you share it with. Your accountant, your email platform, your payment processor - every processor and third party that touches it.
• Transfers and safeguards. Whether the data leaves the UK or EEA and, if so, what protects it - the columns that get the closest scrutiny, because international transfer is where the rules bite hardest.
• Retention. How long you keep it. This links straight to your retention schedule and answers "why do you still have this?"
• Security measures. How the data is protected - the technical and organisational controls around it.

Fill those honestly for each activity and you have not just satisfied Article 30; you have built the map the rest of your compliance runs on.

Two categories that deserve extra care

Two kinds of row carry more risk than the rest and are worth flagging visibly. Special-category data - health, ethnicity, religion, biometrics and the rest - needs a stronger lawful basis and tighter handling. International transfers - any activity that moves data outside the UK or EEA - needs a legal transfer mechanism behind it. Making these rows stand out on sight means the entries that most need attention are the ones you cannot overlook.

The gap that undoes most RoPAs

The failure of a RoPA is rarely that it does not exist. It is that it is half-filled. Someone starts the register, completes the easy columns, leaves the lawful basis or the retention period blank on a dozen rows, and the gaps sit there unnoticed until an audit finds them. A plain template gives you the columns and leaves the completeness entirely to you - and a busy person is exactly the wrong person to rely on for that.

Far better to have the register check itself: read the mandatory fields on each row, decide whether that activity's record is complete or incomplete, and then name the fields that are missing so finishing the record is a short to-do list rather than a hunt through a wall of cells. That single feature turns the RoPA from a document you hope is finished into one that tells you when it is.

Keep it current as your processing changes, and the RoPA quietly becomes the most useful page in your data-protection folder - not the box-tick everyone assumes, but the thing the rest of it stands on.