The difference between a better place to store privacy documents and a system that keeps them true.
Privacy automation software derives your privacy artefacts from the systems that actually process personal data, instead of asking people to author and maintain them. The distinction that matters when evaluating it is where the facts originate: a tool that stores documents you still write yourself is a filing cabinet with workflow, however good the interface. Real automation observes the systems, proposes the record, and detects when reality diverges from what is documented. Judge candidates on which artefacts are genuinely derived, what happens when the underlying system changes, and whether AI is confined to drafting rather than deciding.
Trace one field back to its origin. If the answer is that somebody typed it into a form, the tool is workflow rather than automation. If it is derived from code, infrastructure or a connected system, ask what happens when that source changes.
Vendors describe very different things as automated. Establish specifically whether the Article 30 register, the data map, transfer records, DPIA scoping and retention rules are generated from the map, or whether only the templates are pre-filled.
A proprietary taxonomy means your annotation work belongs to the vendor. An open standard means the same description of personal data survives a change of tooling and serves GDPR, CCPA and other regimes from one annotation.
Drafting a narrative from evidence you already hold is a good use of a model. Deciding whether a legal basis holds is not. Look for outputs that are attributable, reviewable and rejectable, with the reviewer recorded — and be wary of anything that silently changes a record.
The failure mode of manual privacy work is silent divergence between the documents and the systems. Ask what the tool does when a new field appears, a subprocessor changes or data starts flowing to a new region — and whether that surfaces as work or goes unnoticed.
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 starts at the code: personal data is annotated where it is defined, classified against an open privacy taxonomy, and pushed from CI, so the data map is a product of the build rather than a survey.
From that map the Article 30 register, assessment triggers, transfer records and regulatory scope are derived and kept current, which means the documentation changes when the system does.
Cortex drafts the narrative parts grounded in evidence already in your programme, and every output is attributable and reviewable — it never silently decides that a control passes or a lawful basis holds.
Deriving privacy artefacts — the data map, records of processing, assessments, transfer records and evidence — from the systems that actually process personal data, rather than maintaining them as separate documents that have to be manually reconciled.
Most privacy management tools are a better place to keep documents you still write. Automation changes where the facts come from, so the register reflects system behaviour rather than someone's recollection at the time they filled in a form.
No. It removes the discovery and transcription work, which is most of the time cost. Lawful basis, necessity, proportionality and risk acceptance remain accountable judgements that belong to a named person, and the record should show who made them.
It means analysing code to identify where personal data is handled and how it flows. What the privacy record needs is the resulting metadata — fields, purposes, vendors, transfers — not the source itself. Ask any vendor precisely what leaves your environment and what is retained.
At the draft. Generating a first version of a record or narrative from evidence you already hold is safe and useful. Concluding that a legal basis holds, or that a risk is acceptable, is a decision a regulator will attribute to a person — so it should be made by one.
Regulatory references on this page were last checked on .
A 45-minute walkthrough against your frameworks, your integrations and your evidence.
