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 a defensible 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:
| Field | What to document |
|---|---|
| Controller identity | Your organisation's name, address, and the name of any joint controllers |
| Purpose of processing | Why you process the data — e.g. 'payroll administration', 'customer support' |
| Categories of data subjects | Who the data relates to — employees, customers, prospects, etc. |
| Categories of personal data | The types of data held — names, emails, health data, financial data |
| Categories of recipients | Who you share the data with — processors, other controllers, regulators |
| Third country transfers | Any transfers outside the UK/EU and the safeguard relied upon (SCC, adequacy, etc.) |
| Retention periods | How long you keep each category of data |
| Security measures | A general description of technical and organisational security measures |
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.
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.