The RoPA gap: what the DPC actually wants under Article 30, and where most organisations fall short

The Data Protection Commission has known for years that most organisations do not have a defensible Record of Processing Activities. In early 2022 the DPC carried out a “sweep” of 30 organisations, public and private, small and large. It asked each to hand over its RoPA. The findings landed in the DPC’s April 2023 guidance note, and the pattern is uncomfortable. Some organisations could not produce anything within the ten-day window. Some sent DPIAs and hoped they would count. Some sent something that used the word “personal data” as a category of personal data. One referred to Privacy Shield, which has not been a valid transfer mechanism since July 2020.

This piece walks through what Article 30 actually requires, what the DPC found in the sweep, and what a defensible RoPA looks like in practice. If you have never built one, or you built one before your last three product launches, this is for you.

Key takeaways

• Article 30 is not optional for most organisations. The under-250-employee exemption is narrower than most SMEs realise, and rarely applies to HR, payroll, or anything involving special category data.
• The DPC’s 2022 sweep found consistent failures: no RoPA at all, RoPAs assembled at the last minute, RoPAs listing “personal data” as a category of personal data.
• The RoPA must be a standalone, self-explanatory document. You cannot substitute a DPIA, a data protection policy, or a set of hyperlinks the DPC cannot access.
• The DPC gives you ten days to produce it on request. Assembling it during those ten days is not maintenance; it is scrambling.
• Broken down by business function, kept as a living document, and reviewed with each new processing activity, the RoPA becomes useful. Left as a compliance artefact, it becomes a liability.

What Article 30 actually requires

Article 30 of the GDPR asks every organisation acting as a data controller to maintain a written record of the personal data it processes. If you act as a processor for someone else’s data (for example, running a SaaS product for a client), you have a separate but similar obligation under Article 30(2). This piece focuses on the controller obligation, which is where most organisations sit.

For each processing activity, the record must contain:

1. Your name and contact details, and those of any joint controller, representative, or DPO
2. The purpose of the processing
3. The categories of data subjects (employees, customers, job applicants) and the categories of personal data (name, PPSN, bank details, health data)
4. The categories of recipients the data goes to (Revenue, an external payroll provider, an IT services vendor)
5. Any transfers of data outside the EEA, with the specific safeguards used
6. Where possible, the retention period for each category of data
7. Where possible, a general description of the technical and organisational security measures in place

The RoPA must be maintained in writing (electronic is fine, and probably better), and must be made available to the DPC on request. That is what Article 30 formally says. What “granular enough” and “self-explanatory” mean in practice comes from the DPC’s guidance and its enforcement pattern.

The SME exemption trap

Article 30(5) provides a derogation for organisations with fewer than 250 employees. Many small businesses read this and stop.

The exemption does not apply if any of the following is true:

• The processing is not occasional (HR and payroll processing for your own staff is not occasional; it is continuous)
• The processing includes special category data (Article 9): health, biometric, trade union membership, religious belief, criminal records, and similar
• The processing is likely to result in a risk to the rights and freedoms of data subjects

Almost every small business processes HR data on staff continuously. That alone triggers the obligation for that processing. If you also handle sick certificates (health data), you have crossed the special-category threshold. If you use AI in hiring, marketing, or decision-making, the DPC’s guidance explicitly names AI as an example of processing that triggers the obligation.

The practical position is that almost no organisation is actually exempt from Article 30 across its full activity set. A more accurate reading is that some processing activities may not need to appear in the RoPA. The organisation still needs a RoPA for the activities that do.

What the DPC found in the 2022 sweep

The DPC selected 30 organisations and asked each to hand over its RoPA within ten days. The findings map directly to the “Don’ts” in its later guidance.

Some organisations could not produce anything within ten days. The RoPA is meant to be a living document, ready to hand over on request. If assembling it takes weeks, it is not being maintained.

Some organisations substituted the wrong document. One organisation submitted several DPIAs and argued they counted as a RoPA. The DPC rejected this. A DPIA assesses risk for a specific high-risk processing activity. A RoPA maps all processing activities, most of which do not require a DPIA at all. The two documents overlap in some fields but are not interchangeable.

Some RoPAs used categories so broad they conveyed nothing. In the “categories of personal data” column, organisations wrote “personal data,” “personally identifiable information,” or “responses to questions.” The DPC’s response was direct: these responses are “unequivocally not sufficient.” The RoPA is meant to help a supervisory authority understand what data you actually hold. “Personal data” tells the DPC precisely what it already knows.

Some RoPAs were not self-explanatory. Organisations hyperlinked out to retention schedules, security policies, and internal governance documents. When the DPC tried to open the links, they resolved to intranet locations the DPC could not access. Others stated “in accordance with the retention policy” without saying what the policy actually specified. Recital 82 of the GDPR is explicit: the record must be available to the supervisory authority in a way that lets it monitor operations. A trail of broken links does not qualify.

Some RoPAs referred to obsolete legal mechanisms. At least one organisation was still citing Privacy Shield as its US transfer safeguard. Privacy Shield was invalidated in July 2020 by Schrems II. Its successor, the EU-US Data Privacy Framework, has been the operative mechanism since July 2023. A RoPA that cites Privacy Shield is not just outdated; it is a signal that the document has not been touched in years.

What granular actually means

The DPC’s example templates make the expectation concrete. A defensible RoPA does not say:

• “HR” as a purpose. It says: “Payroll processing,” “Personal file management,” “Recruitment,” each as a separate entry.
• “Staff” as a category of data subject when you actually mean staff, contractors, interns, and joiners as distinct groups.
• “Personal data” as a category of personal data. It lists specifically: name, staff number, PPSN, bank details, sick leave records, performance review notes.
• “Password protected system” as the entire security measure when in fact you also have encryption at rest, MFA on the admin interface, access limited to named individuals, and quarterly access reviews.
• “As per retention policy” as the retention period. It lists the actual number of years, and where possible the statute that fixes it (for example, seven years for financial records).

The DPC’s Approach A and Approach B templates in its guidance both meet these expectations. Approach C, provided in the appendix as an example of insufficient detail, is roughly what a lot of organisations submit and mistake for compliance.

Building buy-in beyond the DPO

The DPC’s clearer message from the sweep is that RoPAs owned solely by the DPO tend to be incomplete. The DPO cannot know every processing activity every function has stood up, and if the DPO is the only one asking the questions once a year, activities added between reviews fall through the cracks.

The pattern the DPC recommends is:

• The DPO leads and centrally maintains the RoPA
• Each business function (HR, finance, marketing, IT, product) has a named process owner for its section
• New processing activities are flagged for RoPA inclusion at the point they go live, not at the next audit
• The full RoPA is reviewed at a scheduled cadence, ideally outside peak business periods

This is largely the same discipline that a mature ISMS applies to its asset register or its risk register: distributed authorship, central curation, continuous update.

The ten-day rule and what it means

The DPC’s practical position is that ten days is a reasonable notice period. If your RoPA is not available within ten days, it is not being maintained.

Failure to produce it in that window has consequences beyond embarrassment. The DPC’s guidance says explicitly that failure to have the documentation to hand “could be considered as non-compliance with the GDPR.” Sending templates, samples, or a subset does not satisfy the obligation. It is the actual maintained record that must be handed over.

For organisations preparing for a DPC audit, a breach notification review, or a complaint investigation, the ten-day standard is the effective test. If a request landed today, could you produce the current, complete RoPA by Friday next week? If the answer requires “let me pull together what I can,” the answer is no.

How this connects to broader compliance

For ISO 27001 programmes, the RoPA aligns with the asset register requirement and with accountability obligations under Clause 5.3. For ISO 27701 (Privacy Information Management), the RoPA is a required input under Clause 5.2.1 and the associated Annex A controls.

For NIS2, Article 21 does not explicitly reference a RoPA, but the “risk analysis and information system security policies” measure implicitly assumes an accurate inventory of what personal data is processed and where.

Under the EU AI Act, Article 26 obligations on deployers of high-risk AI systems require maintaining logs and appropriate records. Organisations with a mature RoPA discipline are already halfway there. Organisations without one face two overlapping documentation obligations they cannot satisfy from scratch under regulatory scrutiny.

Getting started for smaller organisations

If you are a small business without a formal RoPA, the practical starting point is a spreadsheet. Take each business function and list its processing activities: HR, payroll, marketing, customer support, IT administration. For each activity, complete the seven Article 30 fields. Use the DPC’s Approach A or Approach B templates as your structure. Save the file somewhere your DPO or data protection lead maintains, and put a review date in the calendar for six months out.

This is not a project; it is a habit. The RoPA that gets built and never touched again is the one that fails ten days after the DPC asks for it.

Closing

Records of Processing Activities is an administrative obligation that looks trivial from the outside. In practice it is where the DPC’s assessment of an organisation’s data protection maturity begins. A weak RoPA is prima facie evidence of weak controls, weak accountability, and weak awareness. A strong RoPA does not guarantee compliance elsewhere, but it does put an organisation in a much better position when a breach, a complaint, or a scheduled review lands.

The DPC has been explicit that further sweeps are likely, and that the RoPA may be requested during breach notification, complaint, or investigation work. The time to build one that would survive the ten-day test is now, not when the request arrives.

For support building or reviewing your RoPA, or for a wider GDPR programme review, get in touch.