Does the Article 30 exemption for organisations with fewer than 250 employees mean we do not need a record of processing?

Rarely. Article 30(5) only exempts smaller organisations when the processing is not likely to result in a risk, is occasional, and does not include special category or criminal offence data. Regular processing such as payroll, customer accounts or security logging is not occasional, so most organisations need a record for at least those activities.

What is the difference between a controller record and a processor record under Article 30?

A controller record under Article 30(1) describes purposes, categories of data subjects and personal data, recipients, transfers, erasure time limits and security measures. A processor record under Article 30(2) lists each controller the processor acts for, the categories of processing carried out on their behalf, transfers and, where possible, a general description of security measures.

Can the record of processing live in a YAML file or a CMDB instead of a spreadsheet?

Yes. Article 30(3) requires the record to be in writing, including in electronic form. What matters is that it contains the required fields, is kept current, and can be made available to the supervisory authority on request under Article 30(4).

Records of Processing (Article 30): A Guide for IT Teams

The record of processing activities (often shortened to RoPA) is one of the least glamorous obligations in the GDPR and one of the most useful for a security team. Article 30 asks controllers and processors to keep a written inventory of what personal data they process, why, about whom, who receives it, where it goes and how it is protected. If that sounds like an asset inventory with a data protection lens, that is exactly what it is. Security and IT teams already own most of the raw material: the CMDB, the application catalogue, network and data flow diagrams, the vendor list and the control framework. This guide explains what Article 30 actually requires, how to build the record from existing IT sources, and how to keep it from going stale the week after the audit.

Why the record matters to security teams

The record is a compliance artefact, but it is also the map you need for almost every other GDPR obligation. When you run a DPIA, the record tells you which processing operations exist and which are new. When a breach occurs, it tells you within minutes which categories of data subjects and personal data sit in the affected system, which directly feeds the minimum content of an Article 33(3) notification. When a vendor is onboarded, it tells you which processing activities depend on that vendor and whether an international transfer is involved.

It is also the backbone of accountability. Article 5(2) makes the controller responsible for, and able to demonstrate, compliance with the principles. Article 30(4) requires the record to be made available to the supervisory authority on request. Failing to maintain it falls under Article 83(4), the fine tier of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher.

What Article 30 requires

Article 30 distinguishes two records: one for controllers and one for processors. Many organisations are both, for example a SaaS provider that is a controller for its own HR and customer billing data and a processor for the data its customers upload.

Controller record: Article 30(1)

Point	Required content	Typical IT source
(a)	Name and contact details of the controller and, where applicable, joint controller, representative and DPO	Legal entity register, DPO appointment
(b)	Purposes of the processing	Application owner, business process catalogue
(c)	Categories of data subjects and categories of personal data	Data model, database schema, data classification
(d)	Categories of recipients, including in third countries or international organisations	Integrations, API consumers, vendor list
(e)	Transfers to third countries, with identification and, for Article 49(1) second-subparagraph transfers, documentation of suitable safeguards	Hosting regions, vendor sub-processor lists
(f)	Where possible, envisaged time limits for erasure	Retention schedule, TTL and purge job configuration
(g)	Where possible, a general description of the Article 32(1) technical and organisational security measures	Control framework, security architecture

Processor record: Article 30(2)

A processor must record (a) the name and contact details of the processor or processors and of each controller on whose behalf it acts, plus representatives and the DPO where applicable; (b) the categories of processing carried out on behalf of each controller; (c) transfers to third countries; and (d) where possible, a general description of security measures. The processor record is usually driven by the customer contract base and the service catalogue, and it lines up closely with the clauses you already negotiate under Article 28 processor contracts.

Form and availability

Article 30(3) requires the record to be in writing, including in electronic form. Nothing mandates a spreadsheet. A structured file in version control, a module in a GRC tool or an extension of your CMDB are all acceptable, provided the content is complete and can be exported in a readable form when the supervisory authority asks for it under Article 30(4).

The 250-employee exemption, and why it rarely applies

Article 30(5) exempts organisations with fewer than 250 employees, but only if none of three conditions is met. The obligation still applies where the processing:

is likely to result in a risk to the rights and freedoms of data subjects;
is not occasional; or
includes special categories of data under Article 9(1) or personal data relating to criminal convictions and offences under Article 10.

In practice, payroll, HR files, customer accounts, CRM, email and security logging are all regular, continuous processing. They are not occasional, so even a small organisation needs a record covering them. Treat the exemption as narrow and document your reasoning if you rely on it.

Building the record from IT sources

The most common failure mode is a record written once by a consultant from interviews and never touched again. A more durable approach starts from systems the IT team already maintains.

Step 1: Define the unit of record

Article 30 speaks of processing activities, not systems. A single CRM may support several activities (sales prospecting, customer support, contract management), and a single activity (recruitment) may span an applicant tracking system, email and a shared drive. Agree with the data protection officer that the record is organised by activity, with each activity referencing the systems (CMDB configuration items) that support it.

Step 2: Seed from the CMDB and application catalogue

Export every business application and data store with its owner, hosting location and vendor. Flag those that hold personal data. For each flagged system, ask the owner which business activities it serves. This produces a first cross-reference of activities to systems.

Step 3: Derive data categories from schemas

Rather than asking business owners to list data fields from memory, inspect the schema or data dictionary. Classification tooling or a simple column-name scan can highlight identifiers, contact details, financial data, location data and anything that might be special category data under Article 9. Humans then validate the result.

Step 4: Use data flows for recipients and transfers

Integration inventories, API gateway configurations, egress firewall rules and the vendor register reveal recipients. Hosting regions and vendor sub-processor lists reveal transfers outside the EEA. Cross-check these with your international transfers inventory, because Article 30(1)(e) and the transfer tool analysis must tell the same story.

Step 5: Link retention and security measures

Point (f) should reference the actual retention rule enforced in the system, not an aspirational policy. Point (g) should reference the control set that applies, such as encryption at rest, MFA, logging and backup, ideally by control identifier so auditors can trace it to evidence.

Example RoPA entry as YAML

Keeping the record as structured data in a repository gives you review via pull requests, history for free and the ability to validate required fields automatically. The example below is illustrative; adapt fields and naming to your own organisation.

# ropa/activities/customer-support.yaml
id: PA-014
name: "Customer support ticketing"
role: controller                      # controller | processor | joint-controller
controller:
  entity: "Example Ltd"
  contact: "privacy@example.com"
  dpo: "dpo@example.com"
purposes:                              # Art. 30(1)(b)
  - "Handling customer support requests"
  - "Quality monitoring of support responses"
data_subjects:                         # Art. 30(1)(c)
  - customers
  - prospects
data_categories:                       # Art. 30(1)(c)
  - identification: [name, customer_id]
  - contact: [email, phone]
  - content: [ticket_body, attachments]
special_categories: false              # Art. 9(1) check
recipients:                            # Art. 30(1)(d)
  - name: "Helpdesk SaaS vendor"
    type: processor
    contract_ref: "DPA-2025-031"
transfers:                             # Art. 30(1)(e)
  - country: "US"
    importer: "Helpdesk SaaS vendor (sub-processor)"
    mechanism: "SCC 2021/914 Module 2"
    tia_ref: "TIA-2025-009"
retention:                             # Art. 30(1)(f)
  rule: "Tickets deleted 24 months after closure"
  enforced_by: "helpdesk automation rule R-12"
security_measures:                     # Art. 30(1)(g)
  - "SSO with MFA (CTRL-IAM-03)"
  - "Encryption at rest by vendor (CTRL-CRY-01)"
  - "Admin audit logging to SIEM (CTRL-LOG-02)"
systems:
  - cmdb_ci: "APP-00231"
owner: "Head of Customer Support"
last_reviewed: "2026-09-01"

A small CI check can then fail a pull request when a mandatory field is empty, when a referenced CMDB item no longer exists, or when last_reviewed is older than your review interval.

Keeping the record current

A record that is accurate on the day of the audit and wrong six months later offers little protection. Build maintenance into processes that already run:

Change management. Add a question to the change or architecture review template: does this change introduce a new processing activity, a new data category, a new recipient or a new hosting region? If yes, the record must be updated before go-live.
Vendor onboarding. Procurement and security review of a new SaaS tool should create or update the relevant record entry, including transfers.
Decommissioning. When a system is retired, update the activities that referenced it and confirm the data has been deleted or migrated.
Periodic review. Have each activity owner confirm their entries at least annually, with the DPO tracking completion.
Incident feedback. After each incident, compare what you actually found in the affected system with what the record says. Discrepancies are findings.

Checklist

Each processing activity has an owner and at least one linked system.
All Article 30(1) points (a) to (g) are filled, or marked "not determined" with a reason for (f) and (g).
Processor activities list every controller and the categories of processing performed for each.
Transfers match the transfer inventory and contracts.
Retention entries reference an enforced technical rule.
The record can be exported in a readable format on request.

For a quick definition to share with colleagues, see the glossary entry on records of processing.

Scope of this guide

This article is technical guidance for security and IT teams on building and maintaining records of processing activities. It is not legal advice. Confirm the scope of your records, your role as controller or processor and any reliance on the Article 30(5) exemption with your DPO or legal counsel.