PII in Logs: The DPDP Blind Spot in Indian Applications

Application logs are the most overlooked PII store in most Indian companies. Under the DPDP Act 2023, log lines that capture Aadhaar-like identifiers, phone numbers, emails, or session tokens are "personal data" like any database column — subject to the same purpose limitation, retention limits, access control, and erasure obligations. Yet logs are almost never included in DPDP data-mapping exercises, which means the biggest leak surface in the stack is also the least governed.

Most teams instrument logging early, before anyone thinks about compliance, and the logging library serializes whatever it's handed — full payloads, headers, user objects — straight into a file, a log aggregator, or a third-party error tracker. Nobody revisits that decision when the DPDP Act arrives. This post covers why logs are a blind spot, redaction and structured-logging patterns, retention limits, access control on log platforms, and what an erasure request means for your log pipeline.

Why logs are a DPDP blind spot, not an edge case

Data protection programs in India tend to focus on obvious stores — the primary database, the CRM, backup snapshots. Logs get treated as operational telemetry, not personal data, because engineers see them as debugging artifacts rather than a data store. That framing is wrong under the DPDP Act's broad definition of personal data — any data "about" an identified or identifiable individual — broad enough to include an email address in a request log, a name in an error stack trace, or a masked-but-reversible phone number in an analytics event.

Three things make logs riskier than a database:

1. Volume and velocity. A production system can emit millions of log lines a day; each is a potential PII exposure point no manual review can catch.
2. Fan-out. The same log line is often shipped to multiple destinations at once — a local file, a log platform, an error tracker like Sentry, and an analytics pipeline — multiplying where that personal data now lives.
3. Low observability of the leak itself. A misconfigured database column shows up in a schema review. A PII leak inside a logger.info() call three levels deep in a request handler usually doesn't surface until someone greps the logs for a phone number and finds it in a dozen places.

What PII ends up in logs

Walk a typical Indian fintech or healthtech request path and you'll find personal data leaking at every layer, not just the application code teams usually audit.

1. Application logs: full request bodies with names, phone numbers, Aadhaar or PAN-like identifiers, and session tokens, often logged on error paths for debugging context.
2. Access/web-server logs: query strings carrying tokens, OTPs, or user IDs get written verbatim by Nginx, Apache, or the load balancer's default log format.
3. Error trackers: tools like Sentry or Bugsnag capture full exception context, including local variables and payloads, by default — often on infrastructure with weaker access controls than the production database.
4. Analytics pipelines: click and event streams sent to product-analytics tools often include user identifiers, email, and free-text fields a support agent typed into a ticket.

Redaction and structured-logging patterns

The fix isn't "stop logging" — teams need logs to debug incidents. The fix is making redaction structural, not a code-review checklist item skipped under deadline pressure.

Move from string logging to structured logging. Free-text log statements like logger.info("User " + user.email + " placed order " + order) are impossible to redact reliably because the PII is buried in unstructured text. Structured logging — a JSON object with named fields — lets a redaction layer inspect field names and apply rules.

Apply redaction at the logging middleware, not at each call site. Relying on every developer to remember to mask a field before calling logger.info() guarantees leaks; someone will forget, especially on error paths written in a hurry during an incident. A centralized serializer that scrubs known-sensitive field names (aadhaar, pan, password, token, otp, authorization) before anything is written closes that gap structurally.

Use allow-lists for error trackers, not deny-lists. Error-tracking SDKs default to capturing everything in scope for maximum debuggability. Configure them to send only an explicit, reviewed set of fields — a deny-list breaks the first time someone adds a new field to a request object.

Mask, don't just truncate. Partial masking (98XXXXXX10) is far more useful for debugging than either full plaintext or a fully redacted [REDACTED] token, while still reducing identifiability.

Retention limits on logs

The DPDP Act's storage-limitation principle applies to logs like any other personal-data store: don't retain data longer than necessary for the purpose it was collected for. In practice, most companies never set an explicit retention policy on logs — they accumulate indefinitely because nobody actively decides to delete them, and log platforms default to "keep everything" unless configured otherwise.

A defensible retention posture separates logs by purpose:

Access control on log platforms

Log platforms are frequently under-governed relative to the production database that generated the data. It's common for half the engineering org to have broad read access to a centralized logging tool — an ELK stack or a SaaS log platform — when only on-call and platform teams genuinely need it.

Baseline controls worth enforcing:

1. Role-based access scoped to the minimum team that needs it (on-call, platform engineering, security).
2. Separate, more restrictive access for any log stream that hasn't been redaction-verified.
3. Logging and alerting on who queried the log platform and what they searched for — logs about logs, so misuse is detectable.
4. SSO and MFA enforced on the log platform itself, not just the application it monitors.

What an erasure request means for your log pipeline

A data principal erasure request under the DPDP Act asks a company to delete that person's data once the processing purpose is fulfilled or consent is withdrawn (subject to legal retention exceptions). Most companies can execute this against their primary database — but logs are the part of the pipeline erasure requests routinely miss, because nobody maps them as a personal-data location during request fulfillment. A company can delete a user's row, confirm the deletion, and still have that user's phone number and order history sitting in months of unredacted logs, an error tracker, and an analytics warehouse.

Practical steps to close this:

1. Include log platforms and error trackers in your data-mapping inventory alongside the primary database and backups.
2. Redact at write-time so there's nothing to erase later. If PII never reaches long-retention log storage in plaintext, erasure requests against logs become largely moot for those fields.
3. For fields logged in identifiable form for security/audit purposes, tie retention to a defined window and automate deletion, rather than relying on a manual erasure-request trigger.
4. Document the exception where logs are retained past a deletion request for legitimate security or legal-obligation purposes — the DPDP Act permits this, but the exception needs to be recorded, not assumed.

Where personal data typically leaks in a logging stack

A practical checklist to close the gap

Use this as a starting audit for any Indian application handling personal data:

1. Grep production log samples for common PII patterns (phone numbers, email formats, Aadhaar-like sequences) to establish a baseline.
2. Move from string-concatenated logging to structured JSON logging with a shared serializer.
3. Configure a redaction layer at the logging framework level, covering known sensitive field names.
4. Configure error trackers to use field allow-lists, not defaults.
5. Set explicit, automated retention windows per log category, differentiated for security/audit versus debug logs.
6. Restrict log platform access with role-based permissions and log the access itself.
7. Add log platforms and error trackers to your DPDP data-mapping inventory and erasure-request runbook.

Getting this right is rarely a rewrite — it's a middleware change, a retention policy, and an access-control review. Our automated VAPT platform, built by Dhisattva AI Pvt Ltd, includes checks for common log-exposure patterns as part of a broader DPDP-readiness assessment, and — where formal empanelled assessment is required — this is delivered with a CERT-In empanelled partner. Start with a free VAPT scan, read more on the Bachao.AI blog, or see the full program at /dpdp-compliance.