DPDP Rules 2025, Rule 6(1)(e): The One-Year Retention Requirement, and Its Genuine Open Question

Part of a series on DPDPA Section 8(5) and DPDP Rules 2025, Rule 6. Read the pillar post first if you haven’t.

The Clause, Verbatim

“(e) for enabling the detection of unauthorised access, its investigation, remediation to prevent recurrence and continued processing in the event of such a compromise, retain such logs and personal data for a period of one year, unless compliance with any law for the time being in force requires otherwise;”

DPDP Rules 2025, Rule 6(1)(e)

Of all seven sub-clauses, this is the one with the least room for interpretation on its numeric core: one year is one year, not “a reasonable period” or “as appropriate.” That specificity is worth noting on its own, since it’s the exception rather than the rule in this list. But the clause has a second element that’s genuinely ambiguous, and it’s a bigger practical question than the number itself.

What It Technically Requires

Retain access logs for at least one year. Logs of the kind described in Rule 6(1)(c), records of who accessed personal data, when, and how, held for a minimum twelve-month period, so that if unauthorised access surfaces months after it happened, the investigative trail still exists.

A defined retention and deletion schedule, not an indefinite default. “At least one year” implies both a floor (don’t delete before then) and an ordinary practice of eventually deleting once other obligations, including DPDPA’s own data-minimisation principles, come into play.

An exception path for law-mandated retention.The clause explicitly carves out situations where another law requires a different retention period (“unless compliance with any law for the time being in force requires otherwise”), which in practice means retention schedules need to be checked against sector-specific requirements (financial recordkeeping rules, health record retention rules, and so on) rather than defaulting to a single DPDPA-driven policy across every data category.

Secure, access-controlled retention. Retaining logs and data for the purpose of investigation only helps if that retained data is itself protected under the same standards as Rule 6(1)(a) and (b), encrypted, access-controlled, and not just parked somewhere convenient for a year.

Where This Gets Subjective, and Where It Gets Genuinely Uncertain

The number isn’t the hard part here. The scope is.

What does “such logs and personal data” actually cover? Read one way, “such personal data” refers only to the personal data implicated in a specific unauthorised-access event, the data that was actually part of an investigation, retained for the duration needed to complete that investigation and any remediation. Read another way, the clause could be taken to mean personal data generally should be retained for at least one year to preserve the ability to detect and investigate unauthorised access, essentially a standing one-year minimum retention period across a much broader set of personal data than just incident-specific records.

That second reading creates real tension elsewhere in the Act. DPDPA’s broader framework leans toward data minimisation and purpose limitation, data should be retained only as long as necessary for the purpose it was collected for, and erased once that purpose is fulfilled, subject to legal retention requirements. If Rule 6(1)(e) is read as a blanket instruction to hold onto personal data for a year regardless of whether the original processing purpose has already concluded, it sits in some tension with that erasure principle. If it’s read narrowly, tied specifically to the logs and data relevant to security investigation, that tension mostly disappears.

Where the one-year clock starts. The clause doesn’t specify whether the year runs from when a log entry or data point is created, or from some other triggering event. A rolling one-year retention window (delete anything older than 365 days, continuously) and a fixed one-year-from-collection window are both plausible implementations, and they behave differently operationally.

What the Breakdown Really Means

Vimalendukumar Dwivedi is Co-founder of Scrutora, a Code Compliance Platform.