What is a Record of Processing Activities (RoPA)?

A record of processing activities (RoPA) is a written inventory of how an organization handles personal data, as required by Article 30 of the GDPR. While it is kept within the organization, it is not completely private. The supervisory authority can request it, and the organization must produce it.

This page is for DPOs, privacy counsels, or operations leads who are responsible for privacy. It ends with a key question that templates cannot answer: does your record reflect what your organization actually does?

What is a record of processing activities (RoPA)?

A record of processing activities is the written inventory of personal data processing that Article 30 of the GDPR requires. 

The requirement has two parts.

• Under Article 30(1), every controller maintains a record of the processing carried out under its responsibility. 
• Under Article 30(2), every processor maintains a record of the categories of processing it carries out on behalf of controllers. 

If an organization acts as both a controller and a processor, it must keep both types of records.

“Processing” means any operation on personal data, automated or not. It runs from collection and storage through use and disclosure to erasure (Article 4(2)). The record’s subject is everything the organization does with personal data. It is not a list of IT systems.

The GDPR’s accountability principle (Article 5(2)) requires controllers to be able to demonstrate GDPR compliance, not just achieve it. Recital 82 explains: “In order to demonstrate compliance with this Regulation, the controller or processor should maintain records of processing activities under its responsibility.” The RoPA serves as this proof and should be ready before anyone requests it.

For each processing activity, the controller’s record answers a fixed set of questions:

• who is responsible (the controller, and where applicable any joint controller, representative, and data protection officer)
• why the personal data is processed
• whose data it is, and what kinds of data
• who receives it
• whether it is transferred outside the EU, and under what safeguards
• how long it is kept
• how it is protected

The record is the main place where all processing activities are fully documented. Other compliance tasks rely on this record, including:

• privacy notices, whose required content overlaps heavily with what the record holds
• DPIA screening, since deciding which activities need an impact assessment starts from knowing what you do
• retention decisions, which the record stores as time limits per category of data
• access requests, which are answerable only if you know what data is held and where
• audits and authority requests: the record is what the supervisory authority can demand on request (Article 30(4))

The RoPA is an internal document. It is not published and is different from the privacy notice. Only the supervisory authority has the right to request it. “RoPA” is a common abbreviation, sometimes called “register of processing activities,” but the law uses “record of processing activities.”

Who needs to keep a RoPA under GDPR?

By default, the duty covers everyone in scope of the GDPR. Article 30(1) puts the duty on every controller, Article 30(2) on every processor. Both paragraphs include the organization’s representative where applicable. (A controller decides why and how personal data is processed; a processor processes it on a controller’s behalf.)

There is one exception for organizations with fewer than 250 employees. However, this exception is limited in law and even more so in practice. That puts most companies in scope: if your organization handles payroll or keeps customer records, you should assume the duty applies to you.

Does the under-250-employees exemption apply?

Rarely, and never by default. Article 30(5) reads in full:

“The obligations referred to in paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10.”

Each condition alone cancels the exemption. The WP29 position paper on the Article 30(5) derogations (April 2018, endorsed by the EDPB on 25 May 2018) reads the three as alternatives: “the occurrence of any one of them alone triggers the obligation to maintain the record of processing activities.”

The trigger is risk, not high risk: organizations “carrying out processing likely to result in a risk (not just a high risk) to the rights of the data subjects” must keep the record.

The paper reads “occasional” narrowly: “a processing activity can only be considered as ‘occasional’ if it is not carried out regularly, and occurs outside the regular course of business or activity of the controller or processor.”

This test is applied to each activity. For example, if a small organization regularly processes employee data, this is not considered ‘occasional’ and must be included in the record of processing activities.

The ICO’s worked example lands the same way. An insurance company with 100 staff must document its regular claims, sales, and HR processing. Its one-off staff engagement survey escapes because “the company doesn’t do this particular processing activity very often, so it need not document it as part of its record of processing activities.” CNIL reads it alike: “salary management, customer management/prospect and supplier” are non-occasional.

The ICO also recommends:

“Even if you need not document some or all of your processing activities, we think it is still good practice to do so.”

Does Article 30 apply outside the EU?

Yes, Article 3 of the GDPR covers organizations based in the EU and those outside the EU that offer goods or services to people in the EU or monitor their behavior. For example, a US company with EU customers must keep the record just like a French company.

The United Kingdom runs a mirror regime. The UK GDPR carries the same Article 30 duty and under-250 exemption, so the ICO guidance quoted here tracks the EU text almost word for word.

What happens if you don’t keep a record?

The fine tier is the lower of the GDPR’s two. It is still substantial. Article 30 sits inside Article 83(4)(a), which covers “the obligations of the controller and the processor pursuant to Articles 8, 11, 25 to 39 and 42 and 43”: infringements carry administrative fines of up to €10 million or, for an undertaking, up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher.

Under the UK mirror, the ICO’s Data Protection Fining Guidance sets the standard maximum amount at £8.7 million or 2% of the undertaking’s total worldwide annual turnover. Whichever is higher.

The actual fine depends on the specific case. Article 83(2) says authorities must consider several factors for each situation. In practice, the first step is usually a request to provide the record, not an immediate fine.

What information must a RoPA include?

A controller’s record must contain the seven items of Article 30(1) for every processing activity. A processor’s record must contain the four items of Article 30(2) for every category of processing carried out for a controller. The lists are fixed by the statute. 

The qualifiers attach to five fields in total. Retention time limits (30(1)(f)) and the security description (30(1)(g), 30(2)(d)) are “where possible.” Third-country transfers (30(1)(e), 30(2)(c)) are “where applicable.” Every other field is unconditional.

What must data controllers include in their record?

Field (a) sweeps in the joint controller, representative, and DPO, so the record also serves as a contact list. Field (e) is where international transfers are documented. The entry names the destination country and the transfer basis, such as an adequacy decision, and documents the safeguards.

Lawful basis is not in the list. Article 30(1) does not require the Article 6 legal basis for processing, but the Irish DPC recommends recording it: it heads the DPC’s list of “helpful extra information not explicitly listed in Article 30,” and organizations should “specifically state which information has been prescribed by Article 30, and which information has been included as a ‘helpful extra.'” The DPC’s worked example marks the columns “GREEN COLUMNS ARE MANDATORY / BLUE COLUMNS ARE AS APPLICABLE.”

What must data processors include in their record?

The four processor fields, per controller: 

1. who the processor and its controllers are
2. what categories of processing it performs for each
3. where the data goes outside the EU
4. how it is secured

Together they make the leaner register. It is the one a SaaS company actually produces when enterprise customers run due diligence.

A neighboring duty is routinely confused with the record: processor contract duties sit in Article 28, outside Article 30. Article 28(3)(h) requires the processor to make available “all information necessary to demonstrate compliance” and to “allow for and contribute to audits.” Related, but not the same document.

What counts as a processing activity?

The unit of record is the processing activity. It is drawn at the level of a purpose within a business function. “HR” is not an activity. “monthly payroll processing” is.

The ICO’s documentation guidance sets the test: “it is important that you do it in a granular and meaningful way,” and “a generic list of pieces of information with no meaningful links between them will not meet the UK GDPR’s documentation requirements.” Its method is broad to narrow. Start from a business function, identify the processing purposes within it, then link people, data, recipients, and retention rules to each purpose, row by row.

Ireland’s DPC prescribes the same structure: “RoPAs should be clearly broken down and detailed according to the different business units or functions within an organization, such as HR, finance or marketing,” with separate tables or spreadsheets per unit inside one overall record.

Example: one row of a controller’s record. (Illustrative, not a real organization’s entry.)

What do regulators say a bad entry looks like?

Two published tests define the bar. The ICO’s is the granularity test quoted above.

The Irish DPC’s is self-sufficiency: “In order to be fit for purpose, the RoPA provided to the DPC needs to be a complete, self-contained document clearly listing all information as required by Article 30. RoPAs must be self-explanatory.” The DPC backs it with the same granularity language as the ICO: “RoPAs should ensure to include granular and meaningful information,” going “into specific detail for each category of data subject, category of personal data or processing activity,” under the heading “Don’t cut corners with detail and granularity.”

The DPC’s 2022 sweep cataloged real submitted entries that fail those tests. All are quoted from the guidance:

One forward-looking warning, framed as advice rather than a finding: “RoPAs should not refer to out-of-date or expired information, for example referring to the Privacy Shield as the mechanism for the transfer of personal data to the US.”

A detailed payroll entry is only useful if all activities are listed. If marketing tools are left out, the record is incomplete. Ensuring completeness requires a thorough discovery process, as described in the build section.

Is a RoPA the same as a data inventory, a DPIA, or a privacy policy?

No. Each document serves a different purpose, is based on different legal requirements, and is meant for a different audience. None of them can replace the record required by Article 30.

The artifacts feed each other without merging.

• The inventory is the discovery input the record is built from.
• The record supplies much of the notice’s content and the screening input for impact assessments.
• Completed assessments are linked back from the record’s rows.

One recurring source of inventory gaps is the website: what your site actually sends to third parties is observable. But only if someone looks.

Three confusions cause the damage.

1. Notice as record. The privacy notice is the public statement. The record is internal, more detailed, and owed to the authority.
2. DPIA as record. It happened in the DPC’s sweep, and the answer was flat: “The RoPA is a standalone record.”
3. Record as one-off project. Keeping the record current is a separate discipline, the subject of the maintenance section.

Does a RoPA have to follow a specific format and where can you get a template?

There is no required format. Article 30(3) only says the record must be in writing, including electronic form. Regulators focus on the content and how up-to-date it is, not the tool you use.

France’s CNIL states the consequence directly: “Le RGPD impose uniquement que le registre se présente sous une forme écrite. Le format du registre est libre et peut être constitué au format papier ou électronique.” (The GDPR requires only that the record take written form. The format is free, paper or electronic.)

Is an Excel RoPA acceptable to regulators?

Yes, in the regulators’ own words. The ICO recommends an electronic form for most organizations “so they can easily add to, remove, and amend it as necessary,” while allowing that “paper documentation may be adequate for very small organizations whose processing activities rarely change.”

Embedding in existing record-keeping is also permitted. Every Article 30 documentation obligation must still be met. In the ICO’s words: 

“The UK GDPR does not prohibit you from combining and embedding the documentation of your processing activities with your existing record-keeping practices.”

The official starting points are all free.

• The ICO publishes a documentation template for controllers and a documentation template for processors (both Excel). Using them “is not mandatory”. The guidance is under review following the Data (Use and Access) Act, so re-check the downloads before relying on them.
• The CNIL’s base model register (ODS format) is “destiné à répondre aux besoins les plus courants,” aimed “en particulier des petites structures (TPE-PME, associations, petites collectivités, etc.)”: small businesses, associations, and small local authorities.
• The Irish DPC’s guidance closes with three worked layouts:
  • Approach A: a well-completed example marking mandatory versus as-applicable columns.
  • Approach B: the same, by business function, retention as “X years post employment.”
  • Approach C: the DPC’s fictitious school, showing what insufficient detail looks like.

Three practices help keep any template manageable:

• Give every activity a unique ID.
• Keep one row per activity so fields stay linked (the ICO’s granularity test).
• Label columns to mark which information Article 30 prescribes and which is a helpful extra (the DPC convention, above).

The DPC warns that submitting a template or sample is not enough. A template is just a starting point. The requirement applies to the actual record you maintain.

No template can guarantee detailed, up-to-date entries or help you find every activity. Achieving this requires a thorough build process.

How do you build a RoPA step by step?

Building a RoPA is evidence-gathering, not paperwork, in four phases: scope which records you owe, discover what the organization actually does, structure broad to narrow, then complete the fields and get sign-off. Monthly payroll processing recurs as the worked example.

1. Scope and assemble sources. Work out which records you owe: a controller’s record under Art. 30(1), a processor’s record under Art. 30(2) for anything done on behalf of other controllers. Before interviewing anyone, gather what already exists: privacy notices, IT asset lists, vendor registers, contracts, and legacy filings already contain entries in draft form (the payroll-provider contract alone names a recipient and a tool).
2. Discover: ask, read, observe. Facts for each entry come from three kinds of sources, detailed below.
3. Structure broad to narrow. The ICO’s method is to “start with the broadest piece of information about a particular processing activity, then gradually narrow the scope”. The Irish DPC’s guidance prescribes the same business-function breakdown, and the granularity test applies row by row.
4. Complete fields, assign owners, sign off. Fill every mandatory field per activity, name one business owner for each, DPO or privacy lead review the whole. The DPC recommends a DPO-led process with business areas feeding in.

Where does the information for a RoPA come from?

Discovery runs through three channels: what people tell you, what documents say, and what systems do. The CNIL’s build method matches. Gather available information. Build the list of processing activities one register sheet at a time.

Its first phase names all three: meet the operational leads, review the available documents, and, if the organization has a website, analyze it and identify the data collected in the online forms, along with the notices and cookies in use.

The ICO starts with the first two rows. Those are an information audit or data-mapping exercise, plus questionnaires and conversations with staff. Rows three and four read systems rather than people.

These sources differ in evidentiary strength. Interviews report belief, contracts record agreement, systems show what runs. Treating them as equal is how plausible-but-wrong entries get written. 

How do you keep a RoPA up to date?

Article 30 does not set a review schedule, but the record still has to be regularly updated to reflect changes in processing activities. The ICO advises treating the record as “a living document that you update as and when necessary,” with regular reviews to ensure it “remains accurate and up to date.”

How often should a RoPA be reviewed?

No EDPB or WP29 document prescribes a cadence. “Annual review” is a convention, not a legal requirement. Regulators say it should be change-driven. The record must always reflect the current situation, so specific events should trigger an update regardless of the calendar.

A workable trigger list:

• A new tool or vendor starts processing personal data
• The purpose of an existing activity changes
• A retention period or practice changes
• A transfer mechanism or destination country changes
• An organizational change (merger, new business unit, outsourced function) moves processing
• An incident or audit finding shows the record diverged from practice

No “14-day standard” exists for producing the record. When the DPC asked thirty organizations for their RoPAs, it advised that ten days should be sufficient notice “in all circumstances.”

Obsolete activities are not silently deleted: the DPC recommends processing no longer taking place be “marked as such or removed from the live RoPA,” with an archive kept for accountability purposes if removal is preferred.

Who should own the RoPA, and what does the data protection officer do?

The controller owns the record. The duty is a legal obligation under Article 30 and cannot be delegated away, but its upkeep still needs one designated person to maintain it, usually the DPO or privacy lead, with business owners feeding in. A workable internal split:

The DPC is explicit about the reason. Row two cannot absorb the whole job. Left to the DPO alone, the record risks missed activities and decay into a tick-box exercise. The recommendation: 

“The process can be led by the DPO with different areas of the organisation feeding into the process.”

A change log belongs with the record. When an authority or auditor asks how the document is maintained, the log is the answer. Ownership plus a review rhythm is the operating model a risk register runs on.

The record also acts as a central hub. Its entries link to related documents, such as data protection impact assessments, retention schedules, data subject access request procedures, and lists of sub-processors and other recipients.

The failure modes below are record-management failures. They are distinct from the entry-writing failures in the contents section. Each is tied to what a regulator actually said.

Who can request your RoPA, and what do they expect to see?

Only a supervisory authority, the national data protection authority, can compel your record. Article 30(4) states that the controller or processor “shall make the record available to the supervisory authority on request.”

Recital 82 explains why. The records exist so the authority can monitor the processing operations. Everyone else who asks is asking through a contract or for something they have no right to.

Do you have to send your RoPA to the regulator?

Yes, you must provide your RoPA if requested. Submitting a blank template or a sample is not enough: “providing the DPC with RoPA templates or a ‘sample’ of the RoPA is not sufficient, as the requirement under Article 30 is to make the actual RoPA maintained available to the supervisory authority on request.”

The DPC’s guidance adds that 

“failure to have such documentation to hand could be considered as non-compliance with the GDPR.”

Other audiences ask through different instruments.

The customer row is the question organizations actually face in practice. Can a customer compel the record itself? No statute gives the customer that right.

Article 28(3)(h) obliges a processor to make available to the controller “all information necessary to demonstrate compliance with the obligations laid down in this Article” and to “allow for and contribute to audits, including inspections”. It is a duty related to the register, but nothing in it entitles the customer to the full document. The practical answer is an extract or summary of the relevant entries under NDA for customers. The supervisory authority gets the full record.

No matter who asks, a good record should be detailed, clear, and up to date. These are the standards regulators and other requesters use, whether required by law or contract.

The record is usually the first artifact an authority asks for, so its absence converts a routine inquiry into an accountability finding on the spot. A stale record does quieter damage. Downstream documents built on wrong entries inherit the error.

The main risk is not the potential fines, but the requirement to provide the record when asked. ICO audits often highlight Article 30 non-compliance as urgent issues. In reality, you may have only ten days to respond, so it is important to have an accurate record ready.

How do you know your RoPA matches what your organization actually does?

You should check your RoPA against evidence that was not used to create it. The build process starts with what people report in interviews, questionnaires, and workshops, but actual processing is what systems do. Verification means comparing these sources, field by field.

Why do RoPAs go stale even when people mean well?

Drift happens naturally. A static spreadsheet is a legitimate format, but it only changes when someone edits it, while processing changes whenever a team ships something new:

• Shadow SaaS. A team adopts a tool outside procurement. No entry ever appears.
• Vendor and sub-processor swaps. The named processor quietly changes its downstream chain. The recipients column keeps describing the old one.
• Tag-manager and website changes. Marketing ships a new tag on Tuesday. The record still describes last quarter’s site.

No regulator prescribes a method for checking the record against reality. The DPC says records should not refer to out-of-date information, but not how to catch drift before an authority does. The following re-check loop helps fill this gap by pairing each field with an evidence source that can contradict it, and a drift signal that flags decay.

The loop feeds maintenance. A drift signal is an update trigger, and each resolved trigger re-enters the change log. The loop works best when the sources raise the signal themselves: connect procurement, SSO, and the tag manager so that a new vendor, a new app, or a new tag generates a change notification to the record owner, and the update does not wait for the next review. For recipient chains, the same stated-versus-observed logic extends one level down into sub-processor and fourth-party territory.

What can you check on your own website?

The website row is the entry most likely to be wrong and the most directly observable. It is the natural place to start. The record should state which third parties receive data, for what purposes, and with what safeguards. You can use your browser to see which requests are actually sent, to which domains, with what data, and under what consent state.

For example, your record might say the marketing site shares data with two analytics providers. However, checking in the browser could reveal four tags firing, one before any consent is given, and one sending data to a country not listed in your record. You can spot these issues without needing to interview anyone.

There is a limit to what you can observe in the browser. While you can see what happens on the website, internal systems and server-side processes require different types of evidence. That is why the table uses both observable and document-based checks.

How can you check which third parties your website actually sends data to?

Every third-party data flow from a website is directly observable: a request the visitor’s browser sends to a destination you can name. Regulators publish free tools for the job themselves. The EDPS Website Evidence Collector, open source under the EUPL-1.2 license, “collects evidence of personal data processing, such as cookies, or requests to third parties.” The EDPB’s website auditing tool can import Website Evidence Collector output. Our web tracking guide has the full manual method. 

MELURNA runs this observation continuously. Rather than a one-off scan, it monitors sensitive data flows across websites, applications, and customer journeys over time. It surfaces hidden vendors, AI services, downstream recipients, and changes. For RoPA work, the mapping runs field by field. Observed recipients inform the recipients column, observed destination countries the transfers column, and observed tags and form fields the data-categories column. 

Request an analysis →

FAQs

DISCLAIMER: This guide is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information, and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.