Everyone scans databases for DPDPA discovery. Personal data doesn't originate there — it originates in an API handler or a form submission, and that's where discovery actually needs to begin.
July 2026 · 7 min read
Ask most organizations how they're approaching data discovery for DPDPA compliance, and you'll hear a version of the same answer: connect a scanner to the database, find the tables named things like users, customers, and transactions, flag the columns that look like PII, call it discovery. That work is necessary. It is nowhere near sufficient — and the gap between where data is stored and where it actually enters your system is exactly where the compliance decisions that matter most get made without anyone noticing.
Data doesn't appear in a database on its own. It arrives through specific, code-defined entry points — a registration endpoint accepting a signup payload, a form handler processing a loan application, a mobile SDK capturing device telemetry, a webhook pulling in customer data from a third party. Those entry points, not the tables that eventually store what they receive, are where the real collection happens.
This matters because DPDPA's obligations attach at the point of collection, not the point of storage. Section 5 requires a notice before or at the time of collection. Section 6 requires consent before collection, wherever the processing isn't otherwise legitimate. If you can't see where data actually enters your system at the code layer, you have no reliable way to confirm every collection point has a matching notice and consent mechanism behind it. A database scan tells you what you're holding. A code scan tells you how it got there — and whether it got there lawfully.
Take a straightforward example: a scanner finds a phone_number column in a leads table. When was that number actually collected? Through which form or endpoint? Was a notice shown before collection happened? Was consent captured, and by whom was this collection point ever mapped to a declared purpose? A database scan can point at the column. Only a code scan can trace where it came from.
Developers add API endpoints that collect personal data all the time without registering them in the consent platform — usually not out of any bad intent, just because the endpoint was never flagged as a collection point in the first place. This is the single most common source of compliance gaps. The database shows the data exists; the code scan shows exactly where it arrived.
Analytics, push-notification, and attribution SDKs routinely collect device identifiers, location, and behavioral data at the application layer — often sending it straight to a third-party server without ever touching your own database. A database-only scan is structurally blind to this category of collection.
A contact form with ten fields might have eight properly linked to a declared purpose in your consent platform, and two — added in a sprint a few months back — with no such link. The database shows all ten columns without distinction. A code scan identifies the form handler and its actual payload, which is what makes it possible to compare against your consent platform and flag exactly which two fields are the gap.
Even where consent is nominally required, is it checked in code before data gets processed? A code scan can identify collection points where personal data is accepted and stored regardless of consent state — a gap in application architecture, not something a database query would ever reveal.
truConsent's open-source code-scanning module, truScanner, connects directly to your GitHub repositories and scans for the patterns associated with personal-data handling: API route definitions, request-body parsing, form field declarations, SDK initialization calls, and database writes involving common PII field names. The output is a map of collection points at the code layer, each tied to its data fields and its exact location in the codebase.
That map does real work once it exists. It auto-populates the consent platform's collection-point registry, cutting down manual configuration substantially. It surfaces gaps between what's actually collected in code and what's declared in the consent platform. It generates purpose-mapping suggestions based on the data elements found at each entry point. And it flags new collection points the moment they're introduced in a code change, turning compliance into a continuous check rather than a one-time audit.
Code changes constantly, and every change is a potential new data-collection surface — a developer adds a field to a signup form, a product team wires in a new analytics SDK, a new partner integration starts sending user attributes over an API. Without ongoing scanning, each of these can introduce unconsented collection without anyone deciding that on purpose. Wiring truScanner into your deployment pipeline catches new entry points before they reach production, rather than discovering them months later during an audit.
A complete DPDPA discovery program needs code scanning and database scanning working together, not one standing in for the other. Code scanning — through a tool like truScanner — answers where data enters, which endpoints collect which fields, and whether a consent gate actually exists; that maps directly to Sections 5 and 6. Database scanning — through a tool like truFinder — answers what's stored, which user it belongs to, and under which declared purpose; that maps to the access, deletion, and retention obligations in Sections 11, 12, and 8(7).
Run either one alone and you get half the picture. Run both, and you get the complete answer: where data enters, where it ends up, who it belongs to, and whether it was collected lawfully in the first place.
Finding out what your own codebase is actually collecting, rather than assuming your database inventory is complete, is exactly where our DPDP gap assessment starts.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation