Three approaches to GDPR compliance under Article 30. The spreadsheet your team updates twice a year. The OneTrust deployment your CFO will not approve. And a third option that does the boring half automatically and leaves the judgement half to you.
This piece is for the DPO who has either evaluated OneTrust and decided not to buy, or who is mid-deployment and finding it does not solve the underlying inventory problem. The promise of "automated RoPA" has been around for a decade and most of those promises were exaggerated. The realistic version of the third option is more useful than the marketed version.
What Article 30 Actually Requires
Two registers. Article 30(1) places an obligation on each controller to maintain a record of processing activities under its responsibility, capturing: the name and contact details of the controller, the purposes of the processing, a description of the categories of data subjects and categories of personal data, the categories of recipients to whom the personal data have been or will be disclosed, transfers to third countries with the safeguards relied on, the envisaged time limits for erasure of the different categories of data, and a general description of the technical and organisational security measures. Article 30(2) places a parallel obligation on processors to keep a record of all categories of processing activities carried out on behalf of a controller.
Article 30(5) exempts firms with fewer than 250 employees, except where the processing is likely to result in a risk to data subjects' rights, where the processing is not occasional, or where it includes special categories of data or criminal data. The exception is narrower than people remember; for any firm operating an AI inventory of meaningful scale, the exemption rarely applies.
The supervisory expectation across European data protection authorities has been consistent since 2018: the RoPA GDPR must be kept up to date. The interpretation of "up to date" is not formally defined but in practice the DPC, the CNIL, and BfDI have all signalled that a register reviewed annually is borderline, a register reviewed quarterly is acceptable, and a register that lags significant changes (new SaaS tools, new processing activities, new sub-processors) by more than a single quarter is exposed.
The Spreadsheet RoPA
The honest assessment is that spreadsheets are not bad. They are appropriate for some firms and inappropriate for others, and the choice depends on the firm's processing activity count and rate of change.
What spreadsheets do well. The data model is recognisable to anyone who has worked with a RoPA before. The cost is zero beyond the DPO's time. The format adapts to the firm's specific structure. For a small firm with twenty processing activities and a low rate of change, a well-maintained spreadsheet is genuinely sufficient.
Where spreadsheets struggle. Three failure modes recur. Version control: as soon as more than one person touches the file, the question of which version is current becomes operational overhead. Single source of truth: the spreadsheet entry references vendors and systems that are recorded elsewhere, in the procurement system, in the SSO directory, in the contract repository, and those external records change without the spreadsheet updating. Maintenance frequency: spreadsheets are updated under audit pressure. Between audits, they decay.
When the spreadsheet is enough. Firms with under fifty processing activities, low rate of change, a single DPO (or a DPO and a clear deputy), and limited cross-system integration. For everyone else, the spreadsheet is a baseline that the firm has outgrown, and the gap between what the spreadsheet shows and what the firm's actual data processing register should contain is where GDPR compliance failures begin.
OneTrust, Securiti, and The Documentation Platforms
OneTrust is the category leader for good reasons, and a fair piece on the alternatives has to acknowledge them.
What OneTrust does well. A unified privacy management platform covering RoPA, DPIAs, data subject access requests, vendor risk, consent management, and adjacent compliance domains. For a large enterprise with the staffing capacity to configure the platform deeply and the integration budget to connect it to the firm's broader systems, OneTrust is genuinely powerful. Securiti and BigID occupy similar territory with different emphases, Securiti more on the data discovery side, BigID strong on data classification.
Where the deployment cost lives. The platforms are configurable to a fault. The RoPA module relies on the firm telling it what processing activities exist; the data discovery layer is more sophisticated than spreadsheet alternatives but still requires substantial input data to operate well. The platform's own documentation explicitly assumes a deployment programme rather than a self-serve adoption. For mid-market firms, the published-list pricing typically lands in the €60,000 to €200,000 per year range plus implementation, and the implementation is usually a six-to-twelve-month engagement with internal effort or a partner.
When OneTrust is the right answer. Large enterprises with dedicated privacy programme staffing. Firms with substantial multi-jurisdictional operation where the DPIA, DSAR, vendor risk, and consent functions all need integration. Firms where the privacy team is deep enough to operate the platform's full capability. For these firms, OneTrust is genuinely the right tool, and pieces like this one should not pretend otherwise.
When OneTrust is not the right answer. Mid-market firms where the privacy function is one DPO with one or two deputies. The platform's depth becomes deployment overhead. The firms that evaluate OneTrust and walk away are not making a mistake, they are recognising that the tool is not sized to their operating model, and that their privacy governance needs are better served by a lighter, inventory-driven architecture.
Automated RoPA from Inventory - What is Actually Automatable
The third option is RoPA GDPR generation that draws from the firm's underlying inventory continuously, automating the parts of the work that data can do and leaving the parts that judgement must do.
Automatable. The processor identification, knowing which SaaS tools and AI services are in use, which carry personal data flows, which have DPAs in place. The technical metadata; vendor name, system reference, data residency, sub-processor lineage. The change detection, surfacing when a new tool is adopted, when a new AI feature turns on inside an existing tool, when a sub-processor changes. The maintenance refresh, updating the underlying records as the inventory evolves.
Not automatable. The purposes of the processing. The lawful basis assessment. The categories of data subjects in operational specificity. The retention period determination. The risk assessment that drives DPIA scoping. These remain DPO judgement work. A platform that claims to automate them is producing template entries that read plausibly and miss the substance.
The realistic split, for a typical mid-market firm: the inventory and processor identification layer covers perhaps sixty per cent of the time the DPO spends maintaining the RoPA. The judgement layer is the remaining forty per cent. Automating the inventory side reduces the DPO's RoPA workload by half to two-thirds, freeing capacity for the judgement work that actually requires the DPO. It does not produce a complete data processing register from data alone, and any vendor claiming otherwise has either lowered the bar of what counts as a complete RoPA or is producing entries that will not survive supervisor scrutiny. This is the honest limit of AI compliance tooling in the RoPA space.
What Montro Sees When the Inventory Layer Runs |
When Montro delivers the first inventory output to a new client, the DPO's reaction is rarely what we expect. The assumption is that the inventory will produce a near-complete RoPA; that once the data work is done, most of the register will follow. But what the inventory actually produces is a clear list of every processing activity that needs a RoPA entry, with the technical metadata filled in. It does not include the purposes, the lawful bases, or the retention determinations. Not because the inventory failed, but because those were never data questions. The DPO who spent 40% of their RoPA time on genuine judgement and 60% on figuring out the vendor names, sub-processor lineages, and data residency details did not know the split existed. The inventory makes the split visible. Some DPOs find that clarifying, and some find it confronting. Both reactions are understandable; it means the work is not done, but it also means the work that remains is the work only they can do. |
A Side-by-Side Decision
Three patterns hold for European mid-market firms.
Spreadsheet works when. The firm has fewer than fifty processing activities, low rate of change, a stable SaaS environment, and a DPO with capacity for quarterly manual maintenance. The cost is the DPO's time and the version-control discipline. Honest about its limitations.
OneTrust works when. The firm has the privacy programme depth and budget to deploy and operate the full platform, and benefits from the integrated coverage across RoPA, DPIA, DSAR, and consent. For the firms it fits, it is genuinely the right answer.
Inventory-driven automation works when. The firm has more than fifty processing activities, a fast-moving SaaS environment with regular new tool adoption, an active AI footprint where embedded AI features turn on inside existing tools, and a DPO who values having the inventory and processor identification done continuously rather than under audit pressure. The maintenance cost moves from DPO time on data to DPO time on judgement, which is the higher-value use of the role, and the operating model that serious privacy governance programmes are moving toward.
What the Supervisor will Inspect
The data protection authority does not inspect the firm's RoPA platform. They inspect the firm's RoPA. The relevant question is not which tool the firm bought, it is whether the record the firm can produce, on a 48-hour request, is current, complete, and signed off.
For each of the three approaches, the answer is operational. A spreadsheet RoPA can be current, complete, and signed off if the discipline is present; the discipline is what fails most often. A OneTrust RoPA is as current as the inputs the firm has fed it; if the underlying inventory is incomplete, OneTrust's output is incomplete. An inventory-driven automated RoPA is current to the cadence of the inventory layer underneath, which is typically continuous; the judgement layer is as current as the DPO's last sign-off pass.
The choice between the three is operational, not aesthetic. The right answer is the one your firm can actually operate, and the one that produces a data processing register the supervisory authority can receive within 48 hours and find current, complete, and signed off.
Frequently Asked Questions
Does the Article 30(5) exemption apply if a firm uses AI tools?
Rarely in practice. The exemption covers firms with fewer than 250 employees only where processing is occasional, does not involve special categories of data, and is unlikely to result in risk to data subjects. Most firms operating any meaningful AI footprint fail at least one of those three conditions, AI tools typically process personal data on an ongoing basis, not occasionally. The exemption should be documented and defended explicitly rather than assumed, and for any firm with a meaningful AI compliance footprint, the assumption that the exemption applies is almost certainly wrong.
What is the difference between a DPIA and a RoPA entry?
The RoPA under Article 30 is an inventory of every processing activity, what data is processed, by whom, for what purpose, and where. The DPIA under Article 35 is a risk assessment for specific processing activities that are likely to result in high risk to data subjects. The RoPA identifies which activities may require a DPIA; the DPIA assesses the risk of those specific activities in detail. A complete RoPA is the precondition for identifying which DPIAs are required, which is why an incomplete RoPA produces an incomplete DPIA programme.
How quickly must a RoPA be produced when a supervisory authority requests it?
Article 30(4) requires controllers and processors to make the register available to the supervisory authority on request, without specifying a formal deadline. In practice, supervisory authorities across the EU have signalled an expectation of rapid production, often within 48 to 72 hours for an initial response. A register that takes two weeks to assemble from scattered sources is responding poorly even if the eventual content is accurate. The time from request to defensible production is itself part of what the supervisory review assesses.
Can a processor use the same RoPA template as a controller?
No. Article 30(1) sets out the controller's register requirements; purposes, categories of data subjects, recipients, transfers, retention periods, security measures. Article 30(2) sets out the processor's register requirements, categories of processing carried out on behalf of each controller, transfers, and security measures. The processor's register is narrower in some respects and differently structured. A processor using a controller's template will have entries that either miss required fields or include fields that are not theirs to determine.
