Rule 6 mandates reasonable security safeguards but leaves "reasonable" deliberately open — here's a practical checklist for what to actually build, and how to evidence it.
July 2026 · 7 min read
Section 8(5) of the DPDPA requires every Data Fiduciary to protect personal data through "reasonable security safeguards" against a breach. Rule 6 is where that gets operationalised — it's the closest the Indian framework comes to spelling out what protection actually looks like. It runs to about two pages. What it implies runs considerably longer.
We treat Rule 6 as a floor, not a target. Building your security programme exactly down to the minimum text is a defensible legal position; it's a poor engineering one. Below is what Rule 6 covers, how to evidence each piece, and where the regulation deliberately leaves you to make your own defensible call.
Rule 6 splits safeguards into two categories. Technical controls are about how data is protected at the system level — encryption, access management, logging, testing. Organisational controls are about how people, process, and third parties are governed around that data. Neither layer substitutes for the other. Excellent encryption with no documented procedures behind it is still a gap, no matter how strong the encryption is.
Every store of personal data — production databases, backups, data lakes, exported archives — needs encryption at rest, structured and unstructured alike. This has to be documented: which algorithm, which key-management approach, where the keys live, who controls them, and on what rotation schedule.
On which standard to pick: Rule 6 is technology-neutral, so the choice is yours to justify, and the right baseline depends on where you're starting from. If you're still relying on hashing alone rather than genuine symmetric encryption, moving to AES-256 for data at rest is the current industry floor and defensible for most Indian enterprises today. Larger organisations — Significant Data Fiduciary candidates, financial institutions, health-data processors — should be going a step further and assessing Post-Quantum Cryptography readiness. NIST finalised its first PQC standards in 2024, and while quantum threats aren't imminent for most Indian businesses, entities holding long-lived records (financial histories, health data) face a harvest-now-decrypt-later exposure that makes starting the PQC assessment now, not in five years, the proportionate call. In short: SHA-only is inadequate, AES-256 is today's baseline, and hybrid AES-plus-PQC is the forward-looking posture for high-sensitivity, high-volume processors. Document where you sit and why.
Every network movement of personal data needs encryption in transit — TLS 1.2 as the practical floor, TLS 1.3 as our recommendation for anything new. Internal service-to-service traffic doesn't get a pass here. A common failure pattern is strong perimeter TLS with plaintext traffic between microservices inside the VPC. Rule 6 draws no line between perimeter and internal.
Access to personal data has to be limited to people who need it for their function, and that need has to be documented — "the developer needed it" isn't a justification on its own.
This splits into two distinct layers, and both need to be built. Identity and Access Control (IAC) covers every identity that touches personal-data systems — employees, service accounts, contractors, vendors — with role- or attribute-based access mapped to actual job functions, and a joiner-mover-leaver process that revokes or updates access automatically at the moment of change, not on a quarterly clean-up. Privileged Access Management (PAM) covers the narrower, higher-risk layer: DBAs, platform engineers, DevOps accounts, and break-glass credentials with elevated reach. Privileged sessions should be time-limited, recorded, and gated behind a formal request. Shared admin logins don't square with Rule 6's expectation that access is attributable to a person.
Section 8(4) of the Act reinforces this from another angle: accuracy and completeness of data are only achievable when access is controlled, attributable, and auditable at both layers.
Every system holding personal data needs tamper-evident logs of who accessed what, when, and what changed — stored separately from the systems they watch, so a compromised production database can't also let an attacker rewrite the trail describing the compromise. Coverage needs to span both application-layer events (API calls, record reads) and infrastructure-layer events (admin console access, backup downloads, privileged sessions).
Rule 6 explicitly calls for periodic VAPT, and it needs to cover the full stack — applications, APIs, infrastructure, network perimeter — not a perimeter scan alone, from both internal and external vantage points. Findings need to be documented, triaged by severity, and tracked to closure, not just filed.
An unpatched system is a known, standing vulnerability, so your patch programme needs a defined SLA. We treat 72 hours for actively exploited CVEs and 30 days for high-severity ones as defensible benchmarks, covering operating systems, middleware, databases, and third-party libraries. Your evidence here is a patch log with timestamps plus a written SLA policy.
Rule 6 needs an owner, not a department. It doesn't have to be a formally appointed Data Protection Officer — though if you process data at scale, Section 10 may already require one — but it does require a specific person with documented ownership of the programme, authority to escalate, and accountability to leadership.
Every category of personal data you process needs its own written procedure covering collection, storage, access, sharing, and deletion. A generic catch-all policy doesn't satisfy this — a procedure for health data should read differently from one for financial data, and the Data Protection Board will expect that difference to be visible.
Everyone who touches personal data — not just the security team — needs role-appropriate training on handling obligations and breach recognition, on a recurring cadence with completion records, not a one-time onboarding tick-box.
Any Data Processor handling data on your behalf needs to be contractually bound to the same standard you hold yourself to. Rule 6's obligations flow downstream, so contracts need explicit clauses on encryption, access restrictions, breach-notification timelines, audit rights, and deletion on termination.
Build a formal schedule: quarterly access reviews, half-yearly VAPT cycles for higher-risk systems, and annual reviews of every policy and procedure. That calendar is itself a document you'll be showing an auditor.
Rule 6 uses "periodic" without ever defining a frequency. Calibrate it to risk, not convenience. A fintech handling financial data justifies quarterly VAPT; an HR system with employee records might justify half-yearly; a low-risk internal tool with minimal personal data might justify annual. Write down the reasoning behind whichever cadence you pick — if a breach hits a high-risk system whose last VAPT was eighteen months ago, "the rule doesn't specify a frequency" won't hold up as a defence.
The Data Protection Board won't take verbal assurances. Your evidence pack should include a security policy citing Rule 6 explicitly and signed by accountable leadership; a data asset register mapping every personal-data store to its encryption status and access configuration; IAC and PAM matrices showing role-to-permission mappings with documented justification; the last two VAPT reports with closure evidence; patch logs demonstrating SLA adherence; training completion records; a processor DPA index listing every contract and its Rule 6 clauses; and a review calendar showing what's scheduled and what's actually been completed. Keep it current — audit readiness is a state you maintain, not a sprint you run once a notice lands.
Rule 6 doesn't name an encryption algorithm, a key length, or a VAPT frequency. That's deliberate — a technology-neutral rule doesn't go stale as standards move. The right response to that gap is to adopt a recognised standard and write down why: AES-256 at rest and TLS 1.3 in transit as your baselines, a PQC assessment timeline layered on top if you're in a regulated or high-sensitivity sector, and a VAPT cadence set by the risk logic above. The point is to show your choices were deliberate and proportionate — not that you found a clever way to do the minimum.
Rule 6 hands you a framework with real flexibility. Use it to build a programme sized to your actual data risk, not to whatever the text will technically tolerate. Document every choice, review on a real schedule, and treat your audit evidence as something you maintain continuously, not assemble the week a notice arrives.
Turning "reasonable" into something you can actually evidence is what our security posture assessment is built for.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation