Rule 6 — Reasonable Security Safeguards

Section 8(5) of the Act requires a Data Fiduciary to protect personal data through "reasonable security safeguards," without saying what that phrase actually covers. Rule 6 answers that, and it answers it as a floor, not a menu — the opening line states the seven paragraphs that follow apply "at the minimum," meaning a Data Fiduciary can't treat any one of them as optional by pointing to strength somewhere else. Using cloud infrastructure, following good coding practices, or never having reported a breach doesn't establish that these seven minimums are actually met; each is its own, separately assessable obligation.

Rendering data unintelligible — Rule 6(a)

Appropriate data security measures — encryption, obfuscation, masking, or virtual tokens mapped to the underlying personal data — so that data, if accessed without authorisation, isn't directly readable or usable. The obligation isn't satisfied by encrypting data at the database layer while it still shows up in plain text in internal tools, exports, logs, or analytics pipelines; Rule 6(a) is met only when unauthorised access fails to produce anything intelligible, across every layer the data actually passes through.

Controlling who gets in — Rule 6(b)

Appropriate measures to control access to the computer resources a Data Fiduciary or its Data Processor uses, wherever applicable. Rule 6(2) borrows the definition of "computer resource" directly from the Information Technology Act, 2000, so this covers the systems, networks and devices actually handling the data, not just the application layer a user sees.

Seeing who got in — Rule 6(c) and Rule 6(e)

Visibility on access to personal data, through appropriate logs, monitoring and review, so unauthorised access can be detected, investigated and remediated — and Rule 6(e) sets a minimum retention period for that same data: one year, for logs and the personal data itself, unless some other law requires a different period. Together these two paragraphs are about reconstruction after the fact — if an organisation can't reliably show who accessed what personal data, when, and through which system, having access controls and monitoring tools in place doesn't satisfy the obligation on its own; fragmented, prematurely overwritten, or unreviewed logs leave (c) and (e) effectively unmet even where the tooling exists.

Staying operational after something breaks — Rule 6(d)

Reasonable measures for continued processing if the confidentiality, integrity or availability of personal data is compromised — through destruction, loss of access, or otherwise — such as by way of data backups. This paragraph is about what happens after a failure, not about preventing one: backups have to actually be restorable and independent of whatever environment was compromised, not merely present. A backup regime that exists on paper but depends on the same compromised systems, or has never been tested for restoration, doesn't meet this obligation just because backups are technically being taken.

Binding the processor — Rule 6(f)

Appropriate provision, wherever applicable, in the contract between the Data Fiduciary and its Data Processor, for taking reasonable security safeguards. This is where Rule 6 meets Section 8(2)'s requirement that a Data Processor only ever be engaged under a valid contract — a contract that references "applicable law" or "industry standards" in general terms, without binding the processor to specific, enforceable DPDP security obligations, doesn't discharge Rule 6(f). Outsourcing the processing doesn't outsource the accountability.

Making it actually work — Rule 6(g)

Appropriate technical and organisational measures to ensure effective observance of the other six safeguards. This closing paragraph is the one that turns the preceding six from documented policy into demonstrated practice — role-based responsibility, staff training, and security-by-design choices that make (a) through (f) real in day-to-day operation rather than aspirational on paper.

Why this matters in practice

Security failures under Section 8(5) sit alongside breach-notification failures under Section 8(6) as the obligations Section 33's penalty framework treats most seriously — a security shortfall can draw penalties up to ₹250 crore, scaled by the seven factors Section 33(2) lists. What tends to fail an audit isn't the absence of a control category — most organisations have encryption, access controls and backups in some form already. It's the inability to explain, for any given control, why it exists, what risk it addresses, how it's actually enforced day to day, and what residual risk remains once it's in place. That explanation is what separates a control that exists from a safeguard that satisfies Rule 6.

Illustration: a logistics company encrypts customer address data at rest in its primary database, satisfying part of 6(a). But its customer-support tool displays the same addresses in plain text to any agent who opens a ticket, with no access logging on that tool at all. Encryption at the database layer doesn't rescue the gap in 6(c) — the organisation still can't reconstruct who viewed which customer's address through the support tool, which is exactly the visibility Rule 6(c) requires.

How Rule 6 connects to the rest of the Rules and the Act

Rule 6 gives operational content to Section 8(5), which Section 17(1) refuses to exempt even where government functions are otherwise carved out of Chapter II — the legislature treated this as non-negotiable regardless of who's processing. Rule 7's breach-notification duty is the reactive counterpart to Rule 6's preventive safeguards — the stronger the safeguards, the less often Rule 7 gets triggered at all. And Rule 8(3) sets its own separate one-year minimum retention for processing logs, running alongside Rule 6(e)'s one-year log-retention floor for security-monitoring purposes.