ROPA template for universities: how to keep a record of processing activities under GDPR Article 30
Every university needs a record of processing activities, and most find it hard to keep current. This guide sets out exactly what Article 30 GDPR requires, what universities typically record, worked example entries, the mistakes we see most often, and how the record connects to vendor assessment. A free Word template is included.
The short version
- Article 30(1) GDPR lists seven items a controller's record must contain; Article 30(2) lists four for a processor. The record must be in writing (electronic is fine) and given to the supervisory authority on request.
- The under-250-employees exemption in Article 30(5) does not realistically apply to universities.
- Record activities by purpose (admissions, payroll, a research project), not by IT system. Then link each activity to the systems and vendors that support it.
- The recipients and transfers columns are where university records most often go stale, because vendors change subprocessors and hosting after approval.
- Download the free ROPA template for universities (Word), with Article 30(1) and 30(2) tables and three example rows each.
Contents
1. What Article 30 requires
Article 30(1) says each controller "shall maintain a record of processing activities under its responsibility" and lists what that record must contain. In plain terms:
| Art. 30(1) | Required content | Plain-English note |
|---|---|---|
| (a) | Name and contact details of the controller and, where applicable, the joint controller, the controller's representative and the DPO | Usually recorded once for the whole university, plus joint controllers per activity. |
| (b) | The purposes of the processing | Specific enough to be meaningful: "student admissions", not "administration". |
| (c) | A description of the categories of data subjects and of the categories of personal data | Both lists are required. Flag special category data separately. |
| (d) | The categories of recipients, including recipients in third countries or international organisations | Includes processors (vendors) and public bodies the data is shared with. |
| (e) | Where applicable, transfers to a third country or international organisation, identifying the country, and for transfers under the second subparagraph of Art. 49(1), documentation of suitable safeguards | Name the country and the transfer tool for each non-EEA recipient. |
| (f) | Where possible, the envisaged time limits for erasure of the different categories of data | Point to the retention schedule rather than writing "as long as necessary". |
| (g) | Where possible, a general description of the technical and organisational security measures referred to in Article 32(1) | A summary with a reference to the full security documentation is enough. |
Article 30(2) sets a shorter list for processors: the name and contact details of the processor and of each controller it acts for (plus representatives and the DPO), the categories of processing carried out for each controller, any third-country transfers, and where possible a general description of the security measures.
Three further rules complete the article. The record must be in writing, "including in electronic form" (Art. 30(3)). It must be made available to the supervisory authority on request (Art. 30(4)). And the exemption in Art. 30(5) is discussed in the next section.
2. Does the 250-employee exemption apply?
Article 30(5) says the record-keeping obligations do not apply to an organisation employing fewer than 250 people, unless the processing is likely to result in a risk to individuals, is not occasional, or includes special category data or data about criminal convictions and offences.
Validemic's analysis Most universities employ well over 250 people. Even smaller institutions process student and staff data continuously, which is "not occasional", and usually some special category data (for example health information for study adjustments or sick leave). The exemption therefore does not fit higher education in practice. The French supervisory authority, the CNIL, also notes that the limited exemption for small organisations covers only occasional, low-risk processing.
3. How universities organise their record
The GDPR does not prescribe a format, and universities take different approaches. Three published examples show the range:
- Per organisational unit. The University of Groningen publishes processing registers per cluster and staff department (for example Education & Students, HR & Health, Finance & Procurement, Research & Impact). Each entry briefly describes which data are processed, why, what is done with them and who is responsible. The university notes that its register is not yet complete.
- Separate registers for business processes and research. Leiden University keeps a register for business processes and a separate one for research, and asks researchers starting a project with personal data to record it, using the data management plan to describe the processing.
- A dedicated research record. Lund University's PULU is its data processing record for research studies. Researchers record items such as the principal investigator, whether the university is the controller, purposes, data subject categories, personal data types, external sharing, processing locations, security measures and the digital tools used.
Validemic's analysis A split between administrative processing and research works well in universities because research projects are numerous, time-limited and owned by individual researchers, while administrative processing is stable and owned by central functions. Whatever the split, the record should be searchable across both, so that you can answer questions such as "which activities use vendor X?" in minutes.
4. What universities typically record
The list below is a starting point for an inventory, not a complete or authoritative list. Your activities will depend on national law and how your institution is organised.
| Area | Typical processing activities | Points to watch |
|---|---|---|
| Student administration | Admissions, enrolment, fees, study records and transcripts, degree certificates, disability and study adjustments, student complaints and appeals, disciplinary cases | Special category data in adjustments; data shared with national registers and funding bodies. |
| Teaching and learning | Learning platform, assessment and grading, plagiarism checking, online exams and proctoring, lecture recording, course evaluations | AI features in teaching tools; proctoring and monitoring; vendors with non-EEA subprocessors. |
| Research | Each project processing personal data: participant recruitment, surveys, interviews and transcription, health or biobank data, data sharing with partners, archiving | Joint controllership in consortia; special category data; transfers to non-EEA partners. |
| HR | Recruitment, contracts and payroll, absence and occupational health, performance and development, staff directory | Health data; works council or employee representative information duties under national law. |
| Library | Loans and accounts, interlibrary loans, authentication to licensed e-resources, reading room access | Attributes released to publishers; retention of loan history. |
| Alumni and advancement | Alumni relations, newsletters, events, fundraising and donor records | Lawful basis for contact; wealth screening, if used; marketing tools. |
| IT and security | User accounts and identity management, email, logging and security monitoring, device management | Monitoring of staff and students; retention of logs. |
| Campus and facilities | Access cards, CCTV, room booking, visitor registration | Systematic monitoring; DPIA triggers. |
Several of these areas can trigger a DPIA under the EDPB-endorsed WP248 criteria, for example systematic monitoring or data concerning vulnerable data subjects. Our free DPIA screening tool helps decide, and the ROPA template has a column to record the result.
Reviewing a vendor right now? Validemic checks the vendor's documents against GDPR and the EU AI Act and cites every finding. Try the demo workspace
5. Worked example entries
These examples show the level of detail that makes a record useful. They are illustrations, not statements about any real university, and the values in square brackets are placeholders you replace with your own (for example, your institution's retention periods and lawful basis).
Example 1: Student admissions
| Purpose (b) | Receiving, assessing and deciding on applications to degree programmes. |
|---|---|
| Data subjects (c) | Applicants; referees. |
| Personal data (c) | Identity and contact details; education history and grades; application documents; nationality and residence status; special category data only where needed for adjustments. |
| Recipients (d) | Admissions staff; faculty assessors; [national admissions service]; processor: application portal vendor. |
| Transfers (e) | None, provided the vendor and its subprocessors process and access data only in the EEA (verified in vendor assessment [ref]). |
| Erasure (f) | [Per retention schedule, for example unsuccessful applications deleted X months after the admission round.] |
| Security (g) | Single sign-on with MFA; role-based access per programme; encryption in transit and at rest; reference to the IT security policy. |
Example 2: A research project with interviews
| Purpose (b) | Research project [ID]: semi-structured interviews with teachers about workload, including audio recording and transcription. |
|---|---|
| Data subjects (c) | Research participants; project researchers. |
| Personal data (c) | Name and contact details; consent records; audio recordings; transcripts; job role and school (pseudonymised in analysis). |
| Recipients (d) | Project researchers; processor: transcription service; co-investigators at a partner university under a written agreement. |
| Transfers (e) | If the transcription vendor uses a non-EEA subprocessor: the country and the transfer tool (adequacy decision, Data Privacy Framework entry or standard contractual clauses with a documented assessment). |
| Erasure (f) | Recordings deleted after transcription is checked; pseudonymised transcripts kept as set out in the data management plan. |
| Security (g) | Approved research storage only; pseudonymisation key held separately; access limited to named researchers. |
Transcription is a good illustration of why the record and the vendor review must be read together: the transfer entry depends entirely on what the vendor's subprocessor list says. Our fact sheets on transcription tools such as Otter.ai, Trint and Rev set out what each vendor documents publicly.
Example 3: Library services
| Purpose (b) | Loans, interlibrary loans and authentication to licensed e-resources. |
|---|---|
| Data subjects (c) | Students; staff; registered external users. |
| Personal data (c) | Name; library card number; university ID; current loans and limited loan history; authentication logs. |
| Recipients (d) | Library staff; processors: library management system and authentication proxy vendors; publishers receive only the attributes needed to confirm entitlement. |
| Transfers (e) | [None, or specify per vendor.] |
| Erasure (f) | [Loan history removed X days after return; account deleted X months after the user leaves.] |
| Security (g) | Minimal attribute release; access logs restricted to named administrators. |
6. When the university is a processor
Universities are mostly controllers, but they sometimes process personal data on someone else's behalf. Examples include a core facility that analyses data for an external research group under the group's instructions, university IT hosting a system for a separate legal entity such as a student union, or a survey unit running a questionnaire for a public agency. In those cases Article 30(2) requires a processor record, and Article 28 requires a processing agreement in which the university is the processor. The template includes a separate table for this.
Check the role carefully. The EDPB's Guidelines 07/2020 explain that the controller determines the purposes and the "essential means" (which data, for how long, who has access), while a processor may decide "non-essential means" such as the software used. If the university decides why the data is processed, for example in a joint research project, it is likely to be a controller or joint controller rather than a processor.
7. Common mistakes
- Recording systems instead of activities. "Learning platform" is a system. "Course delivery", "assessment" and "lecture recording" are activities with different data, recipients and retention.
- Purposes that are too broad. "Administration" or "research" does not tell a supervisory authority, or your own staff, anything useful.
- Missing the vendors. Article 30(1)(d) requires recipients, and processors are recipients. If the record does not list the vendors, nobody can tell which activities a vendor change affects.
- "No transfers" without checking. EU hosting is not the end of the question. The EDPB treats remote access from a third country, for example by support staff, as a transfer.
- Retention left blank or vague. Article 30(1)(f) says "where possible". For most university activities it is possible, through the records retention schedule.
- Research left out. Projects run by individual researchers never reach the central register. Linking registration to the data management plan, as Leiden does, helps.
- A one-off project. Records built for a GDPR programme and never updated. The CNIL says the record must be updated regularly as processing evolves.
- No owner per activity. Without a named owner, nobody updates the entry when the process changes.
8. How the ROPA ties to vendor assessment
The record of processing activities and the vendor assessment process describe the same reality from two directions. The ROPA starts from the purpose; the vendor file starts from the supplier. The links between them are explicit in EU guidance:
- The EDPB's Recommendations 01/2020 make "know your transfers" the first step for any international transfer and point to the Article 30 record, in particular points 30(1)(e) and 30(2)(c), as the place to start.
- The EDPB's Guidelines 07/2020 list a processor's own record of processing activities among the documents a controller may exchange with a processor to assess whether it provides sufficient guarantees.
- The CNIL recommends enriching the record with, among other things, documentation of international transfers and the contracts with processors.
In practice, three habits keep the two aligned:
- Give every vendor assessment and DPA a reference, and put that reference in the ROPA row (the template has a column for it).
- When a vendor notifies a new subprocessor or hosting change, look up every ROPA row that names the vendor and update the recipients and transfers columns. Our free subprocessor alerts tool and transfer mechanism tool help with this.
- Make "ROPA entry updated" the last step of every vendor approval. Our vendor assessment guide includes it in the checklist, and our European vendor questionnaire asks vendors for the information the transfers and recipients columns need.
For research specifically, see GDPR and AI tools in research.
9. The template
The ROPA template for universities is a Word document containing:
- Short instructions on Article 30, including the in-writing and supervisory authority rules.
- Part 1: controller details (Art. 30(1)(a)).
- Part 2: the controller record split into two tables covering every Art. 30(1) item, plus a third table of recommended fields: lawful basis, systems and vendors, vendor assessment and DPA reference, DPIA status, owner and last review.
- Part 3: the processor record (Art. 30(2)), with a recommended sub-processor column.
- A review log.
Each table includes three rows marked "EXAMPLE". Delete them before use. Many institutions will move the record into a spreadsheet or a register system once the structure is agreed; the column structure carries over directly.
The template follows the text of Article 30 GDPR as read on 7 October 2026. Your supervisory authority or national law may expect more. It is not legal advice.
Sources
- Regulation (EU) 2016/679 (GDPR), Articles 4, 28, 30, 32, 35 and 49 (retrieved 7 October 2026).
- CNIL: Le registre des activités de traitement, including its simplified template (retrieved 7 October 2026).
- University of Groningen: processing registers per cluster and staff department (retrieved 7 October 2026).
- Leiden University: Data processing register (retrieved 7 October 2026).
- Lund University: PULU guide (retrieved 7 October 2026).
- EDPB Recommendations 01/2020 on supplementary measures, version 2.0 (retrieved 7 October 2026).
- EDPB Guidelines 07/2020 on the concepts of controller and processor (retrieved 7 October 2026).
- Article 29 Working Party, Guidelines on DPIA (WP248 rev.01), endorsed by the EDPB (retrieved 7 October 2026).
About this page
Sources checked on 7 October 2026. The legal text was read in its Official Journal version; university examples come from the institutions' own published pages. The worked examples are illustrations written by Validemic, and statements labelled as Validemic's analysis are our interpretation. This page is not legal advice. If you spot an error, or you are from one of the universities mentioned and something has changed, please contact us and we will correct it.
Frequently asked questions
What is a ROPA?
A record of processing activities: the written inventory that Article 30 GDPR requires controllers and processors to keep. For controllers it must list, for each activity, the purposes, data subjects and data categories, recipients, third-country transfers, and where possible erasure time limits and a general description of security measures.
Does a university need a ROPA?
In practice yes. Article 30(5) exempts organisations with fewer than 250 employees only for occasional, low-risk processing that does not involve special category or criminal offence data. Universities process student and staff data continuously, so the exemption does not fit.
Is there an official ROPA template?
The GDPR does not prescribe a format; Article 30(3) only requires the record to be in writing, including electronic form. Some supervisory authorities publish templates, for example the French CNIL offers a simplified spreadsheet template.
Should research projects be in the ROPA?
Research involving personal data is processing like any other, so it needs to be recorded. Several universities keep a separate research register linked to the data management plan, for example Leiden University and Lund University's PULU.
Who must see the ROPA?
The controller or processor must make the record available to the supervisory authority on request (Article 30(4)). It is an internal document, although some universities publish summaries per unit, as the University of Groningen does.
How often should a ROPA be updated?
Whenever processing changes: a new purpose, data category, recipient, vendor, transfer or retention period. The CNIL says the record must be updated regularly as processing evolves. An annual full review is a sensible minimum.