DPDP Governance · Module
ConsentGuard Scan discovers and classifies personal data across your estate — read-only, inside your own network, with a person signing off on every finding.
The Challenge
You cannot honour a DPDP request you cannot locate
Access and erasure requests carry regulatory timelines, and most institutions have no current inventory of where personal data sits across core banking, the LOS, collections tools, warehouses and file shares.
Spreadsheet-based data inventories are stale the week they are finished, and nobody can evidence how a given entry was arrived at.
Automated classifiers that publish straight to a catalogue produce confident, unreviewed answers — which is the opposite of what an examiner wants to see.
Capabilities
Discovery built for a regulated estate
Four design decisions shape the product, and each one is enforced in code rather than left to policy.
Connects read-only — and proves it
Every connector verifies at connection time that the credential it was given cannot write. A credential that can write is refused and the scan stops before a single row is read.
- Privilege checks run against the source's own permission system
- Azure requires a read-only SAS token; a connection string is refused outright
- The refusal is written to the audit log as a first-class event
Classifies against DPDP categories
Ten detectors score every sampled field on two signals — the shape of the value and the name of the field — so a column called `discount` never gets read as a PAN.
- Aadhaar is validated with its Verhoeff check digit, not just a 12-digit pattern
- IFSC codes are checked against a known bank-prefix registry
- Categories with no public checksum are capped below Verified by design
Nothing is catalogued without a person
Every candidate classification waits for a Compliance Officer or Super Admin to confirm or reject it — at any confidence score, including 100%.
- Bulk confirm has a server-side floor; a request below it is rejected, not clamped
- Catalogue entries are versioned and superseded, never overwritten
- IT Admins can run scans but cannot confirm a classification
Masked before storage, not before display
Sample values are masked on the way into the database. The application store never holds a raw personal-data value, so a database compromise cannot leak what the scan found.
- Credential secrets live in AES-256-GCM envelopes; the database holds only a reference
- Masked samples are gated behind a separate permission
- Exports carry no unmasked personal data
Connectors
Ten source types, one asset tree
Every connector resolves to the same shape — source, container group, container, field — so a Postgres column and an object in a bucket review identically.
Relational
- PostgreSQL
- MySQL
- Oracle 12.2+
- Microsoft SQL Server 2016+ / Azure SQL
Document & search
- MongoDB
- Elasticsearch 7+ / OpenSearch
Object storage
- Amazon S3 & S3-compatible
- Azure Blob Storage
- Google Cloud Storage
Files
- Mounted filesystem — SMB, NFS, local disk
Delimited, JSON, text, PDF and Office Open XML files are parsed for real field names. Image metadata, including GPS coordinates, is read as location data.
Classification
What it detects, and how far it will commit
Confidence is earned, not asserted. A category with no public checksum can never reach Verified on value alone — the ceiling is built into the detector.
| Category | Detection method | Sensitivity | Highest tier |
|---|---|---|---|
| Aadhaar | Verhoeff checksum | Sensitive | Verified |
| PAN | Format + field name | Sensitive | High |
| Bank account | Composite | Sensitive | Needs review |
| IFSC | Bank-prefix registry | Sensitive | Verified |
| Phone | Format | Personal | Verified |
| Format | Personal | Verified | |
| Name | NER + gazetteer | Personal | High |
| Address | NER + PIN code, GPS from EXIF | Personal | High |
| Gender | Value set + field name | Personal | Verified |
| Date of birth | Composite | Personal | High |
Passport, Voter ID, GSTIN, health and biometric data are not detected in the current release. Your own categories can be added to the catalogue and populated by reviewers.
How a scan runs
From credential to catalogue entry
Five stages, each with a defined failure behaviour. A run that cannot satisfy a stage stops there rather than proceeding on a guess.
Connect and prove read-only
The scan resolves an encrypted credential, connects, and asserts the credential cannot write. A writable credential ends the run here.
Guardrails
Built to be let near production
Discovery tools get pointed at core banking systems. These are the constraints that make that a reasonable thing to do.
Runs inside your network
Docker Compose on your own host. No cloud service, no orchestration platform, and no internet access required at runtime.
Scans only in your window
A run arriving outside its permitted window pauses having connected to nothing. Production systems stay untouched outside agreed hours.
Stops when something is wrong
Transient failures retry with backoff; permission and credential errors never do. Five consecutive container failures trip a circuit breaker and abort the run.
Audit trail the database enforces
Every decision is a hash-chained entry. A database trigger rejects updates and deletes on the audit table, and integrity can be verified on demand.
FAQ
ConsentGuard Scan — common questions
What it covers, what it deliberately does not, and how it behaves against a production estate.
ConsentGuard Scan is the data discovery and classification module of FinHub's DPDP Governance Platform. It connects read-only to your databases and object stores, samples a bounded portion of the data, scores every field against DPDP-relevant personal-data categories, and produces a reviewed data catalogue with a tamper-evident audit trail.
Explore More
Discovery is one module of the platform
Point it at one source and see what comes back
A scoped pilot on a single database or bucket, running inside your network, with your team reviewing every finding.