Skip to content
SimpleAct Logo

Guide · GDPR Art. 30

As of 4 October 2026

Records of Processing Activities (RoPA) under Art. 30 GDPR: Template & Examples

The record of processing activities is the backbone of your GDPR documentation – and the first thing a supervisory authority asks for. This guide gives you every mandatory field as a table, examples for typical processing activities, a generator for single entries and a free Excel template.

Download the RoPA template (Excel)Open the entry generator

XLSX, approx. 28 KB · no sign-up · controller and processor, with example rows

  • Every field under Art. 30(1) and (2)
  • Examples for 8 typical activities
  • Generator for single RoPA entries
  • Free Excel template
app.simpleact.de

Records of processing

Demo Organisation Ltd · 4 processing activities

A

Processing activities

  • RecruitmentHR · Art. 6(1)(b)Approved
  • PayrollHR · processorApproved
  • AI assistant in customer serviceSales · AI system linkedIn review
  • Video conferencingIT · check third countryDraft

Mandatory fields "AI assistant"

5/7
  • Controller
  • Purposes
  • Data subjects & data
  • Recipients
  • Third country
  • Erasure periods
  • TOMs

Sample data · 2 fields open

In short

A record of processing activities (RoPA) lists every processing of personal data in your organisation with the information required by Art. 30 GDPR: controller, purposes, data subjects, data categories, recipients, third-country transfers, erasure periods and security measures. It must be kept in writing, electronic form is fine, and made available to the supervisory authority on request. Almost every organisation needs one.

Basics

What a record of processing activities is – and why you need it

The record of processing activities – RoPA for short, in German "Verarbeitungsverzeichnis" or VVT – is governed by Art. 30 GDPR. Every controller maintains a record of all processing activities under its responsibility (para. 1). Every processor additionally keeps its own record of the activities it carries out on behalf of others (para. 2). The record must be in writing, which includes electronic form (para. 3), and it is made available to the supervisory authority on request (para. 4).

Recital 82 states the purpose: the record serves to demonstrate compliance with the Regulation and allows the supervisory authority to monitor the processing operations. Unlike the older German procedure register, there is no public register anyone can inspect, and no notification to the authority. The RoPA is an internal document that must be ready to show at any time.

What counts as a "processing activity"? The German Data Protection Conference (DSK), the body of the German supervisory authorities, generally means a business process at a suitable level of abstraction – "recruitment", "payroll" or "newsletter", not every single program or record. It applies a strict standard: every new purpose is a separate processing activity. The sum of these individual descriptions makes up the record.

The content is manageable. Art. 30(1) requires seven items, two of them only "where possible": erasure periods and a general description of the technical and organisational measures (TOMs). The legal basis, by the way, is not a mandatory field – even though many templates list it. The DSK does, however, consider it sensible and permissible to add further details such as the legal basis, the data source or the people with access when you use the record for other purposes as well. We recommend that too, because you need this information anyway for privacy notices under Art. 13 and 14.

The RoPA is the hub of your data protection documentation. From it you derive which processing needs a data protection impact assessment, which vendors need a data processing agreement, which periods your deletion concept must cover and what belongs in your privacy notices. If you want to answer data subject requests quickly, the RoPA tells you where a person's data actually lives. The record alone does not discharge every documentation duty, though – it is one building block of accountability under Art. 5(2) GDPR, alongside proof of consent, TOMs and contracts.

Keeping no record or an incomplete one, or failing to provide it on request, infringes Art. 30 GDPR. Art. 83(4)(a) provides for fines of up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher. In practice something else matters more than the fine: in every audit, every data breach and every complaint, the RoPA is the first document requested. A well-kept record shows that you have your processing under control.

Large parts of the AI Act have applied since 2 August 2026. It does not require a record of its own and does not change Art. 30 GDPR. Where AI systems process personal data, however, that processing belongs in the RoPA like any other – with the AI vendor as a recipient and, where relevant, a third-country transfer. The section "AI in the record of processing" below shows how to do that cleanly.

items per processing activity under Art. 30(1)(a)–(g)
7
items per processing activity under Art. 30(1)(a)–(g)
employees: exemption under para. 5 – rarely applies in practice
< 250
employees: exemption under para. 5 – rarely applies in practice
or 2% of turnover: fine ceiling for breaches of Art. 30 (Art. 83(4))
€10m
or 2% of turnover: fine ceiling for breaches of Art. 30 (Art. 83(4))

Mandatory fields

What goes into the record: every item under Art. 30(1)

The seven mandatory items for controllers, each with an example from recruitment. Below them, four items that are not required but that we recommend, because you need them anyway for privacy notices, DPIAs and data subject requests.

Name and contact details
What to enterController, any joint controllers, EU representative and data protection officer with contact details. Once for the whole record is enough.
Example: recruitmentDemo Organisation Ltd, 1 Sample Street, Sample Town; DPO: privacy@demo.example
ReferenceArt. 30(1)(a)
Purposes of the processing
What to enterWhat the data is processed for – specific, not "HR in general". Every new purpose is a separate activity.
Example: recruitmentRunning recruitment procedures, selecting and hiring staff
ReferenceArt. 30(1)(b)
Categories of data subjects
What to enterWhose data: employees, applicants, customers, prospects, suppliers, website visitors.
Example: recruitmentApplicants, referees where relevant
ReferenceArt. 30(1)(c)
Categories of personal data
What to enterWhich types of data. Name special categories under Art. 9 (e.g. health, religion) and Art. 10 data separately.
Example: recruitmentContact details, CV, references, qualifications, salary expectations; disability status where disclosed (Art. 9)
ReferenceArt. 30(1)(c)
Categories of recipients
What to enterTo whom data has been or will be disclosed – internal and external, including recipients in third countries. Processors are recipients.
Example: recruitmentHiring department, works council, provider of the applicant tracking software (processor)
ReferenceArt. 30(1)(d)
Third-country transfers
What to enterWhere applicable, transfers to third countries naming the country; for transfers under the second subparagraph of Art. 49(1), documentation of the safeguards.
Example: recruitmentNone – software operated in the EU
ReferenceArt. 30(1)(e)
Erasure periods
What to enter"Where possible": envisaged time limits for erasure of the different categories of data. Ideally a reference to the deletion class in your deletion concept.
Example: recruitmentRejected applications 6 months after the procedure ends (internal decision); talent pool only with consent
ReferenceArt. 30(1)(f)
TOMs
What to enter"Where possible": a general description of the measures under Art. 32(1) – specific enough to allow a first review. Referring to the TOM documentation is common.
Example: recruitmentRole-based access for HR and hiring managers only, encryption, logging; see TOM document
ReferenceArt. 30(1)(g)
Legal basis (recommended)
What to enterNot part of Art. 30, but mandatory in privacy notices. Keeping it in the RoPA avoids duplicate work; for legitimate interests, document the balancing test.
Example: recruitmentArt. 6(1)(b) GDPR (steps prior to an employment contract); talent pool: consent
Reference– (cf. Art. 13(1)(c))
Systems and data source (recommended)
What to enterWhich applications hold the data and where it comes from. Helps with data subject requests and deletion.
Example: recruitmentApplicant tracking software, HR mailbox; source: applicants themselves
Reference–
Owner, review date (recommended)
What to enterWho maintains the entry and when it was last reviewed. A fixed review cycle – for example yearly – is good practice.
Example: recruitmentHead of HR; reviewed 4 Oct 2026
Reference–
DPIA need, AI link (recommended)
What to enterWhether a data protection impact assessment was considered or carried out, and whether an AI system is involved.
Example: recruitmentDPIA not required (assessment of 4 Oct 2026); no AI system
Reference– (cf. Art. 35)

The details under point (a) apply to the whole record and need not be repeated in every entry. Rows marked "recommended" are not required by Art. 30 GDPR.

Controller or processor

Two records: Art. 30(1) and (2) compared

Many organisations are both – controller for their own customer and staff data, and processor for services they provide to customers. In that case you need two records or two clearly separate parts.

Who keeps it?
Controller (para. 1)Every controller and, where applicable, its EU representative
Processor (para. 2)Every processor and, where applicable, its EU representative
Scope
Controller (para. 1)All processing activities under its responsibility
Processor (para. 2)All categories of processing activities carried out on behalf of a controller
Name and contact details
Controller (para. 1)Controller, joint controllers, representative, data protection officer (point a)
Processor (para. 2)Processor and every controller on whose behalf it acts, representatives and data protection officer (point a)
Purposes
Controller (para. 1)Yes (point b)
Processor (para. 2)No – instead the categories of processing carried out for each controller (point b)
Data subjects and data categories
Controller (para. 1)Yes (point c)
Processor (para. 2)Not expressly required
Recipients
Controller (para. 1)Yes (point d)
Processor (para. 2)Not expressly required
Third-country transfers
Controller (para. 1)Yes (point e)
Processor (para. 2)Yes (point c)
Erasure periods
Controller (para. 1)Where possible (point f)
Processor (para. 2)Not expressly required
TOMs
Controller (para. 1)Where possible, general description (point g)
Processor (para. 2)Where possible, general description (point d)
Form and disclosure
Controller (para. 1)In writing, including electronic form (para. 3); on request to the supervisory authority (para. 4)
Processor (para. 2)In writing, including electronic form (para. 3); on request to the supervisory authority (para. 4)

The Excel template on this page contains both records as separate sheets.

Exemption

Fewer than 250 employees: do small organisations need a RoPA?

Art. 30(5) GDPR contains an exemption for enterprises and organisations employing fewer than 250 persons. It comes with three exceptions, however, and any one of them is enough to bring the obligation back: the processing is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or it includes special categories of data under Art. 9(1) or personal data relating to criminal convictions and offences under Art. 10.

The DSK expressly cites the regular processing of customer or employee data as an example of processing that is "not occasional" – which is what practically every organisation does as soon as it runs payroll or a customer database. On risk, unlike the data protection impact assessment, it does not have to be a high risk; any risk counts. According to the DSK, scoring and monitoring measures regularly fall into this group.

As a result, even a small organisation almost always needs a record – at least for its regular processing. Anyone processing health data, such as sick notes, or religious affiliation for the German church tax also falls under the third exception. Our recommendation: keep a RoPA regardless of size. For a small business this is often just ten to twenty entries.

  • Exception 1: processing is likely to result in a risk to data subjects
  • Exception 2: processing is not occasional (e.g. payroll, customer data)
  • Exception 3: special categories (Art. 9) or criminal data (Art. 10)
  • One exception is enough – the exemption then does not apply

Interactive

RoPA entry generator: prepare an entry in a minute

Pick a typical processing activity, enter your organisation and say whether an AI system is involved or data goes to a third country. You get a pre-filled entry with every mandatory item to copy and adapt. Nothing is stored or transmitted.

Processing activity
About the processing
app.simpleact.de

RoPA entry (draft)

Recruitment

A
Name
Recruitment
Controller, DPO (point a)Required
[Organisation], [address]; data protection officer: [name, contact]
Purposes (point b)Required
Running recruitment procedures, selecting and hiring staff
Data subjects (point c)Required
Applicants, referees where relevant
Data categories (point c)Required
Contact details, CV, references and qualifications, salary expectations, interview notes; disability status where disclosed (special category, Art. 9)
Recipients (point d)Required
HR, hiring department, works council; provider of the applicant tracking software (processor)
Third-country transfer (point e)Required
None
Erasure periods (point f)Required
Rejected applications 6 months after the procedure ends (internal decision, based on German anti-discrimination claim periods); talent pool only with consent; on hiring, transfer to the personnel file
TOMs (point g)Required
See TOM documentation; including role-based access rights, encryption in transit and at rest, logging, backups
Legal basisRecommended
Art. 6(1)(b) GDPR (steps prior to an employment contract); talent pool: consent (Art. 6(1)(a)); for disability status also Art. 9(2)(b) (employment law, check case by case)
SystemsRecommended
Applicant tracking software, HR mailbox

An example for orientation, not legal advice. Periods and legal bases are examples and must be checked case by case; fill in the placeholders in square brackets.

Examples

Typical processing activities in a mid-sized company

These activities appear in almost every RoPA. The table is the short version of the generator examples – a starting point for your inventory, not a finished record. Statutory periods shown are German law.

Recruitment
PurposeSelection and hiring
Data subjectsApplicants
Recipients (selection)HR, hiring department, works council, software provider
Erasure period (example)6 months after rejection (recommendation)
Payroll
PurposePay, statutory reporting
Data subjectsEmployees
Recipients (selection)Tax office, social security, bank, payroll provider
Erasure period (example)Payroll accounts 6 years (Section 41 EStG), vouchers 8 years
Time recording
PurposeWorking time law, payroll
Data subjectsEmployees
Recipients (selection)Line managers, HR, software provider
Erasure period (example)At least 2 years for overtime (Section 16(2) ArbZG)
Personnel administration
PurposeRunning the employment relationship
Data subjectsEmployees
Recipients (selection)HR, line managers, tax advisers
Erasure period (example)Staggered after employment ends (recommendation: deletion concept)
Customer management (CRM)
PurposeSales, order processing
Data subjectsCustomers, contacts
Recipients (selection)Sales, accounting, CRM provider
Erasure period (example)Letters 6 years, invoices 8 years
Accounting
PurposeCommercial and tax duties
Data subjectsCustomers, suppliers
Recipients (selection)Tax advisers, tax office, bank
Erasure period (example)Books 10 years, vouchers 8 years
Newsletter
PurposeInformation, advertising
Data subjectsSubscribers
Recipients (selection)Marketing, newsletter tool
Erasure period (example)Until withdrawal; proof per internal decision
Website & contact form
PurposeProvision, security, enquiries
Data subjectsVisitors, enquirers
Recipients (selection)Hosting provider
Erasure period (example)Server logs short (recommendation)
Video conferencing
PurposeMeetings, training
Data subjectsParticipants
Recipients (selection)Conferencing provider
Erasure period (example)Per provider settings
Email and groupware
PurposeBusiness communication
Data subjectsEmployees, contacts
Recipients (selection)Email/cloud provider
Erasure period (example)Business letters 6 years
IT administration and logs
PurposeOperating and securing IT
Data subjectsEmployees, users
Recipients (selection)IT service provider
Erasure period (example)Per security concept (recommendation)
AI assistant in customer service
PurposeAnswering enquiries
Data subjectsCustomers, service team
Recipients (selection)AI vendor, model provider
Erasure period (example)Per contractual period

German statutory periods: Section 147 AO, Section 257 HGB (accounting vouchers eight years since 2025), Section 41(1) sentence 9 EStG, Section 16(2) ArbZG – details on the deletion concept page. "Recommendation" = internal decision, not a statutory period.

AI in the record of processing

How to record AI systems in your RoPA

The AI Act does not create a record under Art. 30 of its own. As soon as an AI system processes personal data, though, it is part of a processing activity – or one in its own right. These points are our recommendation.

Purpose, not tool

An AI tool is not a purpose. Record the processing it is used for – "answering customer enquiries", "pre-selecting applications". If a tool serves several purposes, it belongs in several entries.

New purpose, new entry

When an existing process is extended with AI, check whether the purpose changes. According to the DSK every new purpose is a separate activity; for minor changes, updating the existing entry is enough.

AI vendor as recipient

The provider of the AI service is usually a processor and one of the recipients (point d). Model and data centre providers behind it are sub-processors – they appear in the vendor's list.

State third countries honestly

Many model APIs run wholly or partly outside the EEA. Record the country and the transfer basis (point e) – remote access for support counts too.

Name the data specifically

AI involves more data than meets the eye: inputs, uploaded files, outputs, histories, logs. Name these categories and check whether special categories may appear in free text.

Flag automated decisions

If a system makes decisions with legal or similarly significant effects without human review, Art. 22 GDPR applies. A dedicated flag in the RoPA makes such cases visible.

Document the DPIA check

Art. 35(1) expressly names the use of new technologies as a reason to check for high risk. Note in the entry whether a data protection impact assessment was considered and carried out.

Link to the AI inventory

If you keep an AI inventory for the AI Act alongside the RoPA, link the two: for each AI system its processing activities, for each activity the system. Gaps then show up on both sides.

For high-risk AI under Annex III, the AI Act's deployer obligations apply from 2 December 2027 following the Digital Omnibus. Deployers then use the provider's information under Art. 13 AI Act for their DPIA (Art. 26(9) AI Act).

Approach

Building a record of processing in 7 steps

How to get from a blank page to a record you can show. The order is a recommendation from practice; for a mid-sized company 30 to 80 entries are common.

  1. 1

    Assign ownership

    Name a person to coordinate the RoPA – often the data protection officer or privacy coordinator. Departments supply the content, because only they know their processes.

  2. 2

    Inventory processes

    Go department by department: HR, sales, marketing, accounting, IT, purchasing, management. Software lists, supplier lists and the org chart help. Ask specifically about AI tools departments use on their own.

  3. 3

    Define activities

    Group operations with the same purpose into one activity and separate different purposes. One entry per program is too granular, one entry "HR" too coarse.

  4. 4

    Fill in the mandatory items

    For each activity the items under Art. 30(1)(b)–(g), plus legal basis and systems as a recommendation. The Excel template and the generator above help you start.

  5. 5

    Create cross-references

    Link every entry to the relevant DPA, the deletion class in your deletion concept, the TOM documentation and, where needed, the DPIA. Missing contracts or periods surface along the way.

  6. 6

    Review and approve

    Have entries confirmed by the department and reviewed by the data protection officer. An approval status with a date shows which version applies.

  7. 7

    Maintain continuously

    New software, new purposes, new vendors: make the RoPA check a fixed step in every roll-out. We also recommend reviewing all entries once a year.

Free template

Record of processing template in Excel

The template contains every mandatory item under Art. 30 GDPR as columns, recommended extra fields, eight example rows and drop-down lists. Free to use and adapt, no sign-up.

Download the RoPA template (Excel)

SimpleAct_Records_of_Processing_Template_EN.xlsx

  • Sheet "RoPA controller" (Art. 30(1))
  • Sheet "RoPA processor" (Art. 30(2))
  • Sheet "Master data" for point (a)
  • Sheet "Guide" explaining every column

Common mistakes

Six mistakes we often see in records of processing

Programs instead of processes

An entry "Microsoft 365" says nothing about purposes. The program is a system; the activity is e.g. "email communication" or "document storage".

Purposes too vague

"Business purposes" or "administration" do not allow any review. Write it so an outsider understands what happens to the data.

Recipients forgotten

Service providers, group companies, tax advisers and authorities are often missing. Processors are recipients and belong in the record.

Third countries left out

US cloud services, support from third countries or AI APIs outside the EU do not appear in the RoPA. That is exactly what authorities ask about.

Created once, never maintained

A RoPA from 2018 rarely reflects today's IT. Without a review date and an owner, every record goes stale.

Special categories overlooked

Sick notes, religious affiliation for church tax or disability status are Art. 9 data and must be named separately.

With SimpleAct

Records of processing in SimpleAct

The GDPR module (from Professional) keeps the RoPA as structured entries rather than a spreadsheet – linked to your AI systems and vendors.

  • Every item under Art. 30 plus legal basis and data source
  • Legal bases as a fixed choice of the six values in Art. 6(1)
  • Special categories under Art. 9 recorded separately
  • Processors linked from the vendor register
  • Status draft, in review, approved, archived
  • Gap list: AI systems without a RoPA entry
  • Review dates and date of last review
  • Export as CSV and in the full GDPR export

Starting with Excel?

The template on this page is enough to get going. SimpleAct pays off once the record should grow together with the AI inventory, DPAs, DPIAs and erasure periods.

See the GDPR module

FAQ

Frequently asked questions about the record of processing

Every controller and every processor (Art. 30(1) and (2) GDPR), including associations and freelancers. The exemption for organisations with fewer than 250 employees (para. 5) falls away as soon as processing is not occasional, is likely to result in a risk or covers special categories – which is almost always the case.
No. Art. 30(1) does not mention the legal basis. The German Data Protection Conference considers it sensible and permissible to add it. We recommend doing so, because you have to state the legal basis in your privacy notices under Art. 13(1)(c) anyway.
No. The GDPR does not provide for public inspection. The record is internal and is made available to the supervisory authority on request (Art. 30(4)). The old German procedure register, which was partly public, was replaced by it.
The DSK understands a processing activity as a business process at a suitable level of abstraction and applies a strict standard: every new purpose is a separate activity. The TOM description should be specific enough for the authority to carry out a first lawfulness check.
It must be in writing, and electronic form is sufficient (Art. 30(3)). Excel, privacy software or a document are all fine. What matters is that it is complete, up to date and can be produced on request.
The GDPR sets no interval, but the record must reflect the current state. We recommend making the RoPA check a fixed step whenever new software or purposes are introduced, and reviewing all entries once a year on top.
A missing or incomplete RoPA, or one not provided on request, infringes Art. 30 GDPR. Art. 83(4)(a) provides for fines of up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher.
Yes, as soon as they process personal data. You record the processing activity the tool is used for, with the AI vendor as a recipient and any third-country transfer. The AI Act does not require a record under Art. 30 of its own and does not change the GDPR obligation.
Yes. Art. 30(2) requires a record of all categories of processing activities carried out on behalf of a controller – with the names of the controllers, the categories of processing, third-country transfers and, where possible, the TOMs.
Yes. Templates such as the Excel file on this page or the examples published by supervisory authorities are a good start. They must be adapted to your actual processes, though; a copied example with no link to your organisation does not satisfy Art. 30.
The RoPA is the foundation: it shows which processing needs a data protection impact assessment, and the erasure periods under point (f) are made concrete in the deletion concept. Cross-references between the documents keep everything consistent.

More questions? We're happy to help. Send email · Try 7 days (credit card required)

Sources and status

As of · SimpleAct editorial team

This guide is general information and not legal advice. Periods, legal bases and examples must be checked case by case. Statutory periods mentioned are German law.

Changes

  • 2026-10-04 – Page rebuilt: mandatory fields table, para. 1/para. 2 comparison, para. 5 exemption, entry generator, Excel template, AI section. Clarified that the legal basis is not a mandatory field under Art. 30.
  • 2026-06-13 – First version.

Related topics

Records of processing and AI inventory in one place

SimpleAct connects the RoPA, vendors, erasure periods and AI systems. Try 7 days (credit card required) or let us show you the GDPR module.

Book a demoTry 7 days (credit card required)