Rule 6 Is Short. Your Implementation Shouldn't Be.
Section 8(5) of the Digital Personal Data Protection Act requires every Data Fiduciary to protect personal data "by taking reasonable security safeguards to prevent personal data breach." Rule 6 of the DPDPA Rules operationalises this obligation, it is the closest the Indian framework comes to specifying what that protection looks like in practice. At two pages, Rule 6 is deceptively brief. The implementation it implies is not.
We treat Rule 6 as a floor, not a ceiling. Building your security programme down to the minimum is a viable legal strategy; it is not a good engineering strategy. This guide covers everything Rule 6 requires, how to evidence it, and where you have to make your own defensible choices because the regulation intentionally leaves gaps.
The Two Layers: Technical and Organizational
Rule 6 frames safeguards across two distinct categories. Technical controls address how data is protected at the system level: encryption, access management, logging, testing. Organizational controls address how people, processes, and third parties are governed around that data. Both layers must be present. Strong technical controls with no documented procedures are still a finding, regardless of how good the encryption is.
Technical Safeguards: The Checklist
Encryption at Rest
Every personal data store, production databases, backups, data lakes, archived exports, must be encrypted at rest. This applies to structured stores (RDBMS, NoSQL) as well as unstructured ones (S3-equivalent buckets, file shares). The encryption must be documented: which algorithm, which key management approach, where keys are stored, and who controls them. Key rotation schedules belong in this documentation.
On encryption standard selection: Rule 6 is technology-neutral, so the choice of algorithm is yours to justify. The right baseline depends on where your organisation sits.
For most organisations that are still relying on hashing alone (SHA-256 applied to data fields rather than proper symmetric encryption), the first step is adopting AES-256 for data at rest. This is the current industry floor and defensible for the vast majority of Indian enterprises today.
Larger organisations, SDF candidates, financial institutions, and health data processors should go further and begin assessing Post-Quantum Cryptography (PQC) readiness. NIST finalised its first PQC standards in 2024. Quantum threats are not imminent for most Indian enterprises, but regulated entities with long data lifespans (financial records, health histories) face harvest-now-decrypt-later risks that make PQC planning relevant today, not in five years. The migration is a multi-year programme; starting the assessment now is proportionate for that profile.
The progression, in practical terms: SHA-only (inadequate) to AES-256 (current baseline) to hybrid AES + PQC (forward-looking for high-sensitivity, high-volume processors). Document where you are and why.
Encryption in Transit
All personal data moving across a network must be encrypted in transit. TLS 1.2 is the practical minimum; TLS 1.3 is what we recommend for any new implementation. Internal service-to-service traffic is not exempt. A common gap is strong perimeter encryption but plaintext traffic between microservices inside a VPC. Rule 6 does not distinguish perimeter from internal.
Access Control: IAC and PAM
Access to personal data must be restricted to individuals who require it to perform their function, and those justifications must be documented. "The developer needed access" is not a justification.
Access control under Rule 6 operates across two distinct layers that must both be implemented.
Identity and Access Control (IAC) covers all identities interacting with personal data systems: employees, service accounts, contractors, vendors. Role-based access control (RBAC) or attribute-based access control (ABAC) configurations should map directly to job functions. The joiner-mover-leaver process must revoke or modify access automatically at departure or role change, not on a quarterly cleanup cycle.
Privileged Access Management (PAM) addresses a narrower but higher-risk layer: the accounts with elevated permissions to personal data infrastructure, database administrators, platform engineers, DevOps accounts, break-glass credentials. Privileged sessions should be recorded, time-limited, and approved through a formal request workflow. Shared admin credentials are not compatible with Rule 6's accountability requirements.
Section 8(4) of the Act reinforces this: Data Fiduciaries must ensure accuracy and completeness of data, which is only possible when access is controlled, attributable, and auditable at both the IAC and PAM layers.
Access and Activity Logs
Every system holding personal data must generate tamper-evident logs of who accessed which records, when, and what changes were made. Logs must be stored separately from the systems they monitor. An attacker who compromises a production database should not be able to alter the access trail. The logging perimeter must include both application-layer events (API calls, record reads) and infrastructure-layer events (admin console access, backup downloads, privileged session activity).
Periodic Vulnerability Assessment and Penetration Testing
Rule 6 explicitly calls for periodic vulnerability assessments. VAPT must cover the full stack: applications, APIs, infrastructure, and network perimeter, not just a perimeter scan. Internal and external testing perspectives are both required. Results must be documented, findings triaged by severity, and remediation tracked to closure.
Patch Management with Critical SLAs
An unpatched system is a known vulnerability. Your patch management programme needs a defined SLA for critical patches. In our experience, 72 hours for actively exploited CVEs and 30 days for high-severity ones are defensible benchmarks. The programme must cover operating systems, middleware, databases, and third-party libraries. Evidence for this control is a patch log with timestamps and a policy document stating the SLAs.
Organizational Safeguards: The Checklist
Named Accountability
Rule 6 compliance must have an owner. This does not have to be a Data Protection Officer, though if your organisation processes data at scale, Section 10 of the Act may already require you to appoint one. What it does require is a named individual with documented Rule 6 ownership: responsible for the programme, empowered to escalate, and accountable to leadership.
Documented Data Handling Procedures
For each category of personal data you process, there must be a written procedure covering how it is collected, stored, accessed, shared, and deleted. Generic catch-all procedures do not satisfy this. A procedure for health data and a procedure for financial data look different, and the DPBI will expect them to look different.
Staff Training
Everyone who touches personal data, not just the security team, needs role-appropriate training on data handling obligations and breach recognition. Training must be periodic, not a one-time onboarding checkbox, and completion records must be maintained.
Third-Party Processor Contracts
Any Data Processor handling personal data on your behalf must be contractually bound to the same security standards you observe. Rule 6 obligations flow downstream. Contracts need explicit clauses covering encryption standards, access restrictions, incident notification timelines, right to audit, and data deletion on contract termination.
Periodic Review Calendar
Build a formal review calendar: quarterly access reviews (who still needs access to what), half-yearly VAPT cycles for high-risk systems, and annual reviews of all policies and procedures. The review schedule itself is a document you will show an auditor.
What "Periodic" Actually Means
Rule 6 uses the word "periodic" for reviews and assessments but does not define a frequency. Periodicity should be calibrated to data risk, not to convenience. A fintech processing financial data warrants quarterly VAPT. An HR system holding employee records might justify half-yearly reviews. A low-risk internal tool with minimal personal data could justify annual. Document your rationale for whatever frequency you choose. If a breach occurs and your VAPT was last run eighteen months ago for a high-risk system, the gap will look indefensible regardless of what the rule technically requires.
Evidencing Rule 6 Compliance for a DPBI Audit
The Digital Personal Data Protection Board will not accept verbal assurances. Build an evidence pack that includes:
A security policy document citing Rule 6 explicitly and signed by accountable leadership. A data asset register mapping every personal data store to its encryption status and access control configuration. IAC and PAM matrices showing role-to-permission mappings with documented justifications and privileged account inventories. VAPT reports (most recent two cycles) with remediation closure evidence. Patch logs demonstrating SLA adherence. Training completion records with dates. A third-party DPA index listing every processor contract and its Rule 6 clauses. A review calendar showing scheduled and completed review activities.
Keep this evidence pack current. Audit readiness is not a sprint you run before a notice arrives; it is the state you should already be in.
The Grey Zone: What Rule 6 Deliberately Leaves Blank
Rule 6 does not specify an encryption algorithm or key length. It does not mandate a specific VAPT frequency. This is intentional: the regulation is technology-neutral so it does not become obsolete as standards evolve.
The right approach for these gaps is to adopt a recognised standard and document it. For encryption, AES-256 for data at rest and TLS 1.3 for data in transit are current industry baselines: choose them and say so. Add your PQC assessment timeline if you are in a regulated or high-sensitivity sector. For VAPT frequency, use the risk-calibration logic above. The goal is to show that your choices were deliberate, informed by recognised standards, and proportionate to your data risk profile, not arbitrary.
The Bottom Line
Rule 6 gives you a framework with intentional flexibility. Use that flexibility to build a programme proportionate to your actual data risk, not to the minimum the text will tolerate. Document every choice, review on a schedule, and treat audit evidence as a living artefact rather than a last-minute assembly job.
Download the DPDPA Compliance Guidebook at truconsent.io/guide for templates, checklists, and DPA clause language you can adapt directly for your Rule 6 programme.