Last verified: 5 August 2026
Ask a room of small-business owners whether GDPR Article 30 applies to them, and most will point at the number 250. Fewer than 250 employees, they’ll say, so the record-keeping rule is somebody else’s problem. It’s the tidiest myth in data protection, and it’s wrong far more often than it’s right. The exemption they’re leaning on is real, but it’s narrow, riddled with exceptions, and it collapses the moment your business does anything routine with personal data.
Here’s what actually happens. A 12-person SaaS startup in Bengaluru signs up EU users every week. Payroll runs monthly for its own staff. A CRM tracks every lead.
Under the headcount myth, none of that needs documenting. Under the real text of GDPR Article 30, all of it does, because the exemption only survives when your processing is genuinely occasional, low-risk, and free of sensitive data.
Regular signups aren’t occasional. Monthly payroll isn’t occasional. The “under 250” shield turns out to protect almost nobody who runs a normal operation.
That gap between what people believe and what the regulation says is where the fines live. A supervisory authority investigating a complaint or a breach asks for the record of processing activities early, often first. If you can’t produce one, you haven’t just failed a paperwork check. You’ve handed the regulator evidence of a systemic accountability failure, and that colours everything that follows.
The good news is that Article 30 is one of the most learnable obligations in the whole regulation. It asks for a defined list of fields. It tells you who has to keep them and in what form.
And once you understand the controller-versus-processor split and the genuine scope of the small-business exemption, building a compliant record is a weekend of structured work, not a mystery. For privacy professionals, that same clarity is a billable skill: EU controllers and processors pay for well-drafted records, and the work travels across borders without you leaving your desk.
GDPR Article 30 requires every data controller and processor to keep a written record of their processing activities, listing specific details such as the purposes of processing, the categories of data and recipients, retention periods, and security measures. The record must be available to the supervisory authority on request. The exemption for organisations under 250 employees is narrow and rarely applies to routine processing.
Skip the record and you’re exposed to fines of up to €10 million or 2% of worldwide turnover, and you’ve weakened your defence on every other GDPR obligation that depends on it. So the real question isn’t whether Article 30 applies to you. It’s what a compliant record has to contain, who inside your business owns it, and how narrow that famous exemption really is.
What does GDPR Article 30 require?
GDPR Article 30 requires controllers and processors to maintain a written record of the processing activities they carry out. That’s the whole obligation in one line, and it flows directly from the regulation’s accountability principle: you don’t just have to comply, you have to be able to demonstrate that you comply. The record is how you show your working.
The formal source is Article 30 of the GDPR (Regulation (EU) 2016/679), and its purpose is spelled out in Recital 82, which states that “the controller or processor should maintain records of processing activities under its responsibility” in order to demonstrate compliance. Two mechanical requirements sit alongside the content list.
Article 30(3) says the record must be “in writing, including in electronic form”, so a spreadsheet counts and a verbal walkthrough does not. Article 30(4) says you must make the record available to the supervisory authority on request. There’s no filing deadline and nowhere to submit it in advance. You keep it current, and you hand it over when asked.
How Article 30 replaced the old notification regime
This looks new to a lot of people, but it’s really a swap. Under the previous EU regime, the 1995 Data Protection Directive, organisations often had to notify or register their processing with a national data protection authority before they started. That system was slow, inconsistent across member states, and generated paperwork nobody read.
When the GDPR replaced the Directive in 2018, it scrapped upfront notification and put the responsibility back on the organisation: keep your own records, keep them accurate, and produce them on demand. The burden shifted from asking permission to proving accountability.
For an India-based processor serving EU clients, a “request from the supervisory authority” isn’t abstract. Say a Pune firm handles support tickets for a German software company. If a data subject complains to the German regulator and the regulator opens an inquiry, it can ask the German controller for its record, and the controller will turn to its processor for the matching processor-side record. Your documentation becomes part of your client’s regulatory response, sometimes within days.
In practice, the record does more work than its own article suggests. A data protection impact assessment under Article 35 starts from knowing what you process and why, which is exactly what the record captures. A breach notification under Article 33 has a 72-hour clock, and the first thing you need is a clear picture of the affected processing.
Teams that keep a living record answer both faster. Teams that don’t end up reconstructing their entire data landscape under pressure.
A question that comes up constantly: isn’t this just the privacy policy? No, and conflating the two is a common early mistake. A privacy policy is an outward-facing notice written for data subjects, telling people what you do with their data. The record of processing activities is an internal accountability document written for you and the regulator.
One is marketing-adjacent and public; the other is operational and confidential. They draw on overlapping facts, but they are not interchangeable, and a regulator asking for your Article 30 record will not accept a link to your website’s privacy page.
Who must keep a record of processing activities?
Both controllers and processors must keep a record of processing activities, and each keeps its own. Article 30(1) sets out the controller’s obligation and Article 30(2) sets out the processor’s, with different content requirements for each.
A controller decides why and how personal data is processed. A processor acts on the controller’s instructions. If your organisation does both, and many do, you keep both records.
Geography is where people miscount their exposure. The obligation follows the GDPR’s territorial reach under Article 3 of Regulation (EU) 2016/679, which extends to organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour. An Indian company with no EU office can still be squarely in scope. If you process the personal data of people in the EU as part of serving that market, Article 30 reaches you the same way it reaches a Berlin startup.
Joint controllers, representatives, and the DPO
The record names people, not just processes. Where two organisations decide the purposes and means of processing together, they are joint controllers, and each names the other in its record. Organisations caught by the extraterritorial rule often have to appoint an EU representative under Article 27, and that representative’s contact details go in the record too.
So does the data protection officer, if you’ve appointed one. The point is that a regulator reading your record should be able to find the responsible parties without a scavenger hunt.
Does Article 30 apply to non-EU companies?
Yes, whenever the extraterritorial trigger fires. A remote-first analytics vendor in Hyderabad that processes behavioural data on EU website visitors for an EU client is processing EU residents’ data, and both the client (controller) and the vendor (processor) carry Article 30 records. The absence of a European entity doesn’t create an exemption. What matters is whose data you touch and why, not where your servers or your team happen to sit.
Consider a concrete case. A bookkeeping outfit in Pune runs monthly payroll for a UK company’s employees. The Pune firm doesn’t decide why the payroll happens or set the retention rules; it follows the client’s instructions.
That makes it a processor, and it needs a record under Article 30(2) describing the categories of processing it performs for that client. Skilled privacy practitioners treat this as recurring, well-paid work, and in many organisations the data protection officer usually owns this record, drawing on exactly the kind of governance skill set that a data protection officer role demands.
A frequent question from smaller operators: does a sole trader or a two-person agency really need one? Usually the honest answer is a scoped yes, because the exemption most of them hope to use is far narrower than its headline suggests. That’s the next section, and it’s the one that trips up the most businesses.
The pitfall here is the “we’re only the processor, so it’s the controller’s job” reflex. Processors have their own, distinct Article 30(2) obligation. Relying on your client to document your side of the arrangement leaves you personally exposed if a regulator asks the processor directly, which it can and does.
Contents of a compliant Article 30 record
A controller’s record under Article 30(1) has to capture seven categories of information for each processing activity. The list is fixed, so the smartest approach is to treat it as a template and fill every field rather than guess at what a regulator wants. Working from the text of Article 30(1), here is what each activity needs.
The mandatory fields, in plain English
- Controller identity and contacts: the name and contact details of the controller, plus any joint controller, the controller’s representative, and the data protection officer where those apply.
- Purposes of the processing: why you process the data, stated specifically (“run monthly payroll”, not “business operations”).
- Categories of data subjects and personal data: who the data is about (employees, customers, website visitors) and what kinds of data you hold (contact details, financial data, and so on).
- Categories of recipients: who the data is disclosed to, including recipients in third countries or international organisations.
- Third-country transfers: details of transfers outside the EU and, for the specific transfers referred to in the second subparagraph of Article 49(1), documentation of the suitable safeguards.
- Retention periods: where possible, the envisaged time limits for erasing each category of data.
- Security measures: where possible, a general description of the technical and organisational measures you use, the ones referenced in Article 32.
Note the “where possible” qualifier on the last two. It’s a small relief, not an escape hatch: regulators expect a genuine effort, and leaving retention and security blank on every line looks like you didn’t try. That security-measures field is also where a written information security program pays off; teams that already maintain one, such as the offshore firms building a plan under the FTC Safeguards Rule and a WISP, can often reuse that description here.
Here’s what one complete entry looks like in practice, for a single controller-side activity:
Worked example: one controller record entry (payroll):
| Field | Example value |
|---|---|
| Processing activity | Monthly employee payroll |
| Purpose | Pay salaries and meet statutory reporting |
| Categories of data subjects | Current and former employees |
| Categories of personal data | Name, address, bank account, salary, tax IDs |
| Recipients | Payroll software vendor, bank, tax authority |
| Third-country transfers | None (or: transfer to US vendor under SCCs) |
| Retention period | Duration of employment plus 7 years |
| Security measures | Encryption at rest, role-based access control, access logging |
Fill a row like that for every distinct activity, payroll, marketing emails, customer support, recruitment, and the record starts to build itself.
What experienced practitioners know is that two fields get skipped most often, and they’re the two “where possible” ones: retention periods and the security description. People treat the qualifier as optional and move on. Regulators read empty retention columns as a sign that the organisation has no data-minimisation discipline, which invites harder questions. Fill them in even when it takes a judgement call.
A common question is whether a spreadsheet is enough or you need dedicated software. A spreadsheet is genuinely enough. Article 30(3) only requires the record to be in writing, including electronic form, so a well-structured workbook satisfies the law. Software helps once you’re tracking dozens of activities across teams, but it’s a convenience, not a legal requirement, and no regulator will fault a clean spreadsheet.
The pitfall to avoid is lifting your purposes straight from the public privacy policy. Marketing language (“we value your privacy”) is useless in a record. Each purpose should map to a real, specific operation your business performs, described plainly enough that someone who’s never seen your systems understands what happens to the data.
How do controller records differ from processor records?
The two records overlap but they are not the same, and mixing them up is one of the more common technical errors. A controller record under Article 30(1) documents the why: purposes, retention, the full data lifecycle. A processor record under Article 30(2) documents the what and for whom: the categories of processing carried out on behalf of each controller, without needing to state the controller’s purposes or retention rules.
Controller record vs processor record (side by side):
| Field | Controller (Art 30(1)) | Processor (Art 30(2)) |
|---|---|---|
| Own identity and DPO | Required | Required |
| Each controller served | Not applicable | Required, named individually |
| Purposes of processing | Required | Not required |
| Categories of data subjects and data | Required | Not required in the same form |
| Categories of processing per controller | Not applicable | Required |
| Recipients | Required | Not required |
| Third-country transfers | Required | Required |
| Retention periods | Required (where possible) | Not required |
| Security measures | Required (where possible) | Required (where possible) |
Read across the table and the logic is clear: the processor doesn’t set the purpose or the retention rules, so it isn’t asked to record them. But it must name every controller it works for and describe the categories of processing it does for each, which a controller never has to do.
Take an Indian SaaS vendor that stores support-ticket data for several EU customers. As a processor, its record lists each EU customer as a controller, and for each one it notes the categories of processing (storing, searching, and analysing support tickets). The EU customer, meanwhile, keeps a controller record that states why it processes those tickets and how long it keeps them. Same data, two records, two different jobs.
Dual-role organisations are the ones that need to slow down. A company processing its own employees’ data is a controller for that activity, and processing client data on instruction makes it a processor for that other activity. It keeps both a controller record and a processor record, and the two shouldn’t be merged into one confused document. Keeping them separate mirrors how a regulator will read them.
A question that surfaces on privacy forums: as a processor, do we still need to list retention periods? Strictly, Article 30(2) doesn’t require it. In reality, many controllers demand it in the data processing agreement, so you’ll often record retention anyway to satisfy the contract. Legal minimum and client expectation aren’t always the same number, and the client usually wins.
The pitfall is a processor that keeps only a controller-style record and never breaks its work down per controller. If a regulator asks which controllers you act for and what you do for each, a single generic record won’t answer the question, and that gap is exactly what Article 30(2) exists to close.
Are businesses with fewer than 250 employees exempt?
Most businesses under 250 employees are not exempt, despite the widespread belief that they are. The exemption is real, but Article 30(5) writes it as a rule with three large holes, and routine business processing falls through all of them. This is the single most misread part of the whole article.
Here’s the actual mechanism. Article 30(5) says the record-keeping obligations don’t apply to an organisation with fewer than 250 employees, unless one of three things is true.
The processing is likely to result in a risk to the rights and freedoms of data subjects. Or the processing is not occasional. Or the processing includes special categories of data under Article 9 (health, biometrics, religion, and the like) or criminal-conviction data under Article 10.
These are alternatives, not a checklist you have to fail entirely. Any single one of them switches the obligation back on.
The word doing the heavy lifting is “occasional”. The Article 29 Working Party, in a 2018 position paper endorsed by the European Data Protection Board, put it bluntly: the derogation “is not absolute”, and the three exceptions are alternatives, so the occurrence of any one alone triggers the obligation.
Their example is the one that ends the debate. “A small organisation is likely to regularly process data regarding its employees. As a result, such processing cannot be considered ‘occasional’ and must therefore be included in the record of processing activities.” Payroll, HR files, a recurring customer database, a CRM that logs every lead: none of that is occasional, so none of it is exempt, no matter how small the company.
Why the exemption rarely applies in practice
Because the “not occasional” trigger catches nearly all regular business activity, the exemption ends up covering only genuinely one-off, low-risk processing that involves no sensitive data. A truly seasonal one-time mailing might qualify. Your day-to-day operations almost never will. The knock-on effect is that skipping the record on the strength of headcount also weakens everything downstream: without it, your DPIA process has no foundation and your 72-hour breach response starts from a blank page.
There’s one narrowing worth knowing. The same position paper clarifies that an organisation relying on partial applicability “need only maintain records of processing activities for the types of processing mentioned by Article 30(5)”. So a small business isn’t necessarily documenting every trivial thing it does, but it must document all the processing that is regular, risky, or sensitive, which in practice is most of what matters.
Picture the 15-person Bengaluru startup again. It signs up EU users continuously, so that processing is not occasional. It runs staff payroll every month, also not occasional.
On those facts alone, well under 250 employees, it must keep a record. The headcount never enters the analysis, because a different trigger already fired.
The misread that costs businesses the most is treating “250 employees” as a hard on-off switch: over the line you comply, under it you’re free. It was never a switch. It’s a floor that only holds for occasional, low-risk, non-sensitive processing, and if you’re running a business that touches personal data every week, you cleared none of those conditions.
Penalties and enforcement under Article 83(4)
Breaching Article 30 sits in the GDPR’s lower fine tier, which still reaches up to €10 million or 2% of worldwide turnover. Under Article 83(4) of the GDPR, infringements of the controller’s and processor’s obligations, which expressly include Articles 25 to 39 and therefore Article 30, attract “administrative fines up to 10 000 000 EUR, or in the case of an undertaking, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher”. The higher-profile 4% tier under Article 83(5) is reserved for breaches of core principles and data-subject rights. Article 30 lives in the 2% band.
Lower tier does not mean low consequence. Two percent of global turnover is a serious number for any company with real revenue, and the “whichever is higher” wording means a well-funded startup can’t hide behind a small profit line. The figure is calibrated to hurt.
In practice, a supervisory authority rarely fines an organisation for a missing record alone. What happens is that the record gets requested during a broader investigation, usually triggered by a complaint or a data breach, and its absence becomes an aggravating factor. Under Article 83(2), regulators weigh the degree of cooperation and the organisation’s technical and organisational measures when setting a fine. Turning up with no Article 30 record signals a systemic accountability failure and pushes the penalty up.
A question that comes up on compliance forums: has anyone actually been fined purely over Article 30? Standalone cases are rare, and that’s the point people miss. The record’s absence usually surfaces alongside other failings and compounds them, rather than generating its own headline penalty. Regulators treat it as a diagnostic: an organisation that can’t produce its record often can’t demonstrate much else either.
The trap is dismissing the “lower tier” label as permission to deprioritise the record. The record is cheap to maintain and expensive to lack. When an investigation lands, it’s the first thing asked for and the fastest thing to get wrong, and its absence colours every later judgement the regulator makes about you.
How do you build a record of processing activities?
Building a record of processing activities is a six-step exercise, and you can complete a first version in a focused day or two. The aim is a living register you update as your processing changes, not a document you write once and bury. Here’s the sequence that works.
- Inventory your processing activities. Walk through the business function by function, HR, sales, marketing, support, finance, and list every distinct thing you do with personal data. This discovery step is where most of the real effort goes.
- Classify each activity as controller or processor. For each one, decide whether you set the purpose (controller) or act on someone else’s instruction (processor). Dual-role organisations tag some activities each way.
- Capture the mandatory fields. For every controller activity, fill the seven Article 30(1) fields; for every processor activity, fill the Article 30(2) fields, naming each controller you serve.
- Assign an owner. Give the record a named custodian, often the data protection officer or a senior operations lead, so it doesn’t drift.
- Set a review cadence. Diarise at least an annual review, plus an update whenever you launch a new processing activity or change an existing one.
- Make it retrievable. Store it where you can produce it quickly, because Article 30(4) gives the regulator the right to ask for it on request.
You don’t have to design the template from scratch. The UK’s Information Commissioner’s Office publishes free documentation guidance and downloadable ROPA templates, one for controllers and one for processors, and it stresses that the record “must reflect the current situation” and be treated as a living document. Starting from an official template saves hours and keeps your field names aligned with what regulators expect to see.
Here’s a filled processor entry to show the shape of the other record type:
Worked example: one processor record entry (support tickets):
| Field | Example value |
|---|---|
| Processor identity | Acme Support Services Pvt Ltd, DPO contact |
| Controller served | EU SaaS client (named individually) |
| Categories of processing | Storing, searching, and resolving support tickets |
| Third-country transfers | Transfer to India under Standard Contractual Clauses |
| Security measures | TLS in transit, encryption at rest, access controls |
Where record-keeping is heading
Two shifts are worth watching. First, record-keeping is going global: India’s Digital Personal Data Protection framework is maturing, and the DPDP Rules 2025 impose parallel record-keeping and documentation duties on Indian businesses, so the ROPA discipline you learn for GDPR transfers cleanly to domestic compliance. Second, automated and AI-driven processing is adding new lines to records, as organisations document model training data, inference activities, and the safeguards around them. Early signals suggest ROPA tooling will lean more on automated data discovery, but the underlying obligation, know what you process and be able to prove it, isn’t going anywhere.
For a privacy professional, this is where the record stops being overhead and becomes income. Drafting and maintaining ROPAs is a concrete, repeatable deliverable that EU controllers and processors will pay for, and it’s a natural on-ramp to building a career in data protection and privacy from anywhere. Several practitioners package it as a fixed-scope service, the kind of specialised offering that fits neatly into a fractional consulting practice serving multiple clients at once.
A recurring question is how often the record needs updating. At minimum, review it annually, and update it immediately whenever you add a new processing activity, change a vendor, or start a new type of data collection. The pitfall is the audit-driven record: built in a panic before an assessment, filed, and never touched again. A stale record can be worse than none, because it tells a regulator you documented your obligations once and then stopped caring.
Frequently asked questions
What is GDPR Article 30 in simple terms? It’s the GDPR rule that says organisations must keep a written record of what they do with personal data. The record lists things like why you process data, what kinds you hold, who you share it with, and how long you keep it. You keep it internally and show it to the data protection regulator when asked.
What is a record of processing activities (ROPA)? A ROPA is the document Article 30 requires: a structured inventory of your organisation’s processing activities and the key facts about each one. Controllers and processors keep different versions. It’s an internal accountability tool, not a public notice.
Is a ROPA the same as a data map or data inventory? They overlap heavily, and a good data inventory often forms the backbone of a ROPA. The difference is that a ROPA must capture the specific fields Article 30 lists, in a form you can hand to a regulator. A data map is a broader internal tool; the ROPA is its compliance-ready subset.
Who has to keep a record under Article 30? Both data controllers and data processors, each keeping its own record with different required contents. If your organisation acts as both, for different activities, you keep both records.
Does Article 30 apply to companies outside the EU? Yes, when the GDPR’s territorial scope applies, for example if you offer goods or services to people in the EU or monitor their behaviour. An Indian company serving EU customers can be fully in scope even with no EU office.
Are companies with fewer than 250 employees exempt from Article 30? Rarely, in practice. The Article 30(5) exemption disappears if your processing is not occasional, is likely to risk people’s rights, or involves special-category or criminal-conviction data. Routine activities like payroll and a customer CRM are “not occasional”, so most small businesses must still keep records.
What must an Article 30 record contain? For controllers: identity and contacts, purposes, categories of data subjects and personal data, recipients, third-country transfers, retention periods, and a description of security measures. Processors record their identity, each controller they serve, the categories of processing, transfers, and security measures.
What is the difference between Article 30(1) and Article 30(2)? Article 30(1) covers the controller’s record and asks for purposes and retention; Article 30(2) covers the processor’s record and instead asks it to name each controller and describe the processing done for each. Processors don’t have to record purposes or retention under the article itself.
Is a spreadsheet enough for a ROPA? Yes. Article 30(3) only requires the record to be in writing, including electronic form, so a well-organised spreadsheet is fully compliant. Dedicated software helps at scale but isn’t legally required.
Is there an official ROPA template? Yes. The UK Information Commissioner’s Office publishes free controller and processor templates and documentation guidance, which are a solid starting point for GDPR-style records.
How often should a record of processing activities be updated? Review it at least annually and update it whenever you start a new processing activity, change a vendor, or begin collecting a new type of data. The regulator’s guidance treats it as a living document that must reflect your current situation.
Who owns the ROPA inside an organisation? Usually the data protection officer, where one is appointed, or a senior operations or compliance lead otherwise. The key is a named owner accountable for keeping it current, rather than a document nobody maintains.
What is the penalty for not keeping a record under Article 30? Article 30 breaches fall under the lower fine tier in Article 83(4): up to €10 million or 2% of worldwide annual turnover, whichever is higher. In practice the missing record usually compounds penalties in a wider investigation rather than being fined on its own.
How does GDPR Article 30 compare with India’s DPDP record-keeping duties? Both push organisations toward documenting how they handle personal data, though the specific requirements differ. India’s DPDP Rules 2025 introduce their own operational documentation duties, so the discipline of maintaining a ROPA carries over well from EU work to Indian compliance.
Can I do ROPA drafting remotely for EU clients as a freelancer? Yes, and it’s a growing niche. Drafting and maintaining records is a defined, repeatable deliverable that EU controllers and processors outsource, and it needs no physical presence, which makes it well suited to remote privacy consultants building an international client base.
References
Official guidance & regulations
- Article 9 GDPR: Processing of special categories of personal data, Regulation (EU) 2016/679
- Article 10 GDPR: Processing of personal data relating to criminal convictions and offences, Regulation (EU) 2016/679
- Article 30 GDPR: Records of processing activities, Regulation (EU) 2016/679
- Article 32 GDPR: Security of processing, Regulation (EU) 2016/679
- Article 83 GDPR: General conditions for imposing administrative fines, Regulation (EU) 2016/679
- Recital 82: Record of processing activities, Regulation (EU) 2016/679
- Regulation (EU) 2016/679 (full consolidated text, CELEX 32016R0679), Official Journal of the European Union, L 119/1
- Position paper on the derogations from the obligation to maintain records of processing activities (Article 30(5)), Article 29 Working Party / European Data Protection Board, 2018
- Documentation (records of processing activities): guidance and templates, Information Commissioner’s Office (UK)
This article is for educational purposes only and does not constitute professional, financial, legal, or immigration advice. For guidance specific to your situation, consult a qualified professional.
Allow notifications
