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 questions by connecting directly to your database in read-only mode and running automated scans.
SELECT privileges - nothing more.1. Database Connections
Navigate to Admin → Data Discovery → Database Connections and add a connection. Supported types:
| Database | Connection method |
|---|---|
| PostgreSQL | Host, port, database name, read-only user/password |
| MySQL / MariaDB | Host, port, database name, read-only user/password |
| MongoDB | Connection URI with read-only role |
| Microsoft SQL Server | Host, port, database, user/password |
| Other | Contact support - we can onboard new connection types quickly |
Create a dedicated read-only database user for Privacy Labs. Do not use an admin or application user. Example for PostgreSQL: GRANT SELECT ON ALL TABLES IN SCHEMA public TO privacylabs_ro;
2. Running a Scan
Once connected, trigger a scan manually from the dashboard at any time. Scans are incremental: only changed tables and columns are re-analysed, so subsequent runs are faster.
The scan does three things: classifies every column by PII category and sensitivity, checks encryption and retention configuration, and maps relationships between tables. These results feed every other section of the Data Discovery module.
3. The Scan Report - 4 Levels
Each scan produces a layered report. 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 the scan 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 persisted - it survives future scans and the model learns from it. You do not need to fix the same mistake twice.
| 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.
The Access Control view lists every user and role that has read access to your database. For each one it shows the tables they can see and flags access that looks unnecessarily broad for their 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 database connected and the first scan done, your auto-generated privacy policy and ROPA are ready to review. Go to Legal Policies to publish them.
Legal Policies & Breach Management →