A new client’s auditor asks for your record of processing activities before their company signs a data processing agreement. The data protection officer sends a spreadsheet created in May 2018. It still lists an HR system that was switched off two years ago, while a cloud CRM platform, a new accounting firm and a recruitment tool the HR team bought on its own are missing. The spreadsheet exists, but in practice there is no record.
The record of processing activities is an obligation under GDPR Article 30 and, at the same time, the simplest map of a company’s data: who processes personal data, for what purpose and in which system. Without that map, the team responsible for cybersecurity does not know which systems need the strongest protection, and after an incident it loses time working out whose data may have leaked. Every controller and every processor keeps a record, and the exemption for organisations with fewer than 250 employees is much narrower than the threshold suggests.
What is a record of processing activities?
A record of processing activities is a written inventory of the processes in which a company processes personal data, containing the information required by GDPR Article 30: purposes, categories of data subjects and data, recipients, transfers to third countries, erasure time limits and a description of security measures. It describes what the company does with data and why, not a list of files or databases.
Recital 82 of the GDPR gives the record two functions. The first is helping the controller itself comply with the Regulation. The second is enabling the supervisory authority to monitor processing, because the record is made available on its request. Both stem from the accountability principle in Article 5(2): the controller is responsible for complying with the processing principles and must be able to demonstrate that it does.
The GDPR does not define a “processing activity”. In its guidance on Article 30 (in Polish), the Polish supervisory authority, the President of the Personal Data Protection Office (UODO), treats it as a set of related operations on data that can be described collectively by their purpose. Recruiting employees is therefore one activity, even though it covers collecting CVs, shortlisting, interviews and deleting data of candidates the company did not hire.
Legal status as of 14 September 2026: GDPR Article 30 applies in its 2016 wording, unamended. Our GDPR guide gives a general overview of the Regulation’s obligations, and the GDPR glossary entry offers a short definition of the act itself. The guidance quoted here comes from the Polish authority; supervisory authorities in other EU countries publish their own templates and explanations.
Who has to keep a record of processing activities?
Every controller keeps a record, meaning the entity that, alone or jointly with others, determines the purposes and means of processing personal data (GDPR Article 4(7)). Its record covers all processing activities under its responsibility. When a controller based outside the EU has a representative in the Union, the representative keeps the record too.
A processor, meaning a company that processes data on behalf of a controller (Article 4(8)), keeps a separate record of all categories of processing activities carried out on behalf of controllers (Article 30(2)). This applies to accounting firms, cloud service providers, IT maintenance companies and backup operators. UODO points out that such a processor will as a rule keep both records, because it is itself the controller of its own employees’ data.
Where there are joint controllers, the obligation rests on each of them, and the description of the shared process should appear in each joint controller’s record, which UODO derives from the word “each” in Article 30(1).
The data protection officer is not the addressee of the obligation, although according to UODO the DPO can advise on the record (see who a data protection officer is).
Is a company with fewer than 250 employees exempt from keeping a record?
A company with fewer than 250 employees is exempt only partly, and only for processing that meets three conditions at once. Article 30(5) states that the obligations do not apply to such an organisation “unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10”.
In its position paper of 19 April 2018, the Article 29 Working Party explained that these conditions are alternatives and that any one of them alone triggers the obligation. The risk in question is any risk, not just a high risk. As an example, it described a small organisation that regularly processes data about its employees: such processing is not occasional and must be included in the record.
The practical effect is simple. An employer with a few dozen staff keeps a record at least for HR, payroll and ongoing customer service, and leaves out only activities that are genuinely occasional, low-risk and free of special categories of data. The Working Party added that for many micro, small and medium-sized organisations maintaining a record is unlikely to be a particularly heavy burden.
What do you have to include in the record of processing activities?
A controller’s record must contain seven groups of information listed in Article 30(1)(a) to (g) of the GDPR. The provision states that the record “shall contain all of the following information”:
- the name and contact details of the controller and, where applicable, the joint controller, the controller’s representative and the data protection officer,
- the purposes of the processing,
- a description of the categories of data subjects and of the categories of personal data,
- the categories of recipients, including recipients in third countries or international organisations,
- where applicable, transfers of personal data to a third country or an international organisation, including the identification of that country or organisation,
- where possible, the envisaged time limits for erasure of the different categories of data,
- where possible, a general description of the technical and organisational security measures referred to in Article 32(1).
You only need to give the controller’s and DPO’s details once, for example on a title page. UODO suggests this layout so that they are not repeated for each activity. Describe the purpose specifically: “calculating and paying salaries” says more than “HR”, and “handling complaints” more than “customers”.
A typical mistake with recipients is listing the company’s own departments. A recipient is anyone to whom personal data are disclosed (Article 4(9)), for example a processor or another controller. According to UODO, employees acting under the controller’s authority within its own structure are not recipients. The record therefore lists the accounting firm and the HR system provider, not the finance department.
How does a processor’s record of categories of processing differ?
A processor’s record is shorter and organised by service rather than by purpose. Article 30(2) requires the details of the processor and of each controller on whose behalf it acts, the categories of processing carried out for each controller, transfers to third countries and, where possible, a general description of security measures.
The record of categories contains no purposes, no categories of data subjects or data and no recipients. The guidance explains that the controller decides on the purposes and means of processing, so the controller describes them. It defines a category of processing as the type of service the processor performs at the controller’s request.
Among its examples, UODO lists storing a client’s data, including making backups, providing infrastructure, administration and maintenance services, archiving electronic data and destroying data carriers. For IT companies that maintain client systems, this is practical guidance: one entry corresponds to one service in the contract, not to one server.
How detailed should you make each processing activity?
You describe an activity at the level of a process linked to a single purpose, without listing individual operations on the data. UODO gives the example of “handling sales contracts”: that one entry is enough, without separate items for issuing an invoice, recording it in the VAT register or sending the JPK file to the tax office.
It makes sense to draw process boundaries according to the actual division of work. In a large company, the same guidance notes, HR and payroll are often two teams and two activities, while in a small one a single person may handle everything as one process. The record should reflect your organisation, not somebody else’s template.
A simple control rule works well: one entry means one purpose and one owner. If, within a process, data goes to several systems with different safeguards or to different providers, it is better to add that information in optional fields than to split the process into artificial fragments.
What extra information is worth adding beyond the Article 30 minimum?
Article 30(1) sets a minimum, not a closed list, so the record can contain fields that make it easier to demonstrate compliance. The guidance mentions the legal basis for processing, the source of the data, the IT system used, information about a completed impact assessment, the process owner and the details of sub-processors.
The “IT system” field has the greatest value for security. It links the record to the application inventory, so when an incident hits a specific system you can see straight away which activities and categories of data are affected. That makes it easier to assess whether the breach has to be notified to the authority, which under GDPR Article 33(1) happens, where feasible, not later than 72 hours after becoming aware of it.
The impact assessment field, in turn, quickly shows the high-risk processes for which the company has carried out, or should carry out, a data protection impact assessment (DPIA). The “process owner” field addresses the hardest problem of the record: who must report a change before the record becomes outdated.
Key takeaways:
- Every controller (Article 30(1)) and every processor (Article 30(2)) keeps a record.
- Regular processing of employee data always belongs in the record, even in a company with fewer than 250 staff.
- Recipients are the entities to which data are disclosed, not your own departments.
- The “IT system” field links the record to the IT inventory and speeds up breach assessment.
How do you describe security measures in the record?
You describe security measures in the record in general terms, with a reference to the documentation that holds the details. Article 30(1)(g) refers to Article 32(1) of the GDPR, which gives examples of measures: pseudonymisation and encryption, the ability to ensure the ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore access to data quickly after an incident, and regular testing of the effectiveness of safeguards.
According to the same guidance, the description can name the type of safeguard, for example access control based on a user ID and password, certificates or encrypted communication, and refer to a policy or procedure. For data in IT systems and data sent over public networks, the description should cover access control and cryptographic protection.
Two opposite mistakes spoil this part of the record: the whole security policy pasted into every entry, or the empty phrase “appropriate safeguards are in place”. UODO sets a clear test: the description must allow the controller, the processor and the authority to make an initial assessment of the measures applied.
In what form should you keep the record, and who can see it?
You keep the record in writing, including in electronic form (Article 30(3)), and make it available to the supervisory authority on request (Article 30(4)). You do not file it with the authority in advance, but you must be able to produce it during an inspection or proceedings.
The GDPR does not prescribe a layout, and UODO publishes record templates (in Polish) as an aid, not as the only correct model. A spreadsheet, a module of a compliance management system or a database are all acceptable if they contain the required elements.
A missing or incomplete record breaches the obligation in Article 30, which falls under Article 83(4)(a) of the GDPR. Infringements in this group carry fines of up to EUR 10,000,000 or, for an undertaking, up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. The indirect effect is often more important: without an up-to-date record it is hard to demonstrate accountability in any other matter.
How do you build and maintain the record step by step?
You build the record from processes and people rather than from a template, and you keep it current by tying it to the decisions that change processing. Article 30 does not say how often to update the record, so the frequency follows the pace of change in the company. The table below organises the work so that the record is evidence from day one rather than a declaration.
| Step | Who is responsible | Where the information comes from | Typical mistake | Evidence for the auditor |
|---|---|---|---|---|
| List of processes | process owners with the DPO or the person responsible for data protection | interviews with departments, organisation chart | process named after a department (“HR”) instead of a purpose | list of processes with owners and the date it was agreed |
| Mapping systems and providers | IT and procurement | application inventory, data processing agreements, invoices for cloud services | services bought by departments without IT involvement are missing | process → system → provider mapping |
| Article 30(1) elements | process owner | terms and conditions, contracts, retention policy | vague purpose, no erasure time limits | complete fields (a) to (g) for every process |
| Description of safeguards | IT or security team | policies, system configuration, test results | whole policy pasted into every entry, or an empty phrase | short description with a reference to the document |
| Assessing the Article 30(5) exemption | person responsible for data protection | Article 29 Working Party position paper | treating the whole company as exempt because of headcount | justification for every process left out |
| Update triggers | process owner and IT | change requests, new contracts, incidents | updating once a year “from memory” | change history with dates and authors |
The most effective trigger is the procurement and deployment process. Every new system that processes personal data, every new provider, new purpose or transfer of data outside the European Economic Area should start with a question about the record entry. Such a checkpoint in the change procedure is simpler than rebuilding the record from scratch every year.
How can nFlo help you organise your record of processing activities?
nFlo organises the record as part of the Comprehensive GDPR Review and Advisory service, which belongs to the “Governance, risk and compliance” area. The service covers an inventory of data processing, a review of data processing agreements, an assessment of technical measures, a gap analysis report, a prioritised remediation plan and documentation templates, including records of processing activities.
Combining the processing inventory and the assessment of technical measures in one review produces a record that describes both the processes and the safeguards, so it supports GDPR compliance and data security at the same time. nFlo does not provide legal advice: interpretive disputes are for the data protection officer or the company’s lawyer to settle. If the record in your organisation needs a review, contact us. More articles on data protection are collected in our GDPR knowledge base.
What else is worth knowing about records of processing activities?
Do you have to file the record of processing activities with the supervisory authority?
No. GDPR Article 30(4) requires you to make the record available to the supervisory authority on request, for example during an inspection. Nobody accepts or registers it in advance.
Can you keep the record in a spreadsheet?
Yes. Writing includes electronic form (Article 30(3) of the GDPR). A spreadsheet is enough if it contains every element of Article 30(1) or 30(2) and stays up to date.
Is the template published by the Polish supervisory authority mandatory?
No. UODO states that its templates should not be treated as the only correct models. What matters is a complete set of required elements for every process.
Who in the company is responsible for keeping the record?
The obligation rests on the controller or the processor, not on the data protection officer. In practice, every process needs an owner who reports changes.
Does a sole trader have to keep a record of processing activities?
The Article 30(5) exemption depends on the type of processing, not on the legal form of the business. If a sole trader regularly processes customer or employee data, that processing is not occasional and, according to the Article 29 Working Party, must be included in the record.
