Rules
Who must keep a record of processing activities, which fields it needs and what an AI assistant entry looks like, with a worked fictional example.
A record of processing activities is the written overview of all personal data processing for which your organisation is responsible. For each activity, record who is responsible, why you use the data, whom it concerns, what types of data are involved, who receives it, whether it leaves the EU, how long you retain it and how you protect it.
The GDPR calls it a “record of processing activities”. The obligation is in Article 30 GDPR. It is an internal document, different from your public privacy statement, that demonstrates you know what you do with personal data. The Autoriteit Persoonsgegevens (AP), the Dutch data protection authority, includes it among the mandatory accountability measures, alongside the DPIA, data breach register and privacy statement, among others.
Under Article 30(1), every controller keeps a record of processing carried out under its responsibility. Paragraph 2 imposes a similar obligation on processors. The exemption is in paragraph 5.
Paragraph 5 says the obligations do not apply to enterprises or organisations employing fewer than 250 people. This is followed by an “unless” covering three situations:
If any one applies, even a small organisation must keep a record.
The AP writes that processing is rarely occasional in practice, giving the examples of data about your own employees, customers, clients, patients or residents. Anyone with staff or regular clients therefore almost always has a record-keeping obligation. Asked by a small healthcare practice whether a record is required, the AP answers: yes, usually.
The European Commission has proposed amending paragraph 5. According to the EDPB and EDPS announcement of their joint opinion of 9 July 2025, the exemption would then apply to organisations with fewer than 750 employees, unless processing is likely to involve high risk. On 13 October 2026, we found no adopted text of that amendment. Until then, Article 30 applies as described above. Check the status before basing a decision on it.
Article 30(1) lists seven components, from (a) to (g). The table below places them alongside what you enter and an example for an AI tool. The example is fictional.
| Field (Article 30(1)) | What you enter | Example for an AI tool |
|---|---|---|
| a. Name and contact details | The controller, any joint controllers, representative and DPO if appointed | Voorbeeldkantoor Noord B.V., contact through the privacy lead; no DPO appointed |
| b. Processing purposes | Why you use the data, specific enough for an outsider to understand | Search and summarise client files with an AI assistant to answer caseworkers' questions |
| c. Data subjects and data | Groups of people and types of personal data | Clients, opposing parties, contacts, employees; name, address, contact details, client file contents, sometimes health data |
| d. Recipients | Types of recipient to whom you disclose data, including outside the EU | Own employees with access to the client file; the AI assistant provider as processor; its sub-processors |
| e. Transfers | Whether data goes to a country outside the EEA, which country, and for the specific transfer under Article 49(1), second subparagraph, documents about safeguards | United States, insofar as the provider processes there; the contractual basis for the transfer |
| f. Retention periods | Where possible: the period within which you erase categories of data | Conversations and uploaded files according to the plan's setting; client files according to your own retention period |
| g. Security | Where possible: a general description of technical and organisational measures | Business account with two-step verification, access per project, pseudonymisation before use, logging, employee training |
The words “where possible” apply only to retention periods and security. They are not a free pass to leave those fields blank. If you do not yet know the retention period, write down how you will determine it and when.
Article 30 does not mention the lawful basis for processing. Many organisations still include it, along with the processor's name, a reference to the data processing agreement and whether a DPIA has been done. That is a choice. The AP says you may decide how to draw up the record, provided it contains the prescribed information. Under paragraph 3, it must be in writing, including electronically. A spreadsheet meets that format requirement.
If you process data on another party's behalf, for example as a bookkeeping firm or online service provider, paragraph 2 requires your own record. It is shorter, with four components.
Many organisations are both: controller for their own personnel administration and processor for a client. The record then has two parts. For agreements with an AI tool provider, see the article about a data processing agreement with an AI provider.
The AP's accountability page explains who must keep a record and what it contains. Three points matter in practice.
Under Article 30(4), you make the record available to the supervisory authority on request. You do not need to submit or publish it. You must be able to show it when the AP asks. Starting to create one only after such a request is too late.
According to the AP, the processing overview is the organisation's own responsibility and not a task for the data protection officer. The DPO supervises it. In practice, DPOs do often keep a list, particularly of risky processing. Who is responsible for what within an organisation is explained in the article about AI governance.
In July 2026, the AP published a tool for deploying generative AI, together with its advice on Microsoft 365 Copilot at a municipality. The tool's first component is the record of processing activities. The AP recommends checking and, where necessary, updating the record before deploying generative AI, and using it to assess which existing processing activities are affected. The advice says the record must at least show broadly which processing activities a generative AI system affects, and that an organisation using such a system must in any event have a record, especially if it can access files containing personal data.
Yes, as soon as personal data enters it: a name in a question, an email you have rewritten, a client file you upload. The record describes processing, not software. Nevertheless, an AI tool almost always prompts changes to the record in two ways.
Using an AI assistant to search client files is a separate processing activity with its own purpose, recipients and often retention period. It gets its own entry. A worked example follows below.
The AP points out that generative AI generally brings new processing and can change how existing processing is performed. Giving an assistant access to your document environment affects personnel, client file and complaint entries at once. Each entry's list of recipients changes, and sometimes its transfers too.
A record can describe only what the organisation knows. If employees use a personal account, that processing is recorded nowhere. This is covered in the article about shadow AI. Which plans have a data processing agreement is explained in the plan comparison.
This example is fictional. Voorbeeldkantoor Noord is a fictional consultancy with forty employees using an AI assistant to search closed and ongoing client files.
The periods and dates in this example are fictional. Never enter a retention period you have not seen in your own plan's terms or settings.
The entry is specific: it also states what does not go in, and everything that may change has a date. Whether health data belongs in such a tool is a separate question to answer first. See the article about special category data.
The AP writes in its advice that the record achieves its purpose only if complete and regularly updated. A fixed rhythm works better than good intentions.
Public authorities also have a separate instrument for algorithms. It differs from the processing record and is explained in the article about the Dutch Algorithm Register and IAMA.
PrivaSearch pseudonymises personal data in documents before an AI assistant searches them. That processing itself also belongs in your record. Your PrivaSearch environment therefore creates a register entry for this one activity: purpose, data subjects, data categories, recipients, transfers, retention period and measures. The entry is intended to be pasted into your own record.
The entry comes from one form, alongside three other documents: an AI policy, a DPIA starter document and a written lawful basis with balancing assessment. They are prepared deterministically, without a language model. The contents follow your environment's configuration, so no measure appears unless enabled. For these documents and their contents, see the page about the GDPR and the EU AI Act.
These are starter documents, not legal advice. The rest of your record, your data protection officer's advice and formal adoption remain your responsibility. PrivaSearch therefore pre-fills one entry, not your whole record.
What the entry says about recipients and transfers depends on what you connect. Pseudonymisation and mandatory review are explained on the page about how it works. What a connected assistant does and does not see is on the page about AI chatbots and the GDPR. Parties involved in processing are in the sub-processor overview. Pseudonymised data remains personal data for your organisation, so the entry remains necessary. To see the register entry, book a demo.
Usually. The exemption for organisations employing fewer than 250 people ceases to apply if processing is not occasional, poses a risk to data subjects or involves special category or criminal offence data. Personnel administration or a client database is not occasional. The Autoriteit Persoonsgegevens writes that processing is rarely occasional in practice. Anyone with staff or regular clients therefore almost always keeps a record.
For controllers, there are seven components: name and contact details, processing purposes, categories of data subjects and personal data, categories of recipients, transfers to countries outside the EEA, retention periods and a general security description. The last two say “where possible”. A processor keeps a shorter record with four components.
This article includes a fictional entry for an AI assistant searching client files, with all seven statutory fields and some optional ones. Use the structure and enter your own details. Retention periods, recipients and transfers vary by provider and plan. Take them from your own contract and settings, with a reference date.
No. You do not need to submit or publish it. You must be able to make it available when the supervisory authority asks. It must therefore exist, in written or electronic form, and be up to date when requested.
The organisation. According to the Autoriteit Persoonsgegevens, the processing overview is the organisation's own responsibility, not a data protection officer's task. The DPO supervises the record and can advise. In practice, a privacy officer or operations employee often manages the document, with an owner for each entry from the department carrying out the processing.
The law specifies no interval. The record must reflect what you do, so every new processing activity, tool, supplier or retention period means a change. In practice, a regular check works, for example quarterly for entries involving an external supplier and annually for the rest. AI tool terms and sub-processors change regularly, so add a reference date to those entries.
The AI Act timeline after the digital omnibus: what applies already, what has moved to 2027 and 2028, and what AI chatbot users need to arrange now.
What a deepfake is, which rules apply now, which prohibition is coming and how organisations tackle fraud using a fabricated voice or video.
What the Dutch Algorithm Register and IAMA are, what is mandatory and what is not, and what a municipality arranges when staff use AI chatbots.
We show it with fictitious client files from your sector: upload, detection, review, search and the connection with your AI assistant. Afterwards you'll know exactly what your team can use safely.
Book a demo →