Data Discovery
The DPDP Act requires you to know exactly what personal data you hold, where it lives, how long you keep it, and who can access it. Data Discovery answers all four with a self-hosted data-discovery scan you run on your own infrastructure. You download the scanner and run it yourself; it discovers and classifies the personal data (PII) you hold and produces your data map - the foundation of your Records of Processing (RoPA). Your database credentials and your data never reach Privacy Labs; only a report of column names and their classifications (never the values) is uploaded.
SELECT privileges only.1. Download & Run the Scan
Go to the Local Scanner tab in your dashboard and download the scanner (a small zip). It runs the data-discovery scan on any machine that can reach your database - a laptop, a jump box, or a server.
- 1
Install Node.js. Install Node.js (LTS) from nodejs.org - one time, one click.
- 2
Unzip and open your folder. Unzip the download. Windows users open the "Windows" folder and double-click Start-Scanner.bat. Mac users open the "Mac" folder and double-click start.command.
- 3
Choose a source and connect. Pick what to scan and follow the prompts. For SQL databases, paste a READ-ONLY connection string. For DynamoDB, enter your region + access key + secret. For Firebase, point it at your service-account JSON. Try the built-in demo first to see how it works.
Supported sources:
| Source | What you provide |
|---|---|
| PostgreSQL / Supabase | A read-only connection string |
| MySQL / MariaDB | A read-only connection string |
| Microsoft SQL Server | A read-only connection string |
| MongoDB | A read-only connection URI |
| DynamoDB (AWS) | Region + access key + secret (read-only) |
| Firebase (Firestore) | Your service-account JSON file |
| A folder of files | A local path (CSV, JSON, and similar) |
| Built-in demo | Nothing - sample data to try it out |
Create a dedicated read-only database user for the scan - do not use an admin or application user. Example for PostgreSQL: GRANT SELECT ON ALL TABLES IN SCHEMA public TO privacylabs_ro; SQL Server, MongoDB, DynamoDB and Firebase download their driver automatically the first time you pick them (one-time, needs internet).
2. Upload Your Report
When a scan finishes, the scanner saves a report in the out folder as discovery-report.json. This file contains column names and their classifications only - never your actual data values. Upload it on the Local Scanner tab.
Privacy Labs then builds the layered report and recommendations below from what you uploaded. Re-run the scanner and upload again whenever your schema changes; your manual classification corrections are remembered.
3. The Report - 4 Levels
The report you upload is layered. You can drill from a high-level table summary all the way down to individual column recommendations.
Table Summary
A ranked list of your database tables showing overall criticality and the types of personal data each one contains. Tables are scored Critical, High, Medium, or Low based on what PII they hold (e.g. a table with Aadhaar numbers ranks Critical; a table with only product SKUs ranks Low).
Column Level View
A zoomed-in view of every column in a selected table. For each column the scan reports the detected PII category (Name, Email, Phone, Aadhaar, Bank Account, IP Address, etc.) and a sensitivity rating.
Human-in-the-loop editing: The classifier is not always 100% accurate. If it misclassifies a column (e.g. flagging an internal reference code as a phone number), you can correct it directly in the UI. Your correction is saved and re-applied - you do not need to fix the same mistake twice. Sensitive categories also have a floor: a column tagged Aadhaar, for example, cannot be set below Critical.
| PII Category | Sensitivity | Examples |
|---|---|---|
| Name / Email / Phone | Medium | users.full_name, users.email |
| Aadhaar / PAN / Passport | Critical | kyc.aadhaar_number |
| Financial data | Critical | payments.bank_account_no |
| IP / Device ID | Low | sessions.ip_address |
| Location | High | deliveries.lat_lng |
| Health / Biometric | Critical | profiles.face_id_hash |
Relationship Diagram
A visual data lineage map showing which tables reference which other tables (via foreign keys and detected join patterns). This is useful for two things: understanding the blast radius of a data deletion request (all the tables that need to be touched when a user asks to delete their account), and identifying unexpected cross-table PII flows.
Recommendations
The most actionable output of the scan. A prioritised list of changes your engineering team should make to become compliant. Recommendations are grouped by impact and reference the specific tables and columns they apply to. Examples:
- Encrypt kyc.aadhaar_number at rest - currently stored as plain text
- Add a data retention policy to sessions table - no deletion schedule found
- Remove direct Aadhaar storage in payments.bank_account_no - use a tokenised reference instead
- Revoke SELECT on users table from vendor_analytics_user - vendor access should be purpose-limited
Each recommendation links to the relevant DPDP Act section so your legal team can verify the obligation. Fixing recommendations increases your Compliance Score in the Compliance Hub.
4. Encryption Status
The scan checks whether columns containing sensitive PII are encrypted at rest. For each column the status is one of: Encrypted, Plain text, or Unknown (when the storage engine doesn't expose encryption metadata). Unencrypted sensitive columns are surfaced as Critical recommendations.
Privacy Labs does not encrypt columns for you - that change happens in your database. The scan tells you where the gaps are and tracks them as resolved once you've applied the fix and the next scan confirms it.
5. Data Retention
The DPDP Act prohibits processing personal data beyond the period necessary for the stated purpose (§8(7)). In practice this means every table that holds PII needs a defined deletion or anonymisation schedule.
The Data Retention view shows, for each PII-containing table, whether a retention period has been set, what it is, and whether any rows are past that window and eligible for deletion. Tables with no defined retention policy are flagged as compliance gaps.
You set retention windows inside Privacy Labs (e.g. "users table - delete 3 years after last login"). The system then alerts you when rows are overdue, and those alerts flow into your daily task queue in the Compliance Hub.
6. Access Control
The DPDP Act holds you liable for data breaches that happen through your vendors and third-party processors (§17). If a vendor you've granted database access to suffers a breach, the penalty falls on you.
Where your database exposes it, the scan reports every user and role that has read access, the tables they can see, and flags access that looks unnecessarily broad for its stated purpose (e.g. a marketing analytics vendor with SELECT on the KYC table).
This is an advisory view - Privacy Labs does not revoke access for you. Use it to identify over-privileged accounts and make the changes in your database or cloud IAM.
Next up
With your first report uploaded, your data map feeds your Records of Processing (RoPA) and your privacy policy. Review your RoPA, then generate and publish your policies.
Legal Policies & Breach Management →