GDPR ROPA template: Article 30 Records of Processing (2026)

What a ROPA actually is

The Record of Processing Activities — ROPA, RoPA, "Article 30 register," "processing inventory" depending on whose handbook you're reading — is the single source of truth describing every processing activity your organisation performs on personal data. It is the document a supervisory authority will ask for first, before they ask you anything else. GDPR Art. 30(4) requires you to make it available to the supervisory authority on request, full stop.

It is not a data-flow diagram. It is not a system inventory. It is not your asset register. It is an activity-level description, written from the perspective of what you do with personal data and why, not from the perspective of which database holds what. Confusing those layers is the number-one reason ROPAs go stale: an asset register changes every week, a list of processing activities changes maybe twice a year.

Who has to keep one

Controllers — Art. 30(1)

Every organisation that determines the purposes and means of processing personal data is a controller for that processing. Art. 30(1) requires the controller to maintain a record containing at minimum:

• The name and contact details of the controller, the controller's representative (where applicable), the joint controller, and the DPO.
• The purposes of the processing.
• A description of the categories of data subjects and the categories of personal data.
• The categories of recipients to whom the personal data have been or will be disclosed, including recipients in third countries.
• Where applicable, transfers to a third country or international organisation, including the identification of that country and the documentation of suitable safeguards.
• Where possible, the envisaged time limits for erasure of the different categories of data.
• Where possible, a general description of the technical and organisational security measures referred to in Art. 32(1).

Processors — Art. 30(2)

If you process personal data on behalf of a controller — you are a SaaS vendor, a payroll bureau, an analytics provider — Art. 30(2) applies. The processor ROPA is narrower: name and contact details of the processor, each controller on whose behalf you act, the categories of processing carried out on behalf of each controller, transfers to third countries with safeguards, and a general description of security measures.

A processor ROPA is structured per-controller, not per-activity. If you have 800 SMB customers, you don't write 800 entries; you write one entry for "customer accounts" and explain the categories of processing you perform on their behalf.

The SME exemption that doesn't really exist

Art. 30(5) says the obligations in 30(1) and 30(2) do not apply to organisations employing fewer than 250 persons. Read more carefully: that exemption is then immediately removed if any of the following are true:

• The processing is likely to result in a risk to the rights and freedoms of data subjects.
• The processing is not occasional.
• The processing includes special categories of data (Art. 9) or data relating to criminal convictions (Art. 10).

"Not occasional" is the killer. Any organisation that processes employee data on payroll, runs an email list, holds a customer database, or has a CRM is processing data on a non-occasional basis. The EDPB's Position Paper on Article 30(5) from 2018 made this explicit: the carve-out applies to processing that is "genuinely occasional" — one-off events. In practice, every company that hires anyone has to keep a ROPA. Treat 30(5) as not existing for production privacy programmes.

The six columns we actually recommend tracking

The Article 30 fields are the legal floor. To run a useful ROPA — one that survives a DSAR, feeds a DPIA, and answers transfer-mapping questions — we recommend six working columns plus metadata:

Add three metadata fields to every row: Owner (the person who maintains accuracy), Last reviewed (date), and Linked DPIA (pointer to the assessment, if any). A row without an owner rots within a quarter.

A copy-pasteable Markdown template

For teams that want to start in a spreadsheet or markdown file before moving into a tool, this is the structure we use in workshops:

| Activity | Purpose & legal basis | Data subjects | Data categories | Recipients / sub-processors | Transfers | Retention | Owner | Last reviewed | Linked DPIA |
|----------|------------------------|---------------|-----------------|------------------------------|-----------|-----------|-------|---------------|-------------|
|          |                        |               |                 |                              |           |           |       |               |             |

The point of putting it in markdown first is that you can fit it on one screen and force yourself to be terse. ROPAs written in 80-column tables are read; ROPAs written in 600-column spreadsheets are not.

Worked example: a B2B SaaS company

Here are two real entries from a ROPA for a hypothetical 80-person SaaS company that sells a workflow product to mid-market customers.

Entry 1 — Customer account management

• Activity: Customer account management — provisioning, billing, support, in-product use.
• Purpose & legal basis: Provision of the contracted service. Legal basis: Art. 6(1)(b) performance of contract for the account holder; Art. 6(1)(f) legitimate interests of the customer organisation for end-user telemetry, with balancing test on file.
• Data subjects: Customer account holders (admin contacts) and their end users (employees of the customer organisation).
• Data categories: Identifiers (name, email), billing (company name, VAT, payment last4 via Stripe), content (documents uploaded), telemetry (page views, feature use), support content (ticket bodies).
• Recipients / sub-processors: Internal support & engineering. Sub-processors: AWS (hosting), Stripe (billing), Postmark (transactional email), Plausible (analytics).
• Transfers: Primary processing in EU (Frankfurt). Support tooling reachable from US offices: SCCs Module 2 plus TIA on file. Stripe transfers under SCCs Module 4.
• Retention: Active for the lifetime of the account. 90 days after account closure all customer content is hard-deleted; billing records retained 10 years under local tax law (Art. 6(1)(c)).
• Owner: VP Engineering. Last reviewed: 2026-04-12. Linked DPIA: DPIA-2025-04 (customer telemetry).

Entry 2 — Marketing email list

• Activity: Outbound marketing — product updates, monthly newsletter, event invitations.
• Purpose & legal basis: Direct marketing to prospects and customers. Legal basis: opt-in consent (Art. 6(1)(a)) for EEA prospects; legitimate interest with soft opt-in for existing customers; PECR/ePrivacy compliance separately documented.
• Data subjects: Prospects who have signed up; existing customer contacts.
• Data categories: Name, business email, employer, opt-in source & timestamp, engagement events (opens, clicks).
• Recipients / sub-processors: Marketing team. Sub-processors: HubSpot (CRM & sender), Postmark (transactional).
• Transfers: HubSpot processing in US under SCCs + TIA. Risk assessed low because no special category data.
• Retention: Unsubscribed contacts: 30-day cool-down then suppression-only retention (hash). Inactive (no engagement) contacts: archived at 24 months, deleted at 36 months.
• Owner: Head of Marketing. Last reviewed: 2026-05-20. Linked DPIA: none required (low-risk processing).

How the ROPA connects to everything else

To DPIAs (Art. 35)

Each ROPA entry should declare whether a DPIA is required and link to the live assessment. New ROPA entries are the natural trigger for DPIA screening — if a row appears that involves new technology, profiling, or special categories of data at scale, screening should be automatic. The connection runs both ways: when a DPIA is closed, the residual controls and retention should flow back into the corresponding ROPA row. For the difference between DPIA and PIA artefacts, see DPIA vs PIA and the working DPIA template.

To DSARs (Art. 15)

The ROPA is what makes DSARs (and CCPA-style access requests) survivable at scale. When a request lands, you query your ROPA by data subject category to find every activity that might hold the requester's data, then route the actual data-pull to the system owners. Without a ROPA, every DSAR starts with a panic email to engineering. See our CCPA deletion request checklist and DSAR deadline calculator for the request-side timelines.

To transfer mapping (Chapter V)

Schrems II made transfer mapping a board-level concern. The transfers column in your ROPA is where the supervisory authority will start, and where you'll start when an adequacy decision moves. For the practical view of where the product processes data, see the jurisdictions section of our trust architecture page.

To breach response (Art. 33)

72 hours to notify is not a lot of time. The ROPA tells your incident response team which activities, data subjects, and sub-processors are within scope of a given incident — without it, the breach team is reconstructing the world while the clock runs.

The mistakes that turn a ROPA into shelfware

Modelling at the system level

The most common failure mode. Someone writes a row called "Postgres database" or "Salesforce" and lists every field. That is an asset register, not a record of processing activities. Activities are verbs — "support ticketing", "payroll", "outbound marketing." Systems are nouns and they appear in the recipients column.

One owner for everything

If "Data Protection Officer" owns all 47 rows, the document is dead. Each row needs an owner inside the business function that runs the activity. The DPO owns the register; the activity owners own the rows.

Retention as "as long as necessary"

That phrase is not a retention period. Replace it with a number, a triggering event, or a documented rule (e.g., "deleted 90 days after account closure" or "retained until end of statutory tax retention period, currently 10 years"). Vague retention is the single most common finding in supervisory authority audits.

No review cadence

A ROPA without a review schedule is the same shape as a ROPA you started in 2019 and last touched in 2020. Quarterly reviews per row, with a calendar reminder to the owner, is the lowest sustainable cadence.

Treating it as a private document

Art. 30(4) requires you to make it available to the supervisory authority. That means it has to be in a state you'd be willing to hand over today, not "after we clean it up." Write every row as if a regulator would read it tomorrow.

Living vs dead ROPAs

The difference between a living ROPA and a dead one is mostly cultural. A living ROPA is wired into how the organisation changes: every new vendor goes through a flow that updates a ROPA row; every new feature triggers a ROPA review before launch; every personnel change reassigns row ownership. A dead ROPA is a spreadsheet that gets opened twice a year, panic-edited the week before an audit, and forgotten again.

The mechanism that converts dead to living is automation. Privacy Automated keeps the ROPA in lockstep with your DPIAs, your sub-processor list, and your transfer mapping — when one changes, the others surface the change. See the features overview for how the connected register works in practice.

A starter ROPA outline you can paste into a doc

If you don't have a ROPA today, start here, then iterate. Most SaaS companies finish their first usable draft in two afternoons:

1. Organisation header — controller name, registered address, representative (if non-EU), DPO contact, supervisory authority of reference.
2. Activity index — one-line names for every processing activity. Aim for 15–40 entries for a typical mid-market business; if you have 200, you've modelled systems.
3. Per-activity rows — the six columns above, owner, last reviewed, linked DPIA.
4. Cross-border transfers register — one row per destination country with the mechanism and the TIA reference, derived automatically from the activity rows.
5. Special category processing register — the subset of activities involving Art. 9 data, with the lawful condition for processing on file.
6. Review log — a dated audit trail of changes to the register. Helpful for showing supervisory authorities that the register is alive.

FAQ — the questions auditors actually ask

Does our ROPA have to be in a particular format?

No. Article 30 specifies content, not format. Spreadsheet, markdown, dedicated tool — the only formal requirement is that it must be in writing, including electronic form, and provided on request (Art. 30(3) and Art. 30(4)).

Do processors really have to keep one too?

Yes. Art. 30(2) is a separate, mandatory obligation on processors. The processor ROPA is the artefact your customers' auditors will inspect during vendor due diligence; it doubles as your evidence that your sub-processor list and DPAs are coherent.

How granular should activities be?

Coarse enough that 15–40 entries cover the whole business. If "customer support" splits naturally into "Tier 1 ticketing," "incident response," and "outbound CSAT surveys" because they have different legal bases, recipients, or retention, split them. Otherwise don't.

Do we need a separate ROPA per legal entity?

If the entities are separate controllers, yes — each controller has its own Art. 30 obligation. You can keep them in one document with a column for legal entity, but the underlying records have to be controller-specific.

Related reading

• DPIA vs PIA: what's the difference?
• CCPA deletion request checklist
• Working DPIA template
• DSAR deadline calculator