DPDP: Logs, Evidence And DPDP

Logs, Evidence And DPDP

Why Good Logging Is Now A Legal Requirement, Not Just An IT Nice-To-Have

Published by Vishwaas.ai | DPDP Series

1. From Optional Logging To Legal Obligation

Most organisations already generate logs - server logs, application logs, audit trails. But under the DPDP Act and DPDP Rules 2025, logging is no longer just a technical hygiene practice. It becomes one of the formal ways in which you prove that you took reasonable security safeguards and handled personal data responsibly.

Rule 6 of the DPDP Rules treats logging, monitoring and review as part of the mandatory safeguard package, alongside controls like encryption and access management. Rule 8 adds a minimum one-year retention floor for personal data, traffic data and processing logs.

If logs are missing, weak or short-lived, it is not just an IT issue. It can become direct evidence of non-compliance.

2. What DPDP Actually Says About Logs

DPDP does not use marketing language for logging. It gives concrete expectations. Organisations must capture appropriate logs to detect and investigate unauthorised access, retain logs for at least one year from the date of processing, and be able to show those logs to the Data Protection Board during investigations or audits.

This applies not only to core systems, but across the data lifecycle - collection, access, modification, transfer, erasure and breach handling.

In other words, every important step in the personal-data story should leave a trace.

3. The Eight Log Categories That Matter Most

Different organisations will design logs differently, but recent guidance highlights eight categories that matter most for DPDP evidence:

• Access logs - who accessed what data, when and from where.

• Authentication logs - logins, MFA events, session starts and failures.

• Modification logs - changes to personal data and key processing parameters.

• Processor activity logs - what Data Processors did on your behalf.

• Consent update logs - grants, changes and withdrawals over time.

• Deletion logs - when personal data was erased, by whom and at what scope.

• Breach detection logs - alerts and anomaly events from security monitoring.

• System anomaly logs - unusual patterns in access, authentication or data movement.

Collectively, these logs form the backbone of DPDP evidence.

4. The One-Year Retention Floor And The Erasure Paradox

Section 8 of the DPDP Act and Rule 8 of the Rules create a tension that every organisation has to resolve. On one side, you must erase personal data once the purpose is complete or consent is withdrawn, unless there is a legal reason to keep it. On the other side, you must retain logs of processing, including personal data embedded in those logs, for at least one year from the date of processing.

Practitioners often call this the erasure-retention paradox. In simple terms: you cannot keep raw user data longer than necessary, but you also cannot delete all traces of it too soon because logs must remain available for investigation and compliance.

Good logging design is about balancing those two obligations.

5. How To Resolve The Erasure-Retention Tension

The emerging best practice is to treat operational data and log data differently. Operational data - profiles, orders, messages - should follow the purpose-first, consent-sensitive retention journey. Log data - access events, transaction records, deletion confirmations - should follow the one-year minimum, sometimes longer when other laws demand it.

Organisations can reduce risk by pseudonymising or minimising personally identifiable fields in logs, while still retaining enough detail for forensic and audit purposes.

This way, logs support compliance without becoming a shadow copy of the entire production database.

6. Why Logs Are Central To Breach Response

Rule 7’s breach-notification structure makes logging critical. On becoming aware of a personal data breach, a Data Fiduciary must notify the Data Protection Board without delay, and then provide a more detailed account within a defined window.

Without good logs, it is almost impossible to answer basic questions: Which data was affected? Who accessed it? When did the breach start? How was it detected? What measures were taken?

Strong logging turns breach response from guesswork into evidence-based reporting.

7. Logs And Rights Requests

Logging is not just about security. It also supports rights handling. When a Data Principal asks for access, correction or erasure, logs can show when the request was received, how it was routed, what actions were taken and when closure happened.

This matters because implementation guidance around DPDP expects organisations to resolve rights requests within defined timeframes and to provide meaningful proof of action if the case ever reaches the Data Protection Board.

Without logs, it is hard to demonstrate that rights were honoured in practice.

8. What A DPDP-Ready Logging Stack Looks Like

Recent commentary suggests that a DPDP-ready logging stack usually has three characteristics: centralised, correlated and protected.

Centralised means logs from key systems and processors feed into a unified location. Correlated means different log types can be linked together to reconstruct incidents and user journeys. Protected means logs are write-protected, tamper-evident and retained for the required period.

Whether this is achieved through a SIEM, a logging platform or a well-built in-house solution, the DPDP obligations remain the same.

9. Practical Steps For Product, Security And Ops Teams

To align logging with DPDP, teams can start with some simple but powerful steps:

• Identify which logs currently exist and where they are stored.

• Check whether logs capture key events across access, consent, modification and deletion.

• Ensure logs are retained for at least one year and protected against tampering.

• Connect logging to breach playbooks and rights-handling workflows.

• Include processor activity in the logging scope, not just internal systems.

This makes logging part of everyday operations rather than a niche IT project.

10. Where Vishwaas.AI® Fits

As DPDP enforcement gets closer, organisations will need platforms that can make logging and evidence less mysterious. Vishwaas.AI® can help by connecting logs to data flows, consent events, breach notifications and rights workflows, so that compliance is visible instead of hidden.

That way, logs stop being just an archive and become what DPDP expects them to be: a living evidence trail of how you protect people’s data.

In a world where privacy law is getting sharper, good logging is one of the clearest ways to show that your organisation takes trust seriously.

(c)Vishwaas.ai | DPDP Compliance Made Simple