DPDPA Section 8(5) and Rule 6, Explained: What “Reasonable Security Safeguards” Actually Requires

If you’ve searched for what DPDPA Section 8(5) actually requires, you’ve probably already found the sentence. It’s short:

“A Data Fiduciary shall protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach.”

Digital Personal Data Protection Act, 2023, Section 8(5)

That’s it. One sentence, no sub-clauses, no named technology, no minimum spec. If you’re an engineer or a security lead being told to “make sure we’re compliant with 8(5),” this sentence alone doesn’t tell you what to build. It’s a legal standard, not a technical one, and it was written that way on purpose. Legislation that names specific algorithms or vendors goes stale the moment the technology moves on. “Reasonable” doesn’t.

The catch is that “reasonable” only means something in context. Reasonable for a five-person SaaS company processing email addresses is not the same as reasonable for a hospital chain processing Aadhaar numbers and treatment records. The Act leaves that calibration to you, and to whoever eventually evaluates whether your safeguards held up.

That’s where Rule 6 comes in.

Rule 6: The Floor, Not the Ceiling

The DPDP Rules 2025 operationalise Section 8(5) through Rule 6, which lists seven measures every Data Fiduciary’s security safeguards must include “at the minimum.” Here’s the full list, each of which gets its own deep-dive in this series:

That word “minimum” is worth sitting with. Rule 6 doesn’t define what reasonable looks like for your organisation. It defines the floor everyone is expected to clear before the conversation about reasonableness even starts. Clearing all seven items tells an auditor, or a Data Protection Board, that you did the baseline work. It doesn’t, by itself, prove that baseline was sufficient for the specific data you hold and the specific risk you carry.

Why the Same Clause Reads Differently at Every Company

This is the part most compliance checklists skip, and it’s the reason we’re writing this as a series instead of a single page. Rule 6 is short by design, which means almost every clause in it can be honestly implemented in more than one way.

Take Rule 6(1)(a): “securing of personal data through encryption, obfuscation, masking or the use of virtual tokens.” A company that encrypts its production database at rest can point to that sentence and say it’s compliant. So can a company that additionally tokenises PII in every analytics pipeline, rotates keys quarterly, and masks personal data in every log line. Both are defensible readings of the same seven words. Only one of them would survive scrutiny after an actual breach.

That gap between “technically present” and “actually adequate” runs through every clause in Rule 6, and it’s exactly what a checklist can’t capture. A scanner can tell you whether a field is encrypted. It can’t tell you whether that level of protection was proportionate to how sensitive the field actually was, and neither can we, in the abstract, without knowing your data and your risk. What we can do is walk through where the ambiguity sits in each clause, so you’re making that judgment call deliberately instead of by accident.

What This Series Covers

Each post in this series takes one Rule 6(1) sub-clause and works through three things:

1. What it technically requires. The verbatim clause, and the concrete engineering controls that satisfy it in practice, not just the legal paraphrase.
2. Where interpretation gets subjective. The specific point in the clause where two reasonable security teams could implement it differently and both claim compliance, and why that gap matters.
3. What the breakdown actually means. How to read the clause in the context of “reasonable,” not just “present.”

If you landed here searching for a specific sub-clause, like Rule 6(1)(f) and what “appropriate provision in the contract” really means for your vendor agreements, jump straight to that post from the table above. If you’re mapping your whole security programme against DPDPA for the first time, we’d suggest reading them in order.

A Note Before You Read Further

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