Noru

Privacy Automation: From Code Scanning to Continuous Compliance

Privacy automation turns one-off audits into continuous, jurisdiction-wide compliance. Here's what it is, how an open privacy taxonomy standard lets you describe data once, and how scanning your source code keeps your data map, records, assessments, and audit evidence current across every regime you operate in.

By Noru8 min readPublished

Privacy automation is the practice of deriving your privacy documentation from the systems it describes instead of authoring it by hand. Source code and infrastructure are scanned and classified against an open privacy taxonomy to produce a living data map; from that one map, the artefacts each regime demands — GDPR Article 30 records, DPIAs, transfer records, regulatory scope, audit evidence — are generated and kept current automatically. AI drafts the first version of the narrative parts; people review and decide. The point is not to remove privacy experts but to stop them spending their time on discovery and transcription.

Privacy used to be a periodic exercise: a once-a-year review, a spreadsheet refreshed before an audit, a questionnaire sent around to engineers who half-remembered what their service actually collected. That model is quietly breaking. The rulebook now spans the EU's GDPR, a fast-growing patchwork of US state laws, and new regimes coming into force somewhere in the world almost every year - while personal data sprawls across dozens of services and third parties. The gap between what privacy teams document and what engineering actually ships keeps widening.

Privacy automation is how teams close that gap. This guide explains what privacy automation is, why the manual approaches most companies still rely on fall apart at scale, and how a code-first approach - one that starts by scanning your source code - turns privacy compliance into something continuous instead of a recurring fire drill.

What is privacy automation?

Privacy automation is the practice of converting privacy obligations into workflows that run on their own as your software and data change. Instead of a person manually discovering where personal data lives, writing down how it is used, and re-checking that record every few months, automation derives those answers directly from the systems that hold the data and keeps them up to date as the code evolves.

The goal is not to remove people from privacy work. It is to remove the repetitive, error-prone parts - the data hunting, the copy-paste record keeping, the chasing of stale answers - so that privacy and legal teams can spend their time on judgement: deciding lawful bases, weighing risks, and signing off on assessments. The machine handles discovery and drafting; the experts handle decisions.

Why manual privacy work breaks down

Most privacy programs are still run on interviews and documents. A privacy manager asks each team what data they collect, why, where it goes, and how long they keep it. The answers are typed into a Record of Processing Activities, a few impact assessments are drafted, and everything is filed away until the next audit. The trouble is that software does not sit still. A single sprint can add a new analytics SDK, a new sub-processor, or a new field that quietly captures something sensitive - and none of it is reflected in the document anyone signed off on.

The result is a set of failure modes that show up in almost every manual program:

  • Records go stale fast. A RoPA is accurate the day it is written and drifts from reality with every deployment after that.
  • Engineers are asked questions they cannot easily answer. "What personal data does this service process?" is hard to answer precisely from memory across a large codebase.
  • Privacy teams lack ground truth. Without visibility into the code, they are documenting what people believe the system does, not what it actually does.
  • Assessments lag behind launches. Manual DPIAs become a bottleneck, so they are skipped, rushed, or completed after the feature has already shipped.
  • Audit prep becomes a scramble. Evidence has to be reassembled by hand each time, because it was never captured as a byproduct of the work.

Privacy code scanning: start at the source

If software is the thing that actually collects and moves personal data, then the most reliable place to understand your privacy posture is the software itself. That is the idea behind privacy code scanning: rather than interviewing people about what a system does, you analyze the source code to find where personal data enters, how it is used, and where it flows.

Security teams have worked this way for years. Static analysis and dependency scanners read the codebase to surface vulnerabilities before they reach production. Privacy code scanning applies the same instinct to personal data: it reads the code, identifies the fields and flows that carry personal information, and classifies them against an open privacy taxonomy standard (more on that shortly) so that the output is consistent and machine-readable rather than free text.

A scan does not just say "this looks like personal data." It produces a structured data map: the systems in your estate, the datasets each one holds, the categories of data in those datasets (and whether any are special-category data), the purposes they are used for, and the people they describe. Wire the scan into your CI pipeline and that map refreshes as the code changes, so it reflects what you ship rather than what you remembered to write down.

Diagram of the privacy automation pipeline: source code is scanned and classified into a data map of systems, datasets, and activities, which feeds records and assessments, AI-drafted enrichment, and audit-ready evidence, with humans reviewing the output

A shared language for personal data

To automate privacy across many regimes, every system has to describe its data the same way. That is what a privacy taxonomy standard provides: a common, machine-readable vocabulary for classifying personal data, maintained as an open standard by the IAB Tech Lab (the IAB Tech Lab privacy standards). Because it is a shared standard rather than any one vendor's private schema, a classification travels with your data across tools, teams, and jurisdictions.

The standard describes data along three axes: what the data is (data categories), why it is processed (data uses), and whose data it is (data subjects). An email address is not just personal data; it is a contact email, used for a specific purpose, belonging to a specific kind of person. That precision is exactly what makes the downstream automation possible.

Three columns showing the privacy taxonomy standard: data categories such as user.contact.email and user.health_and_medical, data uses such as marketing.advertising and analytics.reporting, and data subjects such as customer, employee, and patient

In practice, a scan describes each field once in this shared vocabulary, flagging sensitive fields as special category. From that single classification the obligations of any applicable regime can be generated - the same labels can feed a European record, a US state assessment, or a vendor due-diligence report without re-describing the data each time.

scan-output.yaml
# Every field described once, in the shared taxonomydataset: customerscollections:  - name: profiles    fields:      - name: email        data_category: user.contact.email        data_use: marketing.advertising        data_subject: customer      - name: date_of_birth        data_category: user.demographic.date_of_birth        data_subject: customer        special_category: true

From a data map to automated compliance

A structured data map is valuable on its own, but its real power is that almost every other privacy obligation can be generated from it. Once Noru has the map, it turns that single source of truth into the records, assessments, and evidence that regulators expect - and keeps them current as the map changes.

A living data map

The map is the foundation. Noru materializes the scanned manifest into an explorable view of systems, datasets, and processing activities, with filters for things like special-category data and cross-border activity. Each source carries a version history, so you can see exactly what changed - which systems, datasets, or activities were added or modified - on every push. You can also reconcile a system in the map with an asset or vendor already tracked in your compliance register, connecting privacy to the rest of your governance work.

Records of processing, derived not authored

Almost every modern privacy law expects you to keep an inventory of how you process personal data. The GDPR's Article 30 Record of Processing Activities (the GDPR on EUR-Lex) is the most prescriptive example - and the hardest to maintain by hand - but the same inventory answers similar duties elsewhere. Noru builds that register straight from the data map. The technical facts - purpose, data categories, data subjects, recipients, and the special-category and cross-border flags - are derived automatically from the scanned activities. What is left for people is the judgement: the lawful basis, retention rules, transfer safeguards, and technical and organizational measures. Each entry carries a status as it moves from derived to in-review to approved, and the register can be exported for your documentation.

Assessments that open themselves

Impact assessments are easy to forget precisely when they matter most - when something new and sensitive is introduced. The GDPR calls them DPIAs; US state laws call them data protection assessments; the conditions that trigger them rhyme across regimes. Noru watches the data map for exactly those triggers. When a scan reveals new special-category data or a new cross-border transfer, it opens a privacy assessment automatically, with the relevant activity facts already attached. Teams can also open assessments manually against any activity. Each one records its trigger, walks through the necessity and proportionality analysis, captures residual risk, and ends in a documented outcome - and it can link to the risks in your register so identified risks and their treatments stay connected.

Knowing which laws apply

This is where one data map pays off most. Privacy obligations differ by jurisdiction, and which ones apply depends on what you actually do with data. Noru reads the signals in your activities - special-category data, cross-border transfers, sale or sharing, targeted advertising, profiling - and maps them to the regimes they trigger, so the same underlying map can serve every applicable jurisdiction at once. Instead of guessing what is in scope, you see which laws your processing brings into scope, and why.

Today that includes regimes such as:

As new laws come into force, the same activity signals map to new obligations - without sending another questionnaire to your engineers.

AI that drafts the first version

Some of the work that remains is judgement, but a lot of it is a blank page. Noru uses AI to remove the blank page. For newly discovered activities it drafts an enrichment suggestion - a proposed lawful basis with a short rationale, a plain-language purpose statement, and a recommendation on whether an assessment is warranted, each carrying a confidence score. For newly opened assessments it drafts the processing description and the necessity-and-proportionality narrative. Crucially, none of this is applied silently: every suggestion is presented as a draft that a person can accept, edit, or dismiss, and the choice is recorded.

Evidence that stays audit-ready

Auditors want proof that your data map is real and maintained, not a one-time artifact. Every time a manifest is ingested, Noru records an evidence item for that source - including the change summary and the counts of systems, datasets, and activities - and links it to the relevant Article 30 controls. Keeping your map current quietly produces the audit trail that demonstrates you are keeping it current.

Augmentation, not replacement

It is tempting to describe all of this as "automated compliance," but that phrase oversells what good automation should do. Lawful bases, the outcome of an assessment, and whether to consult a supervisory authority are decisions with legal weight. They belong to people who are accountable for them.

The honest framing is augmentation. Machines are excellent at the parts that defeat manual programs: discovering personal data across a large codebase, keeping a data map in sync with what ships, and drafting a credible first version of a record or a narrative. People are irreplaceable at the parts that require judgement and accountability. Privacy automation works best when it draws that line clearly - the machine maps and drafts, the experts review and decide.

Noru brings these pieces together - data map, records, assessments, regulatory scope, AI-assisted drafting, and evidence - into one continuous workflow that starts at your code and serves every jurisdiction you operate in. If you want to see what privacy automation looks like against your own systems, you can explore it at noru.tech.

Primary sources

FAQ

Privacy & GDPR questions answered

Talk to us

What is privacy automation?

Deriving privacy artefacts from the systems that actually process personal data, rather than maintaining them as separate documents. Code and infrastructure are classified against a shared taxonomy to build a data map, and records, assessments and evidence are generated from that map.

How is privacy automation different from a privacy management tool?

Most privacy tools are a better place to store documents you still write yourself. Automation changes where the facts come from: the tool observes the systems and proposes the record, so the register reflects behaviour rather than recollection.

Can privacy automation replace a DPO?

No, and it should not try. Automation handles discovery, classification and drafting. Lawful basis, necessity, proportionality and risk acceptance are accountable judgements that belong to a named person, and the record should show who made them.

What is an open privacy taxonomy and why does it matter?

It is a shared vocabulary for describing personal data — data categories, data subjects, and purposes of use — that is not specific to one vendor. Describing data once in a standard vocabulary means the same annotation can serve GDPR, CCPA and every other regime you fall under, instead of being re-derived per law.

Does privacy code scanning read our source code?

It analyses code to identify where personal data is handled and how it flows. The output is metadata about data handling — the fields, the vendors, the transfers — which is what the privacy record needs; the value is in the map, not in the source itself.

Where does AI fit without becoming a liability?

As a drafter, never as a silent decider. AI is well suited to writing the first version of a narrative grounded in evidence you already hold, and badly suited to deciding whether a legal basis holds. Every generated output should be attributable, reviewable, and rejectable.