What an Article 30 register actually has to contain, the kinds of tool that claim to maintain one, and the questions that separate them.
RoPA software maintains the Record of Processing Activities that GDPR Article 30 requires — the register of every distinct processing activity, its purpose, the categories of data subjects and personal data, recipients, third-country transfers, retention periods and security measures. The thing to evaluate is not whether a tool can store that register but whether it can keep it true: a RoPA describes a moving system, so any tool that depends on someone remembering to update it after each release will be wrong most of the year. Ask where the facts come from, how change is detected, and whether the tool can produce a per-entity export a supervisory authority would accept.
Article 30(1) and 30(2) require different content. A tool that offers one generic register forces you to either over-document processor activities or under-document controller ones. Most software companies are both roles at once, so this is not an edge case.
A register populated entirely by hand is a record of what someone believed at the time they filled the form in. Ask whether the tool can discover systems, fields, subprocessors and hosting locations from your actual infrastructure, and what it does when those change.
Lawful basis, necessity and retention rationale are accountable decisions. The tool should record who made each one and when, and should not quietly infer them. Where legitimate interests is the basis, it should hold the balancing test alongside the entry.
Article 5(2) accountability means being able to demonstrate compliance. A register with no history cannot show that it was accurate at the time of an incident. Look for versioning, approval trails and a visible last-reviewed state per record.
Groups with several legal entities owe several registers. If you also fall under the UK GDPR or another regime, check whether the same underlying facts can produce each jurisdiction's register rather than being re-entered per regime.
Four shapes of vendor, described by category rather than by name. Which one fits depends on how fast your systems change and how much judgement you need to buy in.
Large, modular GRC platforms that cover most regimes through separately licensed modules, usually with a long implementation and a dedicated administrator.
Best fit: Large organisations with a compliance team big enough to own configuration, and budget that tolerates a multi-module licence.
Focused products that do one job well — consent, DSAR intake, cookie scanning, vendor questionnaires — and integrate loosely with whatever else you run.
Best fit: Teams with one acute, well-bounded problem, who accept that the register tying everything together lives somewhere else.
People rather than software: an external DPO or advisory retainer that produces the documentation on your behalf, often in documents you then own.
Best fit: Organisations without in-house expertise who need judgement more than tooling, and who can accept that the output is a snapshot.
Systems that connect to what you already run, derive the records from live signals, and keep them current between audits rather than regenerating them before one.
Best fit: Teams whose systems change faster than documents can be maintained by hand, and who need to evidence a current state on demand.
Noru derives the factual layer of the Article 30 register from the systems that hold the data: personal data is annotated in code against an open privacy taxonomy, pushed from CI, and materialised into records that update when the code does.
Judgement stays with people. Lawful basis, necessity and retention are reviewed and attributed, with the reviewer and date recorded against the entry rather than inferred.
Because the facts are described once in a shared vocabulary, the same underlying map produces the register for each jurisdiction you operate in instead of a separate documentation exercise per regime.
Software that builds and maintains the Record of Processing Activities required by GDPR Article 30 — the internal register of how an organisation processes personal data, kept current and producible to a supervisory authority on request.
A spreadsheet is legally sufficient — Article 30 requires the record to exist in writing, not to live in a particular tool. It stops being practical when the number of processing activities exceeds what one person can reconcile after every release, or when several entities and jurisdictions each need their own register from the same facts.
For controllers: the purposes of processing, categories of data subjects and personal data, categories of recipients, third-country transfers and their safeguards, retention periods where possible, and a general description of security measures. Processors keep a shorter record of the categories of processing carried out for each controller, transfers and security measures.
Whenever processing changes. There is no fixed interval in the regulation — the obligation is accuracy. In a business that ships software continuously, that means the register should react to change rather than wait for an annual review.
The factual layer can be derived: which systems exist, what fields they hold, which vendors receive data and where it is hosted are all observable. The judgement layer — lawful basis, necessity, retention rationale — should be reviewed by a named person, because it is exactly what a regulator will probe.
It should. The UK GDPR carries an equivalent Article 30 obligation, so the same facts ought to produce both registers. If a tool requires you to maintain them as separate documents, that is duplicated work and a source of drift.
Regulatory references on this page were last checked on .
A 45-minute walkthrough against your frameworks, your integrations and your evidence.
