Research
RoPA Software Compared: What to Look For
To compare RoPA software, score every tool on Article 30(1)/(2) field coverage, multi-entity scoping, evidence traceability, version history, and a Schrems II transfer view — the criteria a supervisory-authority inspection actually tests. Tooling falls into three categories — a spreadsheet-led register, a heavy enterprise suite with a RoPA module, and a governed, assessment-fed platform — and the category you choose determines which of those criteria the tool can actually pass. The deciding factor is never how the form looks; it is whether the register can show that each entry is true, current and accountable when a regulator asks. This article sets out the criteria, scores the three categories against them, and explains why no category is automatically compliant.
Key takeaways
- Compare on the criteria an inspection tests: Article 30(1)/(2) coverage, legal-entity scoping, evidence traceability, reviewer-attributed version history, a per-transfer Schrems II view, EU+UK overlays, and a self-contained export — not on the slickness of the form.
- The market splits into three categories: a spreadsheet-led register (cheap, no provenance), a heavy enterprise suite with a RoPA module (integrated, slow to configure, often still manual), and a governed assessment-fed platform (drafts from approved assessments, human approves).
- No category is automatically compliant. A carefully maintained spreadsheet can satisfy a regulator for a small, stable register, and a governed platform left un-reviewed can still drift — the category only changes how hard each inspected criterion is to evidence.
- The honest test is provenance over storage: can the tool show where each value came from, who approved it, and what changed — and produce that as a record the regulator can read without a login.
For the underlying obligation — what a RoPA is, what Article 30 requires, and how an assessment-fed register works — see the pillar guide on RoPA software: what it is and how it works.
How should you compare RoPA software?
Compare RoPA software against what a supervisory-authority inspection tests, because that is the only benchmark that matters when the register is requested. A vendor demo optimises for the first ten minutes; an audit optimises for whether the record holds. The criteria that separate a tool that passes a demo from one that passes an inspection are consistent across the EU and UK GDPR:
- Full Article 30(1) and 30(2) coverage — both controller and processor record types, each with the dedicated fields it requires, not a single generic table.
- Legal-entity scoping — separate records by entity, country and business unit while keeping group-level visibility, with an entity snapshot preserved at approval time.
- Evidence traceability — every field links back to the assessment, contract or system that produced it, so a claim can be substantiated rather than merely asserted.
- Reviewer-attributed version history — what changed, who changed it, who approved it, and when.
- A Schrems II transfer view — per transfer, the Chapter V mechanism, the linked Transfer Impact Assessment and the supplementary measures, after Schrems II (C-311/18).
- EU and UK GDPR overlays — the ability to distinguish the two regimes (and national overlays where relevant) correctly on one register, which is a granularity signal a single-regime tool cannot claim.
- A self-contained export — a record the regulator can read without a login to your platform.
Jurisdiction overlays are listed here as one rigour signal among several, not the headline. A tool that handles EU and UK GDPR correctly demonstrates field-level granularity, but it is the provenance criteria — traceability, version history, transfer evidence — that decide an audit. For the full requirements behind these criteria, see the RoPA requirements guide for Ireland and the UK.
What are the three categories of RoPA software?
RoPA tooling falls into three categories, and the category determines which problems the tool actually solves. Understanding the trichotomy matters more than comparing individual vendors, because the structural trade-offs travel with the category.
1. Spreadsheet-led register
The most common starting point: the register lives in a shared spreadsheet or a document template, with columns for purposes, data categories, recipients, transfers, retention and security measures.
Strengths: Free or near-free, immediately familiar, and adequate for a single entity with a small number of stable processing activities.
Limitations:It stores only what someone last typed. There is no provenance, no approval chain, and no preserved version history, so it cannot show where a value came from or what changed. It drifts from accurate the day it is written, and a drifted register reads to a regulator as weak Article 5(2) accountability. Multi-entity scoping and a per-transfer Schrems II view are the first things it cannot do.
2. Heavy enterprise suite with a RoPA module
Broad governance and privacy suites bundle a RoPA module alongside data mapping, consent, vendor-risk and incident features. The register is one capability inside a much larger product.
Strengths: Integrated with the wider programme, with workflow routing, approval chains and audit trails. Suited to large organisations that want to consolidate many tools and already have a privacy team to run the configuration.
Limitations:High cost and implementation complexity. Because the RoPA module is one feature among many, configuration can run into months, and evidence reuse across the suite is often limited. The register frequently remains a manual data-entry surface — the platform routes the workflow, but the content quality still depends on whoever fills in the fields.
3. Governed, assessment-fed platform
A platform that treats the register as a downstream output of approved assessments. Each Article 30 field is derived from work already done — DPIAs, legitimate-interest assessments, vendor reviews — with a link back to the source response, and a named reviewer approves every record before it is published.
Strengths:Provenance is built in. Each field is traceable to its evidence, every version is retained, transfers carry a Chapter V view, and the export is self-contained. Keeping the register true between reviews is the design goal rather than an afterthought.
Limitations:It depends on the assessment programme feeding it, so it works best where assessments are actually run, and it requires the human-approval discipline to be honoured — the AI drafts, classifies and surfaces, but a person approves and nothing publishes itself. It must also integrate with the rest of the privacy stack.
RoPA software compared: spreadsheet vs enterprise suite vs governed platform
The same processing register built in each category produces a very different record under inspection. The table below maps the three categories against the criteria a supervisory authority tests. It scores the categories, not named vendors — the structural trade-offs belong to the category, and a specific product may sit better or worse than its category norm.
| Criterion an inspection tests | Spreadsheet-led register | Heavy enterprise suite (RoPA module) | Governed assessment-fed platform |
|---|---|---|---|
| Article 30(1)/(2) field coverage | Manual columns; processor (30(2)) record usually improvised. | Both record types, but configured by hand during setup. | Both record types modelled, scoped by operating role (controller / joint controller / processor / sub-processor). |
| Legal-entity scoping | One sheet per entity, no group view; snapshots lost. | Supported once configured; setup-dependent. | Single entity to multi-entity group with per-entity exports and an entity snapshot at approval time. |
| Version history (reviewer-attributed) | Overwritten in place; earlier versions lost. | Yes — versioned within the workflow. | Yes — what changed, who changed it, who approved it, and when. |
| Evidence traceability (field to source) | None — values are asserted, not sourced. | Possible via integrations once configured (months). | Each field links back to the assessment, contract or system that produced it. |
| Schrems II transfer view (C-311/18) | A free-text “transfers: yes” cell at best. | Module-dependent; often a separate transfer register. | Per transfer: mechanism, linked TIA and supplementary measures. |
| EU + UK GDPR overlays on one register | Single regime; a second regime means a second file. | Configurable; depends on the regional packs licensed. | EU and UK GDPR (and national overlays where relevant) distinguished on one register. |
| Self-contained export (no regulator login) | Yes — a static file, but no approval history. | Usually yes, sometimes only viewable inside the SaaS. | Bundles activities, evidence references, versions and approval history per entity. |
No category is automatically “compliant.” A spreadsheet-led register maintained with real discipline can satisfy a regulator for a small, stable estate, and a governed platform whose drafts are rubber-stamped without scrutiny can still produce a weak record. The deciding factor is whether the tool makes the inspected criteria easy to evidence as the register grows in entity count, transfer complexity and assessment volume. See the Article 30 template for the mandatory controller and processor fields any of these categories has to capture.
Why provenance beats storage in a RoPA tool
Provenance — knowing where each value came from — is the dividing line between the three categories, and it is what an audit probes first. When a supervisory authority asks to see the register, the question is not “do you have a document” but “can you show this is true, current and accountable.” A spreadsheet answers the first and fails the second; a governed register answers both because it keeps each field's source, its approval chain and its version history.
This is also the honest meaning of RoPA automation. Automation should reduce the typing and the chasing, not the accountability: the AI drafts, classifies and surfaces records for review, and a named person approves, edits or rejects each one before it reaches the published register. Nothing publishes itself. For where that line should fall — what a RoPA tool should and should not automate — see RoPA automation: what it should and shouldn't automate.
How the Acompli RoPA register fits these criteria
Acompli sits in the third category — a governed, assessment-fed register — with a specific design choice: every Article 30 field is derived from an approved assessment and stays traceable to the evidence behind it. Approved DPIAs, legitimate-interest assessments and vendor reviews are read by a multi-phase AI extraction pipeline that drafts the relevant fields with a confidence score and a link to the source response; a named reviewer approves, edits or rejects each draft before it is published.
The register maintains both Article 30(1) and 30(2) records on one platform, scoped by legal entity and operating role, with an entity snapshot kept at approval time, reviewer-attributed version history, a per-transfer Chapter V view, and a self-contained per-entity export. See the RoPA management module for how the register works in the platform, and the pillar guide on RoPA software for the wider picture.
Common questions about comparing RoPA software
How should organisations compare RoPA software for an Article 30 audit?
Score every tool on the criteria a supervisory-authority inspection actually tests, not on how the form looks. The deciding ones are full Article 30(1) controller and 30(2) processor field coverage, legal-entity scoping for groups, evidence traceability from each field back to its source assessment, reviewer-attributed version history, a Chapter V transfer view that holds the Schrems II safeguards, EU and UK GDPR overlays on one register, and a self-contained export the regulator can read without logging into your platform. A tool that only exports a flat spreadsheet passes a demo and fails an audit, because the auditor's first question is not whether you have a document but whether you can show it is true, current and accountable.
What features make the best RoPA software?
The features that matter are the ones that survive scrutiny: both Article 30(1) and 30(2) record types with their distinct fields, an entity snapshot preserved at approval time so historical records reflect the structure that existed then, a link from each field back to the assessment or contract that produced it, a full change-and-approval trail, and a per-transfer Chapter V view after Schrems II (C-311/18). 'Best' is contextual rather than a ranking — a tool is best for an organisation when it makes those inspected criteria easy to evidence at that organisation's scale. A single-entity controller and a twelve-entity group with onward processors have different best answers.
Is a dedicated RoPA tool better than the RoPA module in a large suite?
Both can produce a compliant register; the trade-off is depth versus breadth. A RoPA module inside a broad governance suite — PrivacyEngine, DataGrail or Symbiant are illustrations of the suite category, not a ranking — benefits from existing data-mapping and vendor-risk integrations, but the register is one feature among many and configuration can run into months. A dedicated, assessment-fed platform tends to invest more in the register itself — evidence grounding, version history, transfer views, audit-ready export — and ships faster, but must integrate with the rest of the privacy stack. The right answer depends on whether your bottleneck is keeping the register true between reviews or consolidating wider programme tooling.
What is the difference between RoPA software and a spreadsheet?
A spreadsheet stores what someone last typed; RoPA software knows where every value came from. The software keeps each field's source assessment, who approved it and what changed, preserves every version, and surfaces records for review when the business changes — the things a shared file cannot do, and the first things an auditor asks about. A spreadsheet is accurate the day it is written and drifts from then on, and a register that has drifted reads to a regulator as weak Article 5(2) accountability rather than as compliance.
Does the tool handle controller and processor registers?
It should — and this is a common gap. Article 30(1) requires a controller record and Article 30(2) requires a separate processor record with its own fields, including the categories of processing carried out on behalf of each controller and the controller's identity. Many tools model only the controller record well. In Acompli both record types live on one platform, scoped by legal entity and operating role (controller, joint controller, processor, sub-processor), with an entity snapshot kept at approval time so a record stays faithful to the structure that existed when it was approved.
How does RoPA software keep the register current between formal reviews?
The strongest tools make the register a downstream output of work already being done rather than a separate data-entry chore. In Acompli, approved assessments — DPIAs, legitimate-interest assessments, vendor reviews — are read by an AI extraction pipeline that drafts the relevant Article 30 fields with a confidence score and a link to the source response; a named reviewer approves, edits or rejects each draft before it reaches the published register. When an upstream fact changes — a new supplier, a retired system, an updated transfer safeguard — the affected records surface for review with the change that triggered them. The AI drafts, classifies and surfaces; a person approves, and nothing publishes itself.
Does the tool give a per-transfer Schrems II view of international transfers?
It should hold a Chapter V view for each transfer, not a single free-text 'transfers: yes' field. After Schrems II (C-311/18) the register needs to record, per transfer, the mechanism (adequacy, standard contractual clauses or a derogation), the linked Transfer Impact Assessment, and any supplementary measures. A tool that cannot attach a TIA and supplementary measures to a specific transfer cannot evidence that the safeguard was actually assessed — which is the point a supervisory authority probes when transfers appear in the register.
Can the tool produce an export a regulator can read without logging into the platform?
This is the test a slick demo often hides. When a supervisory authority requests the register, it expects to receive a self-contained record — the activities, the linked evidence references, the version and approval history — not credentials to log into a vendor SaaS. If the export is incomplete or only viewable inside the platform, the controller has not in practice produced the record it is obliged to provide. A self-contained, per-entity export lets each legal entity answer its own supervisory authority without exposing the whole group's register.
Does the tool scope a register across multiple legal entities and jurisdictions?
Multi-entity scoping is where spreadsheets and single-regime tools fail first. A group needs separate records by legal entity, country and business unit while keeping group-level visibility, and it needs to distinguish EU GDPR from UK GDPR (and, where relevant, national overlays such as the German BDSG) correctly on one register. Acompli scopes from a single entity up to a multi-entity group with per-entity exports, so each subsidiary can answer its own regulator while the group keeps one consolidated view.
Is paying for RoPA software worth it when a free spreadsheet template exists?
A free template can hold a register on day one; the cost shows up in maintenance and in audit. The recurring work is keeping the register true as systems, suppliers and transfers change, proving where each value came from, and producing a defensible export on request — exactly what a flat file cannot do. For a single entity with a handful of stable activities, a carefully maintained template can suffice. As entity count, transfer complexity and assessment volume grow, the manual effort and the audit risk of a drifting spreadsheet outweigh the licence cost of a governed register.
Primary sources
Related research
RoPA Software
What RoPA software is, how assessment-fed drafting works, and what to look for.
Read article →RoPA Requirements: Ireland & UK
Article 30 requirements under the EU and UK GDPR, with the DPC and ICO compared.
Read article →Article 30 (RoPA) Template
The mandatory controller and processor fields, as a usable Article 30 template.
Read article →