ROPA software can make records of processing activities easier to maintain, but it cannot discover a lawful purpose or decide a controller’s role simply by scanning systems. Article 30 GDPR requires a written record, including electronic form, with different fields for controllers and processors. A well-managed spreadsheet can meet that requirement. The buying question is whether a tool helps the people who own processing activities keep the record accurate as services, recipients and decisions change. This guide gives buyers one repeatable trial and a way to compare a dedicated ROPA product, a broader privacy platform and their existing method. It does not offer invented market prices or claim that a supervisory authority always asks for the record first.
Start with three imperfect activities rather than a vendor’s sample dataset: employee recruitment, customer support and a service your organisation provides for another controller. For each, note the owner, systems, recipients, retention decision and missing facts. One activity should involve a processor and another a possible third-country access route. Ask candidates to model the same facts, show uncertainty and export an understandable record. The complete ROPA guide explains the underlying obligation; this page is about selecting the system that will keep it usable.
Establish the right Article 30 scope
Article 30 GDPR separates the controller record in paragraph 1 from the processor record in paragraph 2. A company may need both when it controls employee information and processes client data as a service provider. The tool must allow different field sets and client-scoped views rather than presenting one undifferentiated “processing” card. A service provider should be able to produce its record of categories of processing carried out on behalf of each controller without showing one client another client’s information.
The under-250 exception in Article 30(5) is not a blanket exemption for a small business. For a particular activity it does not apply when processing is not occasional, is likely to result in a risk to individuals’ rights and freedoms, or includes Article 9 special-category or Article 10 conviction/offence data. Regular employee or customer work is generally not occasional. An isolated event still needs a check of the other triggers. Software should record the reason for a conclusion rather than turning an employee count into a legal answer. The Article 30 data-fields template helps expose gaps without claiming that every optional management field is mandatory.
A ROPA is made available to the supervisory authority on request under Article 30(4). The law does not impose a particular vendor export format or require an authority to request it first in every investigation. That distinction matters in procurement: demand a complete, legible export with the statutory content, and check it against your source information. A tool’s “audit-ready” label is not evidence that the fields or facts are right. A ROPA template can also produce a compliant record when it is maintained; the software decision is about ongoing coordination and proof of changes.
Test the controller and processor field models
For a controller, Article 30(1) calls for its name and contact details, those of any joint controller, representative and DPO where applicable, purposes, categories of data subjects and personal data, categories of recipients including those in third countries, transfers and relevant safeguards, envisaged erasure time limits where possible, and a general description of security measures where possible. Ask the vendor to show which fields are statutory and which were added for internal management. Legal basis is a useful accountability field but is not itself listed as an express Article 30(1) field. A compulsory “consent” default for every activity would be more harmful than a blank field.
For a processor, Article 30(2) includes the names and contacts of the processor and each controller for whom it acts, the categories of processing carried out for each, transfers and relevant safeguards, and a general description of security measures where possible. Do not copy the controller purpose and data-subject fields into this record as if the law imposed an identical model. Additional fields can still help, provided the output distinguishes required content from operational context. In the trial, let the service team open two client records and ask whether an export, access control and deletion of a mistaken attachment remain scoped to the right client.
Supplier roles also need human analysis. The same organisation may be a processor for hosting, an independent controller for its own billing, or part of a more complex relationship for another service. Do not let a product infer role from the word “vendor.” Record who determined purposes and essential means, what service is actually provided and which agreements apply. The controller-versus-processor guide is a useful companion to the Article 28 guide; the ROPA should link a reviewed contract, not declare a relationship lawful just because a PDF was uploaded.
Run a change that a spreadsheet could also handle
A small, disciplined team can keep a spreadsheet current with a named owner, protected storage, version history and a process for reporting changes. It is inaccurate to claim that spreadsheets never have version control or can never evidence an earlier state. They can fail when multiple departments keep diverging copies or when no one verifies that a system change affects the record. A platform can fail in exactly the same way if its reminders go unanswered. In the trial, give both methods the same supplier change and compare what remains understandable to someone who did not make the edit.
The fictional customer-support team moves from one ticketing provider to another. The new provider proposes a subprocessor and offers remote support from a third country. Ask the candidate to update recipients, document the potential transfer question, link the supplier review and identify any changed retention or security assumptions. The system should show what was known before the move, what evidence came from the supplier and who approved the final description. A global green tick without those facts is not a maintained record. The international-transfer guide may help the separate Chapter V assessment, but the ROPA must not silently conclude that hosting in the EU settles all access questions.
Add a second change: support wants to reuse old tickets to train an automated assistant. That is not just a new tool name. Someone must consider purpose compatibility, the Article 6 basis, transparency, retention, security and whether a DPIA is needed because the planned processing is likely to be high risk under Article 35. The record can direct the owner to a DPIA decision guide; it should not automatically create a legally completed assessment for every change. Test whether a rejected proposal stays visible as a dated decision, rather than disappearing from the history when a task is closed.
Now introduce uncertainty. The buyer cannot yet identify the support region or the final subprocessor. A useful system keeps that field unresolved with an owner and review date. It does not fill a placeholder with “EU” to satisfy a completeness score. A spreadsheet can capture uncertainty too, if the team has a convention for it. Judge the tool by whether the unresolved point is acted on and whether the record is corrected once facts arrive.
Compare four approaches against that trial
A maintained template is the baseline. It costs licence-free effort but can be appropriate for a few stable activities and one accountable editor. A dedicated ROPA product may standardise statutory fields and gather confirmations. A broader privacy platform may connect activities with processors, DPIAs, rights requests and incidents. A GRC platform may offer group-level controls and approval trails, but must still represent the exact Article 30 content. None is inherently compliant or non-compliant. The record-of-processing guide covers substance; the manual ROPA cost method helps estimate your existing work rather than asserting that software always saves money.
Vendors including Dastra, TrustArc and OneTrust describe relevant privacy-management products. These are first-party descriptions, not a demonstration that the offered tier imports your file, produces a client-scoped processor record or preserves export history. Ask each supplier to complete the same trial. Avoid a leaderboard based on unrelated feature counts or an assumed price by employee size. A different bundle, onboarding plan or contract may change the comparison.
Measure the time to create and revise each of the three activities, the number of unresolved points correctly flagged, the ability to reconstruct a previous version and the usability of an exit export. Include internal hours spent identifying activities, reconciling suppliers and reviewing legal bases. Licence, configuration, integrations, read-only seats, storage, support and migration are separate quote lines. The EU software-cost guide may help structure those lines; do not treat published bands as a current vendor offer. A broader software overview can help identify categories to trial, but its brand order is not evidence that any product fits this ROPA test. A quote with a low headline price but expensive export work may be dearer over the intended life of the system.
Migration is an accuracy project, not a file upload
Preserve a dated copy of the old ROPA before cleaning it. Look for duplicate activities, missing owners, outdated providers and free-text labels that conceal different roles. Decide whether an old activity ended or its name changed; keeping the historical mapping can matter when explaining a past period. Test import on three deliberately messy rows, not on a perfectly arranged vendor template. Ask who approves a corrected record and how the imported source version is identified. Do not assume a universal half-day migration or a vendor-specific connector without proof.
A legal basis or contract reference may be stored in the old spreadsheet but not in the vendor’s mandatory fields. Confirm what happens to those extras. Conversely, if a supplier label is imported as a recipient without role review, the new interface can make a mistaken assumption look official. Map each legacy column to a required field, optional management field or investigation task. Keep a list of discarded columns and why they were discarded. The processor relationship guide can help an operational reviewer recognise when “supplier” is too broad a category.
After import, export the whole register and one limited view. Check dates, identities, transferred attachments and the history of approval. Have a colleague who lacks an administrator licence read the export and explain the changed supplier. Ask what happens when the subscription ends: file format, access period, assistance charges and deletion or return of hosted materials. A dataset stored inside the tool may also contain employee names, incidents and sensitive free text; Article 32 security and access limits still matter. The security and privacy principles guide provides context, while the contract must specify the real service.
Maintain the record after launch
Set a trigger for business changes: new supplier, new purpose, service retirement, change of controller, changed transfer route or retention decision. The owner of each activity should confirm facts; a privacy lead can review legal implications; management can resolve resources. A quarterly review may be a useful internal habit, but Article 30 does not prescribe one universal calendar. Review quickly when a material change occurs. A beautiful annual export assembled from stale answers would not satisfy the purpose of a current record.
Do not claim that an automated scan can determine why personal data is used. Discovery of a database can reveal a system and perhaps a data category. It cannot reliably establish purpose, legal basis, recipients, retention or the actual controller relationship without business context. Automation is most valuable for routing a question, proposing a change and keeping the decision traceable. Privacy by design also requires decisions at design time, before the processing becomes a row in a report.
Finally, separate a ROPA from an erasure engine. The record can state envisaged erasure time limits where possible and link to a retention decision; actual deletion occurs in the systems holding data and may have legal exceptions. It can show that a processor contract exists, but Article 28 permits either a written contract, including electronic form, or another binding Union or Member State legal act with the required content. Review instructions, confidentiality, subprocessors, assistance and return or deletion rather than treating “file attached” as the end of diligence.
Questions buyers ask
Is a ROPA tool required by the GDPR?
No. Article 30 requires a written record, which can be electronic, and availability on supervisory request. A maintained spreadsheet can work. A tool is worth testing if owners, versions or group structures make manual control difficult.
Does the under-250 exception remove our record duty?
Not for every activity. It does not cover processing that is non-occasional, likely to pose risk to people, or includes Article 9 or 10 data. Document the particular activity and each trigger; do not base the answer on headcount alone.
Does a processor use the same ROPA fields as a controller?
No. Article 30(2) has its own client-oriented field model. A firm that acts in both roles needs distinct entries or views and an export that does not disclose another client’s information. Internal additions are fine if they are identified as such.
What should the vendor demonstrate first?
A change in supplier, purpose or transfer facts, followed by a complete export. If the tool cannot show what changed, who checked it and which question remains open, more dashboard modules will not make the register accurate.
Buy for maintenance and a credible exit
The strongest ROPA system is the one your organisation can keep truthful and explain after staff or suppliers change. Compare your spreadsheet and candidate tools on identical imperfect activities. Demand statutory fields, role separation, source-backed revisions and a usable export. Purchase only when the improvement in maintenance and coordination is clear for your team, not because a seller claims a spreadsheet is inherently unlawful.