A processing register your discovery scans keep honest

What §8(7) turns the register into

Section 8(7) requires a Data Fiduciary to erase personal data when the data principal withdraws consent or when it is reasonable to assume the specified purpose is no longer being served, unless retention is necessary for compliance with any law. Read that as an operational requirement and it stops being a paperwork exercise: to erase on purpose-completion you have to know which activities process which data in which systems, and to evidence the erasure you have to record it against something.

So the register here is not a document. It is a set of activities, each carrying its purpose, lawful basis, the categories of personal data and of data principals, the systems the data actually sits in, the recipients including processors, whether it crosses a border, the retention rule it is disposed against, the security measures claimed, and a risk score. The register is what §8(7), §8(2) and §16 are all enforced from.

Five views of the same register

The module presents one register through five lenses, because the DPO, the security team and the person answering an erasure request are looking for different things in the same rows.

• Activities — the register proper: name, purpose, lawful basis, retention, risk and DPIA state, recipients, cross-border, notice completeness.
• Data flow — the visual lineage from collection through purpose to recipients and destination.
• Data sensitivity — where sensitive categories sit, drawn from discovery findings rather than from what someone typed.
• Risk and DPIA — the scored activities and the assessments proposed against them.
• Governance — the DPO and independent data auditor designations and the periodic audit tracker.

Entries you did not type

Three routes populate the register and they coexist. You can add an activity by hand, which is the right answer for HR, payroll, KYC and physical security — processing with no consent purpose behind it. A starter set of those standard activities is seeded per tenant so the register is not an empty table on day one.

The second route is the one that stops decay. A resolver reads your declared consent purposes together with the findings from PII discovery and proposes activities, deriving the data categories from what was actually found, linking the systems the data was found in, attaching the recipients recorded against those purposes, scoring the risk and suggesting the retention rule. Discovered personal data that maps to no activity opens its own task rather than being quietly absorbed.

The third is a discovery sweep across vendors, open incidents and registered data sources that reports proposed changes without writing any. That reticence is the design: the resolver proposes and a person decides. Where the lawful basis is inferred rather than stated, the activity is flagged unconfirmed and a task is raised to confirm it, and the register shows you the count of unconfirmed bases on the front page.

Where the data categories come from

Discovery connects to fifteen source types — PostgreSQL, MySQL, SQL Server, Oracle, Db2 and managed relational instances, MongoDB, S3, Salesforce, SAP, a generic REST source, shared filesystems and log files through an outbound-only on-premises agent, and the Microsoft Purview and OpenMetadata catalogues, which contribute existing classification tags rather than reading raw data. Mailboxes are scanned separately with their own connectors, reading bodies and attachments including scanned PDFs, and storing findings masked with a keyed hash and no message metadata.

Classification runs on a named-entity engine with a set of India-specific recognisers layered on top, falling back to pattern and checksum detection when the engine is unavailable. The India set is the part that matters here: Aadhaar with its checksum, PAN, GSTIN, IFSC, Indian passport, Indian phone, vehicle registration, voter ID, driving licence, UPI virtual payment address and ABHA health identifier, alongside the general types — email, card number with a network and checksum test, address, person name and IP. Context-gated types only fire when supporting keywords sit nearby, which is what keeps a column of six-digit numbers from being reported as identifiers.

Those findings feed the register's sensitivity categories, and categories like children's data, health, biometric, genetic and financial are the ones that force a DPIA regardless of the computed score.

DPIA, processor contracts and restricted destinations

An activity is scored out of a hundred and banded. A DPIA is triggered by a forced category, a rule match, crossing the threshold, a cross-border element, high volume or a high-risk recipient — and it is proposed as pending sign-off, never auto-approved. Sign-off is gated to the DPO, compliance or organisation administrator roles, and the assessment itself is versioned and exportable.

Processor contracts are checked by joining the recipients recorded against each activity to the contract records held for those vendors, so the register can tell you which processors are handling personal data with no data processing agreement in force or with an expired one. That is the §8(2) obligation expressed as a count on the front page rather than as a spreadsheet someone maintains.

Cross-border works from a registry of restricted destinations that ships deliberately empty, because no country has been notified. Administrators add notified destinations as and when; a transfer to one raises a materially larger risk signal than a generic cross-border flag and opens its own review task. Each recipient carries its geography, transfer mechanism and safeguard. What the module does not do is manage standard contractual clauses or adequacy decisions for you — that machinery belongs to a regime India has not adopted.

Erasure you can evidence

This is where the register earns its place rather than duplicating a spreadsheet. When a consent withdrawal lands, a bridge observes it and writes an erasure evidence record sealed against the register's audit chain, then opens a dispatch task against the activities and recipients that withdrawal touches. A data principal request can be mapped to the activities, sources and recipients it actually reaches, which turns "do we hold anything for this person" from a meeting into a query.

The audit trail underneath is a SHA-256 hash chain with a per-entry keyed digest and a signed head, and there is a verify call that recomputes it. Register-level sign-off takes a snapshot with an optional expiring share link, which is the thing you give an auditor rather than exporting your live register to them.

One limitation worth stating rather than discovering. The data model carries version, supersession and current-version fields, but edits are applied in place and recorded as audit events naming the fields that changed — there is no side-by-side version diff of an activity. DPIAs are versioned properly. If you need a before-and-after of a register entry, the audit trail is where it lives.

Where processing registers break

The register is the artefact most likely to be technically present and practically useless.

• It was built once, by interview, and is now a description of an organisation that has since changed three systems. Nothing in the document tells you which parts have gone stale.
• Lawful basis is filled in as consent everywhere because that was the default, and nobody has confirmed a single one. The count of unconfirmed bases exists so this is visible rather than assumed.
• Discovery is pointed at production databases and not at the file share where the operations team keeps spreadsheets. The register is accurate about the systems that were easy to connect.
• Recipients are recorded as company names with no contract record behind them, so the processor contract check has nothing to join to and reports clean.
• An activity is retired in the register while the pipeline that fed it keeps running, because retiring a row does not stop a job.
• The register and the consent purposes drift apart, with retention set to one number in the purpose and another in the retention rule. They are linked for exactly this reason, and the link has to be maintained.

What the data map does not do

It does not delete anything. The retention side is a rules registry with review dates and upcoming expiries; enforcement happens in the consent module's sweeps and in the systems that own the data. Nothing here purges a database on a schedule.

It does not decide lawful basis. The resolver infers a starting point from the activity and its purpose, flags it as unconfirmed, and raises a task. A person confirms it, and that confirmation is recorded with their name against it.

It does not sign off a DPIA. It triggers one, structures it, versions it and exports it; approval is gated to accountable roles and is a human act.

It does not discover data sources by itself, and it does not connect to everything. There is no cloud-drive, warehouse or collaboration-tool discovery, and a source nobody registers is a source the register will never know about.

It is not a replacement for reading the buyer's guide before you choose a tool. If you are still comparing approaches rather than operating one, start there — the guide covers what a record has to contain and why questionnaire-built registers decay.