The Article 30 fields a controller and a processor each have to record, why the fewer than 250 employees exemption almost never gets a software company out of it, and what building the record actually takes.
A record of processing activities, usually shortened to ROPA, is the written inventory of how your organisation uses personal data. GDPR Article 30 requires every controller to record the purposes of the processing, the categories of data subjects and personal data, who receives the data, any transfers outside the EU, the envisaged erasure periods and the security measures in place. A processor keeps a shorter record of the processing it carries out for each controller. The record must be in writing, and you must hand it to a supervisory authority on request.
A record of processing activities is the document that shows a regulator what personal data your organisation holds, why, where it goes and how long it is kept. GDPR Article 30(3) requires it in writing, including electronic form, so a spreadsheet or a structured tool both qualify. Article 30(4) gives it teeth: you must make the record available to the supervisory authority on request, which means it is the first thing asked for when a complaint or a breach notification lands.
This is the question most small companies get wrong, and it is worth being precise. GDPR Article 30(5) says the Article 30 obligations do not apply to an organisation employing fewer than 250 persons, and then immediately adds three exceptions. The obligation comes back if the processing is likely to result in a risk to the rights and freedoms of data subjects, or if the processing is not occasional, or if the processing includes special category data under Article 9(1) or criminal conviction data under Article 10.
Those three conditions are alternatives, not a checklist you have to fail on all counts. Any single one of them re-imposes the full duty. The one that catches almost everybody is the middle test. Processing that happens continuously as part of how the business runs, such as holding customer account records, running payroll or handling support tickets, is not occasional by any reasonable reading. A company of 20 people with a live product and a payroll is doing non-occasional processing every day.
So for most organisations of 5 to 200 people the exemption does not help. It was written for the genuinely intermittent case, such as a business that processes personal data only when it occasionally sends a mailout. If you run a software product, assume GDPR Article 30 applies and keep the record.
GDPR Article 30 sets out two lists, and which applies depends on whether you act as controller or processor for that activity. The controller list in Article 30(1) has seven items; the processor list in Article 30(2) has four. Erasure limits and security measures are qualified "where possible", transfers "where applicable".
| Field | Controller, Article 30(1) | Processor, Article 30(2) |
|---|---|---|
| Contact details | Controller, any joint controller, representative and DPO | Processor, each controller it acts for, representatives and DPO |
| Purposes of the processing | Required | Not required. Instead: categories of processing per controller |
| Categories of data subjects and of personal data | Required | Not required |
| Categories of recipients | Required, including any in third countries | Not required |
| Third country transfers | Where applicable, naming the country and the safeguards | Where applicable, naming the country and the safeguards |
| Envisaged erasure time limits | Where possible, per category of data | Not required |
| Security measures under Article 32(1) | Where possible, a general description | Where possible, a general description |
The Article 30 list is a set of field names, not a format, and this is where most published guidance stops. In practice a record of processing activities is a table with one row per activity. The four illustrative entries below show the shape for a software company acting as a controller.
| Processing activity | Purpose | Data subjects and data | Recipients | Erasure |
|---|---|---|---|---|
| Customer account administration | Providing and billing the product | Customer users. Name, work email, role, login timestamps | Cloud hosting provider, payment processor, support desk tool | 30 days after account closure |
| Payroll and HR records | Meeting employment and tax obligations | Employees. Name, address, bank details, tax ID, salary | Payroll bureau, accountant, tax authority | Per local employment and tax law |
| Customer support tickets | Resolving support requests | Customer users. Name, email, ticket content | Support desk tool, engineering team | 24 months after ticket closure |
| Marketing email list | Product updates, on the basis of consent | Subscribers. Name, email, engagement events | Email marketing platform | On unsubscribe, or 24 months of inactivity |
Two columns do more work than they look. Recipients is where a record of processing activities quietly becomes a vendor inventory, because every sub-processor has to appear. Erasure is where most first drafts fall apart, because teams find they have no retention rule to write down. Writing "indefinite" across every row invites a follow-up question from a regulator.
GDPR Article 30 sets no review interval. The obligation is to maintain the record, and a record that no longer describes what you actually do is not maintained. That makes the practical answer event driven, with an annual backstop. Review the record whenever one of these happens:
On top of that, schedule one full review a year. The UK Information Commissioner's Office guidance on documenting processing activities takes the same line, treating the record as something kept current rather than produced once.
A record of processing activities carries no licence fee of its own, so the cost is the time to build the first version plus whatever tooling keeps it current. The table states plainly where a figure is not publicly available.
| Cost component | What it covers | Cost as of September 2026 |
|---|---|---|
| CertAssist subscription | Every GDPR control, editable policy and record templates, read-only auditor access | US$225 per month, or US$2,475 per year |
| Vanta, Drata and comparable platforms | Automated evidence collection and continuous monitoring | No published list price. Both sell by custom quote only |
| Building the first record | Interviewing teams, listing systems and vendors, agreeing retention | Internal time. Under 50 people, budget a few days over two to four weeks |
| Keeping the record current | Adding new vendors and features, running the annual review | Internal time. A few hours a quarter once the first version exists |
| Data protection officer | Required only where GDPR Article 37 applies | Nil for most SMBs, otherwise a salaried or fractional appointment |
| Legal review | A lawyer checking lawful basis, transfers and retention | Optional. Varies by jurisdiction and scope |
The record itself is cheap; the thinking behind it is not. Agreeing a retention period for support tickets is a business decision that takes a conversation, and no tool shortens it.
Usually both roles apply at once, and this trips up software companies. A business acting as a processor still owes a record under GDPR Article 30(2) covering the categories of processing it carries out for each controller. A software company is typically a processor for the customer data inside its product and a controller for its own employee records, marketing list and sales pipeline. Keep one record with a column marking the role per activity, because two documents means the same vendor appears twice and drifts out of sync.
If your organisation processes no personal data of people in the EU or UK, GDPR Article 30 does not apply and a ROPA is not where to start. A US company selling only to US customers, with no EU staff or users, is governed by other rules, and state laws such as the CCPA set their own requirements.
A record of processing activities also has limits worth naming. It does not make an organisation GDPR compliant. It documents processing; it does not establish a lawful basis, write a privacy notice, run a data protection impact assessment or handle a data subject request. Treating the ROPA as the finish line is a common and expensive mistake.
CertAssist is also the wrong tool for one version of this job. CertAssist does not connect to your systems, by design, so it will not scan your databases to discover personal data you have forgotten about. If nobody knows what data exists across hundreds of systems, you need data discovery tooling, and the trade-offs are covered in our guide to automated evidence collection and the access it needs.
CertAssist lays out the GDPR requirements as controls with a documentation and evidence checklist against each one, including the Article 30 record, plus editable templates so the first draft is not a blank page. Your assessor gets read-only access, every change carries activity history, and multi-factor authentication is mandatory. CertAssist costs US$225 per month as of September 2026 and needs no access to your cloud, identity provider or code, so there is nothing to integrate and nothing to breach. GDPR is live in CertAssist today, alongside the others on the frameworks page.
A record of processing activities includes, for each processing activity, the purpose of the processing, the categories of data subjects and of personal data, the categories of recipients, any transfers to a third country and the safeguards used, the envisaged erasure period, and a general description of the technical and organisational security measures. Controllers also record their own contact details and those of any data protection officer.
Records of processing activities are important because GDPR Article 30 makes them mandatory for most organisations and Article 30(4) requires you to hand the record to a supervisory authority on request. Infringements of Article 30 carry fines of up to 10 million euro or 2 per cent of total worldwide annual turnover, whichever is higher. The record is also the practical starting point for answering data subject requests.
Update your record of processing activities whenever the underlying processing changes: a new product feature that collects different data, a new sub-processor or vendor, a new country you transfer data to, a changed retention period, or a new lawful basis. GDPR Article 30 sets no fixed interval, so most organisations also schedule a full review once a year to catch anything that slipped through.
A register of processing activities is the same thing as a record of processing activities. GDPR Article 30 uses the word record, while many organisations, supervisory authorities and templates say register, data processing register or ROPA. All four names describe the written inventory of processing activities that Article 30 requires. The name you use does not change what the record has to contain.
Yes. GDPR Article 30(2) requires each processor to maintain a record of all categories of processing carried out on behalf of a controller. The processor record is shorter than the controller record: contact details for the processor and each controller it acts for, the categories of processing per controller, third country transfers with their safeguards, and a description of security measures.
CertAssist lays out every GDPR control, gives you editable policy and record templates, and lets your assessor review it all in one place, for a flat $225 a month. No integrations required.
See pricing FrameworksFlat $225 a month, or $2,475 a year (12 months for the price of 11). All prices in USD.
