GDPR Article 30: how to build a Record of Processing Activities without a spreadsheet

Article 30 requires every organisation with 250+ employees to maintain a formal ROPA - but even smaller teams should have one. Here's how to build an audit-ready record without drowning in spreadsheets.

GDPR Article 30 requires controllers (and processors) to maintain a written record of all personal data processing activities. The ICO and other supervisory authorities can request this record at any time. If you can't produce it, or if it's obviously incomplete, that signals a wider compliance failure and will attract scrutiny.

Article 30 applies to organisations with 250+ employees as a mandatory requirement - but also to any smaller organisation whose processing is 'likely to result in a risk to the rights and freedoms of data subjects', is not occasional, or includes special category data.

What must a ROPA contain?

For controllers, Article 30(1) requires the record to include:

The exemption that rarely applies

Article 30(5) is the provision small organisations reach for, and it is narrower than its headline. The under-250-staff threshold applies unless one of three things is true: the processing is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or it includes special categories of data under Article 9 or criminal conviction data under Article 10.

Those are alternatives rather than a checklist you must fail entirely, and the second defeats most organisations on its own. Payroll processed every month is not occasional. Customer records maintained continuously are not occasional. Sickness absence records are health data, so the third condition applies as well.

A ten-person company employing staff and serving customers will fail the test before it reaches anything unusual. The ICO's position in its documentation guidance is that most organisations need to document at least some of their processing.

Controller and processor records are different lists

Article 30 has two halves and they ask different questions. Paragraph 1 is the controller's record. Paragraph 2 is the processor's, and it is shorter.

Most organisations are both. You are a controller for your own staff and customers, and a processor for any client data you handle on instruction. Those need separate records, because one blended document answers neither paragraph properly.

Why spreadsheets fail

Most teams start their ROPA in a spreadsheet. It's free, familiar, and fast to set up. The problem emerges at scale: columns get added inconsistently, retention periods become stale, new processing activities get documented only if someone remembers, and there's no audit trail of who changed what and when. When an auditor asks to see your record, a messy spreadsheet with obvious gaps is worse than no record at all - it demonstrates disorganisation rather than good faith.

A practical approach to building your first ROPA

Step 1: Map your processing activities, not your data

The most common mistake is trying to document every piece of data before understanding why you hold it. Start with activities: HR and payroll, customer relationship management, marketing and analytics, IT systems and logging, recruitment, finance, and so on. Each activity becomes a row in your record. For most SMBs, you'll end up with 15-40 activities - more than that usually means you've gone too granular.

Step 2: For each activity, identify the data categories

For each processing activity, identify: what data you hold, where it lives (systems and locations), who has access, and how long you keep it. 'Where it lives' is the field most teams get wrong - it needs to include endpoint devices and shared drives, not just formal databases. Employees storing customer spreadsheets locally is extremely common and almost never captured in an initial ROPA.

Step 3: Document the lawful basis for each activity

Every processing activity needs a lawful basis under Article 6 (and Article 9 for special category data). Common bases for SMBs:

• Contract: processing necessary to perform a contract with the data subject (employees, customers)
• Legal obligation: payroll, tax reporting, health and safety records
• Legitimate interests: fraud prevention, network security, direct marketing to existing customers
• Consent: marketing emails to prospects, non-essential cookies

Step 4: Document retention periods

Retention is the field most ROPAs leave blank or fill with 'as required by law'. Be specific: HR records - 6 years after employment ends; financial records - 6 years (UK Companies Act); recruitment records for unsuccessful candidates - 6 months to 1 year; customer records - duration of relationship plus limitation period (typically 6 years). If you don't have a documented retention schedule, draft one before completing the ROPA.

Step 5: Document third-party transfers and processors

Any SaaS tool, cloud service, or outsourced function that touches personal data needs to appear in your ROPA as a recipient. This includes payroll providers, CRM vendors, cloud storage (including personal Dropbox or Google Drive accounts - yes, really), IT support firms, and marketing platforms. For each processor, you need a Data Processing Agreement. Check you have one before documenting them.

Keeping the ROPA current

A ROPA that was accurate 18 months ago is not compliant. Build a review cadence: at minimum, review annually, and trigger an immediate update whenever you introduce a new system, start a new processing activity, engage a new processor, or change your retention periods. The most practical approach is to make ROPA review part of your procurement and IT change management process - new tool procurement should automatically trigger a ROPA update.

Starting when you have nothing

The most common reason a record of processing does not exist is that building one looks like a project nobody has time to start. It is smaller than it appears if you resist the urge to be complete on the first pass.

1. 1List the processing activities you would name if a regulator rang today. For most organisations that is between eight and twenty: recruitment, employment, payroll, customer orders, support, marketing, supplier management, and a few that are specific to what you do.
2. 2Write one entry per activity with the fields you can fill in from memory. Leave gaps rather than guessing, because a guess looks the same as a fact once it is written down.
3. 3Give each entry an owner who runs the process, not the person who owns the record. They are the one who will know when it changes.
4. 4Fill the gaps by asking the owners rather than by inspecting systems. It is faster and it surfaces the activities nobody told you about.
5. 5Check the categories and locations against what is actually held, which is the step that turns the document from a description into a record.
6. 6Set a review date per entry and treat a passed date as a finding with a name against it, the way you would an overdue patch.

The first version will be incomplete and that is the correct outcome. A partial record that reflects reality is more use to you, and more credible to a regulator, than a complete one that describes an intended architecture.

One structural decision is worth making early, because it is expensive to reverse: one record per processing purpose, not per system. A single CRM can appear in three entries with three purposes, three lawful bases and three retention periods. Merging them into one row loses exactly the distinctions the record exists to hold.

The two fields that decay fastest

Every field in a record of processing goes stale eventually. Two go stale faster than the rest, and they fail in a way a review will not catch.

Categories of personal data is written from the system specification. The specification says name, email and phone. Two years later the same folder holds scanned passports from a verification exercise, bank details from an expenses process, and a sickness note somebody attached to an email. Article 30(1)(c) asks what categories you process, not what you intended to process.

The security measures field has the same problem in a different form. Article 30(1)(g) asks for a general description of the technical and organisational measures in Article 32(1), and those measures are scoped to where the data is. A description that is true of the primary system and silent about the exports, mailboxes and laptops it feeds describes an architecture rather than an estate.

Neither is caught by re-reading the entry, because the entry still describes the design accurately. Catching them means comparing the entry against what is actually held, which is a different activity from a document review.

What a regulator does with it

Article 30(4) requires the record to be made available to the supervisory authority on request. There is no reasonable-effort qualification and no period to prepare.

The request rarely arrives on its own. It usually follows a breach notification, a complaint, or a wider inquiry, and it arrives alongside requests for the lawful basis for the processing at issue, any DPIA, the privacy information you published, the processor contract, and evidence that your security measures were in place at the time.

That is why a thin record costs more than its own contents. It is read as evidence of whether the organisation understands its own processing, and blank transfer columns alongside single-word purposes suggest nobody has examined this recently. The immediate question then becomes whether the failure under investigation is isolated or characteristic.

A short record that is accurate beats a long one that is aspirational. If you are asked for it, do not pad it first, and if you update it in response to the request, say that is what you have done.

Discovering data you didn't know you had

One of the most uncomfortable outcomes of a thorough ROPA exercise is discovering processing activities that nobody formally authorised - personal data that exists in email archives, on individual laptops, or in old file shares that 'somebody set up years ago'. These shadow data stores are both a compliance gap and a security risk. Endpoint scanning tools can surface this unstructured data automatically, giving you an accurate picture of what you actually hold rather than what you think you hold.