If there is one GDPR obligation that organisations consistently underestimate, it is the requirement to maintain Records of Processing Activities. Article 30 of the GDPR requires controllers and processors to keep a written record of the personal data processing they carry out. It sounds administrative. It is often treated as a box-ticking exercise. And yet, when a data protection authority comes knocking — or when a data breach occurs, a data subject exercises their rights, or a due diligence process begins — the RoPA is almost always the first document they ask for.
The reason is simple: your RoPA is the map of your data processing. Without it, you cannot demonstrate compliance with any other GDPR obligation. You cannot show that you have a legal basis for each processing activity if you have not documented what those activities are. You cannot conduct a meaningful Data Protection Impact Assessment if you do not know which processing operations involve high risks. You cannot respond accurately to a data subject access request if you do not know where their data sits and what you do with it.
A well-maintained RoPA is not just a compliance document. It is the foundation on which everything else in your data protection programme is built.
The short answer: almost every organisation.
Article 30(5) of the GDPR provides a narrow exemption for organisations with fewer than 250 employees, but that exemption disappears the moment any of the following apply: the processing 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 or data relating to criminal convictions. In practice, this means the exemption almost never applies. Any organisation that processes employee data on a regular basis — which is every employer — falls outside the exemption.
The Belgian Data Protection Authority (GBA/APD) has made this point explicitly in its guidance: the 250-employee threshold is not a safe harbour. If you process personal data regularly, you need a RoPA.
If you act as both a controller and a processor — for example, if you provide services that involve processing personal data on behalf of clients while also processing your own employees' and customers' data — you need to maintain separate records for each role.
Article 30(1) sets out the mandatory contents for controllers. For each processing activity, you must document the following.
The name and contact details of the controller — and, where applicable, the joint controller, the controller’s representative, and the Data Protection Officer. For group structures, clarify which entity is the controller for each activity.
The purposes of the processing. This must be specific. “Business purposes” or “internal use” is not sufficient. Each processing activity should have a clearly articulated purpose — for example, “payroll administration”, “customer relationship management”, “website analytics”, or “recruitment and selection”.
A description of the categories of data subjects and categories of personal data. Who are you processing data about (employees, customers, website visitors, suppliers, job applicants) and what data do you hold about them (identification data, contact details, financial data, location data, online identifiers, health data)?
The categories of recipients. Who receives the data — both internal departments and external parties? This includes processors (your payroll provider, your cloud hosting service, your email marketing platform), other controllers you share data with, and any public authorities that receive data.
Transfers to third countries or international organisations. If personal data leaves the European Economic Area, you must document the destination country, the transfer mechanism (adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, or a derogation), and any supplementary measures applied.
Time limits for erasure. For each category of data, what is your intended retention period? Where you cannot specify an exact period, you must document the criteria used to determine it — for example, “duration of the employment relationship plus 5 years” or “7 years after the last invoice for tax compliance”.
A general description of technical and organisational security measures. This does not require a full security audit, but it should describe the measures in place at a level sufficient to demonstrate that you have considered data security — encryption, access controls, pseudonymisation, backup procedures, and the like.
If you process personal data on behalf of another organisation, Article 30(2) requires a separate set of records. The processor’s RoPA must include the name and contact details of the processor and each controller on whose behalf you process data, the categories of processing carried out on behalf of each controller, details of any transfers to third countries, and a general description of security measures.
Processors do not need to document purposes or legal bases — that is the controller’s responsibility. But they must be able to show what they do with the data and how they protect it.
The Article 30 requirements are a floor, not a ceiling. Organisations that treat their RoPA purely as a legal checklist miss the opportunity to turn it into a genuinely useful management tool. In practice, the most effective RoPAs also document the following.
The legal basis for each processing activity. Article 30 does not explicitly require this, but documenting it alongside each activity makes it far easier to respond to data subject requests, conduct DPIAs, and demonstrate compliance during audits. For each activity, record whether you rely on consent, contractual necessity, legal obligation, vital interests, public interest, or legitimate interests — and for legitimate interests, document the balancing test.
The source of the data. Was the data collected directly from the data subject, or obtained from a third party? If the latter, from whom?
Whether automated decision-making or profiling is involved. If so, document the logic, significance, and consequences for the data subject.
Links to related documentation. Connect each processing activity to the relevant data processing agreement, privacy notice, DPIA (if applicable), and retention schedule. This turns the RoPA into a navigation tool for your entire data protection programme.
The department or business function responsible. Assigning ownership to a specific team or process owner makes it easier to keep the RoPA current and ensures accountability.
The date of last review. RoPAs are living documents. Recording when each entry was last reviewed — and by whom — demonstrates that you are maintaining the records actively rather than creating them once and forgetting about them.
Having reviewed RoPAs across organisations of all sizes, the same problems appear repeatedly.
Too generic. Entries like “HR data processing” or “customer data management” are too broad to be useful. Each distinct processing activity should have its own entry. Payroll, recruitment, absence management, and performance reviews are separate activities with different purposes, legal bases, recipients, and retention periods. Lumping them together defeats the purpose of the record.
Out of date. A RoPA created two years ago and never updated is worse than no RoPA at all — it gives a false picture of your processing. New systems are adopted, vendors change, new data categories are collected, and retention practices evolve. If the RoPA does not reflect current reality, it cannot serve as a compliance tool.
Missing the processor perspective. Organisations that act as both controller and processor frequently maintain only a controller’s RoPA and forget the processor records entirely. If you provide services that involve handling personal data on behalf of clients, you need a separate processor RoPA.
No retention periods. The retention field is often left blank or filled with “as long as necessary”. This is insufficient. Each processing activity must have a defined retention period or clear criteria for determining one. “As long as necessary” is not a retention policy — it is the absence of one.
Forgetting website processing. Cookies, analytics tools, advertising pixels, session recording software, and chatbots all process personal data. Many organisations document their internal business processes meticulously but overlook the processing that happens on their own website. A technology audit of your digital properties will often reveal processing activities that are absent from the RoPA — and absent from your privacy notice.
No security measures described. The requirement is for a “general description”, not a detailed security policy, but leaving this field empty suggests that security has not been considered at all.
There is no prescribed format for a RoPA. The GDPR requires it to be in writing, which includes electronic form. In practice, organisations use spreadsheets, dedicated compliance tools, or integrated systems that maintain the records as part of a broader compliance programme.
Whatever the format, the structure should make it easy to find, review, and update individual entries. A practical approach is to organise processing activities by business function or department — HR, finance, sales and marketing, IT, legal — with each activity as a separate row or record containing all the Article 30 fields plus any additional fields you have chosen to include.
For organisations with multiple legal entities, maintain separate records per entity (since each entity is a separate controller), but use a consistent structure across the group so that records can be compared and consolidated when needed.
The biggest challenge with RoPAs is not creating them — it is keeping them up to date. A RoPA that accurately reflects your processing at the time of creation will drift out of date within months unless you build maintenance into your operational processes.
Effective approaches include assigning a process owner for each entry who is responsible for flagging changes, scheduling periodic reviews (quarterly is a reasonable cadence for most organisations), integrating RoPA updates into your change management processes so that new systems, vendors, or data flows trigger a review, and including RoPA verification in your internal audit programme.
For organisations using technology to manage their data protection compliance, automated flagging of changes — such as new technologies detected on your website, new data processing agreements signed, or new categories of data collected — can significantly reduce the effort required to keep records current.
The value of a well-maintained RoPA becomes most apparent in specific situations.
Data protection authority inspections. When the Belgian GBA/APD or any other supervisory authority initiates an investigation or audit, the RoPA is typically the first document requested. A complete, current RoPA demonstrates that you take compliance seriously and gives the authority confidence that you understand your own processing. An absent or outdated RoPA raises immediate concerns.
Data breaches. When a breach occurs, you need to assess its impact quickly — which data subjects are affected, what data was compromised, who has access, and what the consequences might be. If your RoPA accurately maps your processing activities, these questions can be answered in minutes rather than days.
Data subject requests. When someone exercises their right of access, erasure, or portability, you need to know where their data is and what you do with it. The RoPA tells you exactly that.
Due diligence. In M&A transactions, the buyer’s advisors will ask for your RoPA as part of data protection due diligence. A well-structured RoPA signals compliance maturity. Its absence signals risk.
DPIA triggers. Your RoPA helps you identify which processing activities are likely to require a Data Protection Impact Assessment — high-risk processing, large-scale processing of special categories, systematic monitoring of public areas, and so on.
At Pitch, we help organisations build, review, and maintain their Records of Processing Activities as part of our broader data protection practice. Our approach is practical rather than theoretical — we work with your teams to identify every processing activity, document the required information, and establish processes to keep the records current.
Where your processing involves technology — websites, SaaS platforms, marketing tools, analytics — our domain monitoring capabilities can automatically detect privacy-relevant technologies and flag processing activities that may be missing from your records. This closes the gap between what your documentation says and what your systems actually do.
We also integrate RoPA management into broader compliance programmes, connecting your processing records to data processing agreements, privacy notices, retention schedules, and risk assessments so that every element of your data protection framework is linked and navigable.
Pitch is the law firm for innovators and creatives. If you need to build, review, or update your Records of Processing Activities, get in touch or schedule a meeting with our team.
%402x.svg){kind=small}
%402x.svg){kind=icon}
%402x.svg){kind=icon}
