Most teams start with names, email addresses, phone numbers and government IDs. Then they stop. Modern products do not work that way. Personal data can be spread across identifiers, logs, analytics events, support messages, documents and device data.
The DPDP Act defines personal data broadly as any data about an individual who is identifiable by or in relation to such data. The engineering consequence is important: classification cannot happen only from column names.
Direct identifiers are the easy part
Name, email, phone number, PAN, Aadhaar-related information, address and account information are obvious. A scanner can find many of these with schema rules and pattern detection.
The harder cases are indirect identifiers. A user_id, device ID, order ID or persistent cookie may look meaningless by itself. If your systems can link it back to an identifiable person, it belongs in the privacy analysis.
Free text is where inventories break
Columns such as notes, comments, metadata, support_message and description can contain anything. A support ticket may contain a phone number. An AI conversation may contain a medical detail. A sales note may contain an address.
Schema-only discovery will miss this. Useful discovery combines schema signals, pattern matching, context and content sampling.
Logs are data stores
A request log can contain a user ID, email, phone number, IP address or request body. Once it is written to CloudWatch, an SIEM or an exported S3 bucket, that system becomes part of the personal-data map.
The same applies to analytics. user_id plus behavioural events is not automatically anonymous just because it lives in a product analytics platform.
Hashing does not automatically make data anonymous
Hashing an email address can be useful for matching. It does not automatically remove the privacy implications if the value can still be linked to a person or used as a persistent identifier. Pseudonymisation and anonymisation are not the same thing.
Build an inventory that understands context
For every material data element, record:
- Data category
- Data Principal category
- System and field
- Purpose
- Applicable processing basis
- Recipients and processors
- Storage/processing location
- Retention rule
- Deletion method
- Owner
The goal is not a giant PII spreadsheet. It is a data inventory that can answer what the data is, why it exists, where it flows and what should happen next.
The one-user test
Pick one real test account and trace it through your stack:
Production DB
↓
Warehouse
↓
S3
↓
Logs
↓
CRM
↓
Support
↓
Analytics
↓
Backups
Can your team explain every meaningful copy and why it is still there? If not, the problem is discovery, not policy wording.
Where Privra fits
Privra discovers personal data across databases, cloud storage, analytics, logs and third-party systems, then connects findings to purpose, processors, retention and remediation.