Guides

Record of processing activities (GDPR Article 30): what to include and when to run a DPIA

By the NexoDocs Team · how we make and check our content

A record of processing activities (ROPA) lists everything an organization does with personal data: why it uses it, whose data it is, which data, who receives it, whether it leaves the country, how long it is kept and how it is protected. The GDPR requires it in Article 30 for both controllers and processors, with a narrow exemption for organizations with fewer than 250 people. It is also the foundation of ISO/IEC 27701 and of the data protection impact assessment (DPIA), which Article 35 requires when processing is likely to result in a high risk to people. This guide is for information only and is not legal advice.

Which columns the controller's record needs

GDPR Article 30(1) lists the minimum content. The most practical format is a spreadsheet with one row per processing activity (for example "payroll", "online store customers", "CCTV") and these columns:

Beyond the legal minimum, add the lawful basis of each activity, the system where the data lives, the internal owner and whether a DPIA is required: the same record then helps you answer data subject requests and pass audits.

The processor's record

If your company processes data on behalf of customers (for example a SaaS provider or a payroll bureau), Article 30(2) requires its own record with: your name and contact details and those of each controller you act for, the categories of processing carried out for each, international transfers and a general description of security measures. Many companies are both controllers (of their own staff and customers) and processors (of their customers' data), and need both records.

The template, ready to use

ISO 27701 Toolkit: documentation for your privacy management system

38 Word documents · 15 Excel tools · 78 Annex A controls

See the ISO 27701 toolkit with ROPA and DPIA templates

Who is exempt?

Article 30(5) exempts organizations with fewer than 250 people, but only if the processing is unlikely to result in a risk to data subjects, is occasional and does not include special categories of data or criminal convictions data. Payroll and customer databases are not occasional, so in practice almost every active business must keep a record, at least for those activities.

Other laws ask for something equivalent: the UK GDPR keeps the same Article 30 duty, and Brazil's LGPD (Art. 37) requires controllers and operators to keep records of their processing operations.

When you need a DPIA

GDPR Article 35 requires a DPIA before processing that is likely to result in a high risk to people's rights and freedoms. It names three cases where one is always required:

• Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that produces legal or similarly significant effects.
• Large-scale processing of special categories of data or of criminal convictions and offences data.
• Systematic monitoring of a publicly accessible area on a large scale (for example extensive CCTV).

Supervisory authorities publish lists of processing that requires a DPIA. A DPIA must describe the processing and its purposes, assess necessity and proportionality, assess the risks to people and set out the measures to reduce them (Art. 35(7)). If the residual risk stays high, you must consult the authority before starting (Art. 36). The "DPIA required?" column in your record is where you spot these cases.

How it fits ISO 27701

ISO/IEC 27701:2025 asks for a privacy information management system that identifies and documents personal data processing, assesses its risks and applies controls for the controller role and the processor role. A complete record and a DPIA method are the core evidence of that system, and they serve the GDPR and other privacy laws at the same time.

• Keep a single record and mark on each row whether you act as controller or processor.
• Review the record whenever a system, supplier or purpose changes, and at least once a year.
• Link each row to its risk assessment or DPIA, its processor contracts and its privacy notice.

Common mistakes

• Building the record per system ("the ERP", "the CRM") instead of per purpose: one system usually supports several activities with different retention periods and lawful bases.
• Writing retention as "indefinite" or "as long as necessary" without a criterion.
• Forgetting cloud providers as recipients and their international transfers.
• Filling it in once and never updating it: the record must reflect current processing.
• Not flagging special categories of data, which change the available lawful bases and the need for a DPIA.

Next step

Try it free or go straight to the complete solution.

ISO 27701 Toolkit: documentation for your privacy management system

38 Word documents · 15 Excel tools · 78 Annex A controls

See the ISO 27701 toolkit with ROPA and DPIA templates

Free sample

Download a reduced version of the toolkit's risk matrix for free (Excel, 10 scenarios, heat map). See how it calculates risk level and category before you decide.

Get the free sample

Frequently asked questions

Related guides

Updated: 2026-10-25