RoPA Examples
Records of Processing Activities: Worked Examples
A worked RoPA example shows what a complete Article 30 entry looks like field-by-field — one named processing activity with its purpose, lawful basis, categories of data subjects and personal data, recipients, transfers and safeguards, retention period and security measures all filled in. Most teams know the Article 30 field list in the abstract but stall on what each field should actually say for a real activity. The examples below fill in those fields for four common activities — recruitment, payroll, customer support and marketing email — and then contrast a controller entry with an Article 30(2) processor entry to show how the two record types differ. All entries are illustrative and generic; they are not legal advice, and your own purposes, lawful bases and retention periods will differ.
Key takeaways
- A complete entry fills in every Article 30 field for one named activity — purpose, lawful basis, data subjects, data categories, recipients, transfers + safeguards, retention and security measures.
- The hardest fields to get right are lawful basis and retention: they should be specific to the activity, not copied across every entry in the register.
- A controller entry (Article 30(1)) states its own purpose; a processor entry (Article 30(2)) does not — it records the controller it acts for and the categories of processing carried out on that controller's behalf.
- Get the granularity right: one entry per business process with a coherent purpose, one set of recipients and one retention rule — not one entry per individual operation.
What does a complete RoPA entry look like?
A complete Record of Processing Activities entry describes a single processing activity and fills in each of the Article 30(1) content elements for it. The fields are always the same; what makes an entry useful is that every field carries a real, activity-specific value rather than a generic placeholder. The four worked examples that follow are controllerentries — activities the organisation carries out for its own purposes — written exactly as you would record them in a register. They are illustrative only.
Example 1 — Recruitment (controller)
| Purpose of processing | Assessing and selecting candidates for open roles, managing the hiring process, and (with consent) keeping promising candidates in a talent pool for future vacancies. |
|---|---|
| Lawful basis | Legitimate interests (Art. 6(1)(f)) for assessing applicants and steps prior to a contract (Art. 6(1)(b)); consent (Art. 6(1)(a)) for talent-pool retention beyond the live vacancy. |
| Categories of data subjects | External job applicants; named referees provided by applicants. |
| Categories of personal data | Contact details, CV/work history, education, interview notes and scores, right-to-work evidence, references. No special-category data collected by design. |
| Categories of recipients | Internal hiring managers and HR; applicant-tracking-system (ATS) provider acting as processor; background-check provider where used. |
| Transfers & safeguards | ATS hosted within the EEA — no third-country transfer. (Where an ATS hosts in the US, record the Standard Contractual Clauses and the linked Transfer Impact Assessment.) |
| Retention period | Unsuccessful applicants: 6–12 months after the decision; talent pool: until consent is withdrawn or a defined review point; successful hires migrate to the employee record. |
| Security measures | Role-based access limited to the hiring panel, encryption in transit and at rest, access logging, processor bound by an Article 28 contract. |
Example 2 — Payroll (controller)
| Purpose of processing | Calculating and paying employee salaries, deducting and remitting tax and statutory contributions, and producing payslips and statutory reports. |
|---|---|
| Lawful basis | Performance of the employment contract (Art. 6(1)(b)) and compliance with a legal obligation (Art. 6(1)(c)) for tax and social-insurance reporting. |
| Categories of data subjects | Current and former employees; in some cases dependants named for benefits. |
| Categories of personal data | Name, address, national identifier (e.g. PPS/NI number), bank details, salary and deductions, tax codes, benefit elections. |
| Categories of recipients | Payroll-bureau provider acting as processor; the tax authority (Revenue/HMRC); pension and benefits providers; the organisation's bank. |
| Transfers & safeguards | None outside the EEA where the bureau hosts within the EEA. Record any cloud sub-processor location and its Chapter V safeguard if data leaves the EEA. |
| Retention period | Payroll and tax records retained for the statutory period (commonly 6 years after the relevant tax year), then deleted. |
| Security measures | Strict access controls on financial data, encryption, segregation of duties for payment approval, audited bureau under an Article 28 contract. |
Example 3 — Customer support (controller)
| Purpose of processing | Receiving, triaging and resolving customer queries and complaints, and maintaining a history of contacts to provide continuity of service. |
|---|---|
| Lawful basis | Performance of the contract (Art. 6(1)(b)) for service users; legitimate interests (Art. 6(1)(f)) for handling general enquiries and improving support quality. |
| Categories of data subjects | Customers and prospective customers who contact support. |
| Categories of personal data | Name, contact details, account identifiers, ticket contents and correspondence, and any data the customer volunteers in describing an issue. |
| Categories of recipients | Support agents; the help-desk/ticketing-platform provider acting as processor; relevant internal teams for escalations. |
| Transfers & safeguards | Where the help-desk platform hosts or supports outside the EEA, record the Standard Contractual Clauses and the linked Transfer Impact Assessment after Schrems II (C-311/18). |
| Retention period | Tickets retained for a defined support window (e.g. 24 months from closure) for continuity and quality, then deleted or anonymised. |
| Security measures | Authenticated agent access, role-based permissions, encryption in transit and at rest, processor bound by an Article 28 contract. |
Example 4 — Marketing email (controller)
| Purpose of processing | Sending newsletters and promotional emails to subscribers and, where permitted, existing customers, and measuring engagement to improve relevance. |
|---|---|
| Lawful basis | Consent (Art. 6(1)(a)) for prospects, plus the ePrivacy/PECR rules on electronic marketing; legitimate interests (Art. 6(1)(f)) for the “soft opt-in” to existing customers for similar products. |
| Categories of data subjects | Newsletter subscribers; existing customers who have not opted out. |
| Categories of personal data | Name, email address, consent and preference records, opens/clicks and other engagement metrics. |
| Categories of recipients | Email-marketing-platform provider acting as processor; internal marketing team. |
| Transfers & safeguards | Where the email platform is US-based, record the Standard Contractual Clauses (or the provider's Data Privacy Framework certification) and the linked Transfer Impact Assessment. |
| Retention period | Held until the subscriber unsubscribes or consent is withdrawn; suppression list retained to honour opt-outs. |
| Security measures | Access controls on the marketing platform, encryption in transit, documented consent capture, processor bound by an Article 28 contract. |
What is an example of a controller vs processor RoPA entry?
The four entries above are controllerrecords under Article 30(1): each states a purpose the organisation set for itself. A processorrecord under Article 30(2) looks different. A processor acts only on a controller's documented instructions, so it does not record a purpose of its own — instead it records each controller it acts for and the categories of processing it carries out on their behalf. The example below is the same kind of activity as the customer-support entry above, but written from the processor's side: a SaaS provider that hosts and operates a help-desk platform for its business clients. It is illustrative only.
Example 5 — Help-desk hosting on behalf of clients (Article 30(2) processor)
| Processor & contacts | The SaaS provider (processor) and its DPO; each client organisation (controller) and its contact, recorded per engagement. |
|---|---|
| Controllers acted for | Each business client whose end-customer support data is hosted — listed individually rather than as a single purpose. |
| Categories of processing (per controller) | Storage and hosting of support tickets, operation of the help-desk application, backups, and technical support — carried out on the controller's documented instructions only. |
| Transfers & safeguards | Any sub-processor or hosting region outside the EEA recorded per controller, with the Standard Contractual Clauses and supplementary measures in place. |
| Sub-processors | Cloud-infrastructure provider and any third-party tooling, each under an Article 28(4) sub-processing contract with the controller notified. |
| Security measures | General description of technical and organisational measures: tenant isolation, encryption in transit and at rest, access logging, and breach-notification procedures to the controller. |
The contrast is the point: the controller entry answers “why are we processing this and on what basis?”, while the processor entry answers “for whom, and what are we doing on their instructions?” A processor record has no lawful basis or purpose field of its own, because the controller owns those. For the full mandatory field list for both record types, see the Article 30 (RoPA) template.
How many processing activities should a RoPA have?
There is no target number — a RoPA should hold one entry per distinct processing activity, and the right count falls out of getting the granularity right. The most common implementation mistake is granularity, in both directions. Too broad (“all HR processing” as one entry) and lawful basis, retention and recipients stop being assessable; too granular (“calculate tax” and “issue payslip” as separate entries) and the register becomes impossible to maintain. A workable rule of thumb: an activity is a business process with a single coherent purpose, one set of recipients, and one retention rule.
In practice a small organisation often lands between roughly 15 and 40 activities once the obvious ones — recruitment, payroll, customer management, marketing, supplier management, website analytics, CCTV — are mapped; a large multi-entity group with many products can run to several hundred. The examples on this page each represent exactly one activity at the right level. For how to identify and scope activities in the first place, see the RoPA requirements guide for Ireland and the UK.
From example to maintained register
Worked examples show what each field should say; the harder problem is keeping every entry true after the business changes. Acompli derives Article 30 records from approved assessments and keeps each field traceable to the evidence behind it — the AI drafts, classifies and surfaces fields, and a named person approves, edits or rejects each record before it reaches the published register. Nothing publishes itself. See what RoPA software is and how it works, and the Acompli RoPA management module for how the register is maintained in the platform.
Common questions about RoPA examples
What does a complete RoPA entry look like?
A complete RoPA entry names one processing activity and fills in every Article 30(1) field for it: the purpose of the processing; the lawful basis; the categories of data subjects; the categories of personal data; the categories of recipients; any transfers to third countries with their safeguards; the envisaged retention period; and a general description of the technical and organisational security measures. A worked recruitment example, for instance, states the purpose (assessing and selecting job applicants), the lawful basis (legitimate interests for assessment, consent for a talent pool), the data subjects (external candidates and referees), the data categories (contact details, CVs, interview notes, right-to-work evidence), the recipients (hiring managers and an applicant-tracking processor), the retention (typically 6–12 months for unsuccessful applicants), and the security measures (role-based access and encryption). If any of those fields is blank or generic, the entry is not yet complete.
What is an example of a controller vs processor RoPA entry?
A controller RoPA entry under Article 30(1) is written from the organisation's own purposes — for example a payroll activity that records why the data is processed, the lawful basis, the data subjects and categories, the recipients, retention and security. A processor RoPA entry under Article 30(2) is written from a different angle: it does not state a purpose of its own, because the processor acts only on the controller's documented instructions. Instead it records the controller it acts for, the categories of processing carried out on that controller's behalf, any third-country transfers and their safeguards, and a general description of the security measures. A SaaS provider hosting a client's customer-support tickets, for example, lists each client controller and the category of processing (storage and helpdesk operations) rather than a purpose it set itself.
How many processing activities should a RoPA have?
There is no fixed number — a RoPA should have one entry per distinct processing activity, and the right count comes from getting the granularity right rather than hitting a target. A small organisation often lands somewhere between 15 and 40 activities once the obvious ones (recruitment, payroll, customer management, marketing, supplier management, website analytics, CCTV) are mapped; a large group with many products and entities can run to several hundred. An activity is a business process with a coherent purpose, not every individual operation: 'payroll' is one activity, not separate entries for 'calculate tax' and 'issue payslip'. Too granular and the register becomes unmaintainable; too broad and lawful basis, retention and recipients stop being assessable. Aim for entries where one purpose, one set of recipients and one retention rule hold true.
Primary sources
- GDPR Article 30 (EUR-Lex, Regulation (EU) 2016/679)
- DPC — Records of Processing (Article 30) Guidance
- ICO — What do we need to document under Article 30?
These examples are illustrative and generic; they are not legal advice. Your own purposes, lawful bases, recipients, transfers and retention periods will differ — verify each entry against your processing and, where needed, professional advice.
Related research
Article 30 (RoPA) Template
The mandatory controller and processor fields, as a usable Article 30 template.
Read article →RoPA Requirements: Ireland & UK
Article 30 requirements under the EU and UK GDPR, with the DPC and ICO compared.
Read article →RoPA Software
What RoPA software is, how assessment-fed drafting works, and what to look for.
Read article →