The Rule Says Log Everything. Your Logs Are the Leak.

It is May 2027. Rule 6 of the DPDP Rules is now enforceable, and an email from the Data Protection Board arrives:

“Please provide evidence that access to personal data in your systems is logged, monitored and reviewed.”

Not your policy. Not your SOC 2 report. Evidence.

What do you send?

If your first instinct is to attach a PDF, you have already answered the question.

If that makes you uncomfortable, good. This series exists to make it stop being uncomfortable, one rule at a time. Each post takes a single clause of the DPDP Rules, asks what evidence would actually satisfy it, shows the gap between what organisations claim and what their software does, and then shows how we close that gap.

The Rule

Rule 6 of the Digital Personal Data Protection Rules, 2025 defines the minimum security safeguards every Data Fiduciary must implement. Clause (1)(c) requires visibility on the accessing of personal data through appropriate logs, monitoring and review, so that unauthorised access can be detected, investigated and remediated. Rule 6(1)(e) then requires those logs and associated data to be retained for at least one year, so investigations can actually happen.

Read clause (c) carefully. It does not ask whether you have logs. It asks whether your logs let you detect unauthorised access to personal data. Those are very different questions, and the penalty ceiling for failing on security safeguards under Section 8(5) of the Act is 250 crore rupees.

The Illusion

Most organisations believe they already satisfy this. Ask them for evidence and you will receive some combination of the following: a logging and monitoring policy, written once and reviewed annually. An ISO 27001 or SOC 2 certificate attesting, at a point in time, that a process was described convincingly to an auditor. A security questionnaire where an engineer ticked “Yes” next to “Do you log access to sensitive data?” A dashboard screenshot from the week before the audit.

None of these demonstrate, by themselves, what the running system actually does. Policies describe intent. Evidence describes reality. The certificate attests that the intent was described well to an auditor. The questionnaire records that someone believed the intent was implemented. Very few organisations continuously verify any of it at the code level, because compliance evidence has been built for two decades on the assumption that nobody reads code.

The Reality

Here is what the code is usually doing while the policy PDF sits in a shared drive.

Every company says they log everything. That is the problem, because “everything” usually includes names, email addresses, phone numbers, session tokens, full API payloads, exception dumps, and entire user objects. This line looks harmless:

logger.error("User registration failed: {}", request);

But if the request contains:

{
  "name": "Rahul",
  "email": "rahul@example.com",
  "phone": "9876543210",
  "id_number": "XXXX-XXXX-1234"
}

you have just written personal data into a log file. Every debug statement is a compliance decision, whether the developer knows it or not. From there it flows to CloudWatch, ELK, Splunk or Datadog, where every engineer with log access can search it. Now add Rule 6(1)(e): those logs must be retained for a year. The personal data that leaked into them is now retained, replicated across aggregators and backups, and readable across the engineering organisation, for a year, by legal mandate.

The safer version of that line, for the record:

logger.error("User registration failed: requestId={}, errorCode={}", requestId, errorCode);

Log identifiers and outcomes. Never log the payload.

The Evidence Test

So back to the email. A defensible answer to the Board has three parts, and none of them is a policy.

First, proof that personal data does not flow into your logs. Second, proof that access paths to personal data are actually instrumented with logging. Third, proof that both of those statements were true continuously, not just on the day someone checked.

How We Verify It

Solving this is not about buying another SIEM. A SIEM analyses events after the application emits them. The harder question is whether the application should have emitted those events in the first place, and whether the events that matter are being emitted at all. Those questions can only be answered by analysing the code.

That is what our platform does. We start where personal data enters the application. We follow it across files, helper methods, services and API layers until it reaches storage, leaves the system, or lands inside a log statement. If it reaches a log, we show the exact path that made it happen: the file, the line, and every hop in between. The same analysis runs in reverse: if code paths that access personal data stores carry no logging instrumentation at all, that absence is flagged as a finding against Rule 6(1)(c). Infrastructure checks then confirm that retention, monitoring and alerting are actually configured in your Terraform, Kubernetes and cloud accounts, not just described in a document.

Engineering Checklist

While the lawyers work on the policy, engineering can start today:

• 1Identify every entry point for personal data: HTTP requests, message queues, file imports, third-party APIs.
• 2Search for logger calls that accept request, response, user or payload objects. Grep helps, but it cannot trace data across function calls, services or files, so treat it as triage, not proof.
• 3Replace payload logging with identifiers: request IDs, error codes, correlation IDs.
• 4Instrument read access to personal data stores, not just writes.
• 5Verify log retention configuration aligns with the one-year requirement under Rule 6(1)(e).
• 6Automate all of the above in CI, so every commit generates evidence. A check that runs once is a snapshot, and Rule 6(1)(c) demands a film.

Key Takeaway

The Rule 6 security safeguard obligations become enforceable around May 2027. Organisations that start collecting code-level evidence now will walk into it with a year of continuous proof. Organisations that start in early 2027 will walk in with a freshly written policy.

Policies explain what you intended. Code proves what you built. Regulators investigate the second one.

Next in this series: Rule 6(1)(a), and why “we encrypt everything” is the most confidently false sentence in Indian software.