A record of processing activities (ROPA) fails the first time a regulator or auditor asks for it when it is a list of systems instead of a register of purposes that answers every Article 30 field. This template gives you the register itself: the controller columns required by GDPR and UK GDPR Article 30(1), the shorter processor record under Article 30(2), the extra columns that make the record usable for accountability, and three worked rows you can copy and adapt. It is for data protection officers, privacy leads and the security and IT staff who supply the systems and security measures columns. How to discover and map the data in the first place is covered in the Data Mapping and ROPA Guide; this page assumes you have started that work and need the record.
How to use this template
- Build the register in a spreadsheet, a database or a privacy management tool. Article 30(3) says the record must be in writing, which includes electronic form, so a spreadsheet is acceptable.
- One row per processing activity, defined by purpose (for example "payroll" or "newsletter marketing"), not one row per system. A system that serves several purposes appears in several rows; a purpose that uses several systems lists them all in one row.
- Columns marked Art 30 are legally required content. Columns marked Recommended are not in Article 30 but are what supervisory authorities and auditors usually ask for next, and they let the record drive other duties.
- Replace text in square brackets, such as [Organisation], [System name] and [retention period], with your own values.
- Keep the controller register (section 5) and the processor register (section 6) on separate sheets if [Organisation] acts in both roles.
- Article 30(4) requires the record to be made available to the supervisory authority on request, so keep it current enough to send without a rewrite.
1. Purpose
This register is [Organisation]'s record of processing activities under Article 30 of the GDPR and UK GDPR. It documents why and how [Organisation] processes personal data, who it is shared with, where it goes, how long it is kept and how it is protected. It supports the accountability principle and is the starting point for privacy notices, data subject requests, DPIAs, retention and breach assessment.
2. Scope and the 250 employee exemption
- The register covers all processing of personal data by [Organisation] as controller, joint controller or processor, in any format, including processing carried out for [Organisation] by processors.
- Article 30(5) exempts organisations with fewer than 250 employees, but not where the processing is likely to result in a risk to the rights and freedoms of data subjects, is not occasional, or includes special category data under Article 9(1) or criminal conviction and offence data under Article 10.
- Routine processing such as payroll and customer records is not occasional, so in practice most small organisations still need a record for those activities. [Organisation] keeps a full register regardless of headcount.
3. Roles and responsibilities
- [Data Protection Officer or privacy lead]: owns the register, sets the column definitions, and reviews every new or changed row.
- Activity owners (heads of HR, marketing, finance, product): own the rows for their purposes and confirm them at each review.
- [IT and security]: complete the systems, location, transfer and security measures columns and confirm them against the asset inventory.
- [Procurement or legal]: record processors, contract references and transfer mechanisms.
4. Column definitions
| # | Column | Status | What to write |
|---|---|---|---|
| C1 | Activity ID and name | Recommended | Stable ID (for example HR-01) and a short purpose-based name. |
| C2 | Controller, joint controller, representative and DPO contact details | Art 30(1)(a) | Name and contact details; can sit once in a header if the same for all rows, plus any joint controller per row. |
| C3 | Purposes of the processing | Art 30(1)(b) | Specific purposes in plain words. "Business purposes" is not a purpose. |
| C4 | Lawful basis | Recommended | Article 6(1) basis per purpose; for legitimate interests, the reference of the assessment. |
| C5 | Special category or criminal offence data condition | Recommended | Article 9(2) condition or Article 10 basis, and under UK law the Data Protection Act 2018 Schedule 1 condition and appropriate policy document where one is needed. |
| C6 | Categories of data subjects | Art 30(1)(c) | For example employees, job applicants, customers, website visitors, children. |
| C7 | Categories of personal data | Art 30(1)(c) | For example contact details, bank details, health data, location data. Flag special category data. |
| C8 | Source of the data | Recommended | Data subject, employer, public sources, third party; needed for privacy notices. |
| C9 | Categories of recipients | Art 30(1)(d) | Internal teams, processors, other controllers, authorities, including recipients in third countries or international organisations. |
| C10 | Processors and contract reference | Recommended | Processor name and the reference to the Article 28 contract or data processing agreement. |
| C11 | International transfers | Art 30(1)(e) | Destination country or international organisation; for transfers under the second subparagraph of Article 49(1), documentation of suitable safeguards. |
| C12 | Transfer mechanism | Recommended | Adequacy, standard contractual clauses, UK IDTA or Addendum, binding corporate rules, or a derogation; link the transfer risk assessment. |
| C13 | Retention period | Art 30(1)(f), where possible | Envisaged time limit for erasure per data category, with the trigger (for example "6 years after employment ends"). Link the retention schedule. |
| C14 | Technical and organisational security measures | Art 30(1)(g), where possible | General description of Article 32(1) measures; reference the security standard rather than copying it. |
| C15 | Systems and data location | Recommended | Application and data store names from the asset inventory, and hosting region. |
| C16 | DPIA reference | Recommended | DPIA ID, or the screening decision that a DPIA was not required. |
| C17 | Activity owner and last review date | Recommended | Named role and the date the owner last confirmed the row. |
5. Controller register: worked examples
Three rows show the level of detail expected. Values in square brackets are illustrative and must be replaced with your own decisions.
| Column | HR-01 Payroll | MK-02 Newsletter marketing | FC-03 Office CCTV |
|---|---|---|---|
| C3 Purpose | Paying staff, tax and pension deductions, statutory reporting | Sending product news to subscribers who signed up | Preventing and investigating crime and safety incidents at [Site] |
| C4 Lawful basis | Art 6(1)(b) contract; Art 6(1)(c) legal obligation for tax reporting | Art 6(1)(a) consent [or soft opt-in rules under electronic marketing law] | Art 6(1)(f) legitimate interests, assessment [LIA-07] |
| C5 Special category | Health data for statutory sick pay: Art 9(2)(b) employment, [DPA 2018 Sch. 1 Part 1 para 1], appropriate policy document [APD-01] | None | None expected |
| C6 Data subjects | Employees, former employees | Subscribers | Staff, visitors, contractors, members of the public passing entrances |
| C7 Data categories | Name, address, national insurance or tax number, bank details, salary, sickness absence | Name, email address, consent record, email engagement data | Video images |
| C9 Recipients | Payroll bureau (processor), tax authority, pension provider | Email service provider (processor) | Security contractor (processor), police on lawful request |
| C11 and C12 Transfers | None | [United States], [standard contractual clauses or adequacy decision], TRA [TRA-03] | None |
| C13 Retention | [6 years after end of tax year] | Until consent withdrawn, plus suppression list of email address only | [30 days] unless retained for an investigation |
| C14 Security measures | Access limited to payroll group with MFA, encryption at rest, quarterly access review [per Security Standard SS-02] | SSO with MFA for marketing users, provider security assurance [report reference] | Recorder in locked comms room, restricted viewing, export log |
| C15 Systems | [HR system], [payroll bureau portal] | [Email platform], [CRM] | [Video recorder model], [Site] |
| C16 DPIA | Screened, not required [date] | Screened, not required [date] | [DPIA-04] |
The security measures column is where most records are weakest. A general description is enough under Article 30(1)(g), but it should name real controls (MFA, encryption, access review) and point to the standard that holds the detail. Accounts and API tokens used by integrations that move personal data between systems belong in that description too, because they are often the access path in a breach. See the GDPR Compliance Guide for Security Teams.
6. Processor register
Where [Organisation] processes personal data on behalf of customers or other controllers, it keeps the shorter record required by Article 30(2).
| Column | Status | Worked example: PR-01 Hosted support desk service |
|---|---|---|
| Processor, controller, representative and DPO contact details | Art 30(2)(a) | [Organisation] as processor; controller: each customer listed in [customer register]; [Organisation] DPO contact |
| Categories of processing carried out for each controller | Art 30(2)(b) | Hosting, storage and support access to customer ticket data, including end user names, emails and ticket content |
| Sub-processors | Recommended | [Cloud hosting provider], [email delivery provider], with contract references |
| International transfers and safeguards | Art 30(2)(c) | Support staff access from [country] under [standard contractual clauses] |
| Security measures | Art 30(2)(d), where possible | Tenant isolation, encryption in transit and at rest, support access by approval and logged [per ISMS scope] |
| Contract reference | Recommended | Data processing agreement version [x] in each customer contract |
7. Building and maintaining the register
- Information audit: run a questionnaire or interviews with each activity owner covering why data is processed, who it is about, what it is, who it is shared with, how long it is kept and how it is secured. The ICO describes this approach and recommends involving IT, information governance and legal.
- Check against documents: reconcile answers with contracts, data sharing agreements, privacy notices, the asset inventory and the vendor list. A processor in the accounts payable ledger who is missing from C10 is a gap.
- Link, do not duplicate: point C4, C12, C13, C14 and C16 to the legitimate interests assessments, transfer risk assessments, retention schedule, security standard and DPIAs rather than copying them.
- Change triggers: a new system, new vendor, new purpose, new data category or new transfer must update the register before go-live. Add a ROPA check to the change and procurement processes.
- Review: each owner confirms their rows at least every [12 months] and C17 is updated.
8. Using the register for other duties
| Duty | Columns used | Related resource |
|---|---|---|
| Privacy notices (Arts 13 and 14) | C3, C4, C6 to C9, C11, C13 | UK GDPR and Data Protection Act 2018 Guide |
| DPIA screening (Art 35) | C5, C7, C15, C16 | DPIA Template |
| Retention and deletion | C13, C15 | Data Retention and Disposal Policy Template |
| International transfers | C11, C12 | Transfer Impact Assessment (TIA) Template |
| Processor oversight (Art 28) | C9, C10 | Data Processor Due Diligence Questionnaire Template |
| Breach assessment (Arts 33 and 34) | C6, C7, C15 | Data Breach Notification Checklist |
9. Review and approval
- The register is approved by [Data Protection Officer] and reported to [governance committee] every [12 months] with: number of activities, rows past their review date, activities with special category data, transfers by mechanism, and activities with an outstanding DPIA.
- Non-compliance with Article 30 falls under Article 83(4)(a), the tier of fines up to EUR 10 million or 2 percent of worldwide annual turnover, whichever is higher.
Standards and references
- GDPR: Article 30, Records of processing activities
- ICO: How do we document our processing activities?
- ICO: International transfers, a guide
Implementation guidance
- Start with the obvious activities: HR, payroll, recruitment, customer accounts, marketing, CCTV and IT logs cover most organisations. Complete them before chasing edge cases.
- Agree the definition of an activity: purpose-based rows of roughly the granularity in section 5. Too coarse ("customer data") cannot support a privacy notice; too fine (one row per report) is never maintained.
- Get security to fill C14 and C15: pull system names from the asset inventory or CMDB so the register and the inventory stay reconciled.
- Measure: rows reviewed in the last [12 months], new systems with a ROPA entry before go-live, processors in the vendor list with a C10 entry, transfers with a recorded mechanism.
- Small versus large: a small organisation can keep one sheet with 15 to 30 rows. A group with several legal entities should add a controller entity column and consider a privacy tool that links rows to assets and vendors.
This template is provided for guidance, summarises Article 30 of the GDPR and UK GDPR, and is not legal advice. Related NHI Mgmt Group resources: Data Mapping and ROPA Guide · GDPR Compliance Checklist · DPIA Guide: Running a Data Protection Impact Assessment · International Data Transfers Map