Implementing DPDP Rule 6 security safeguards: an engineering guide
Rule 6 lists outcome-based minimums — encryption, access control, logs, backups, breach detection — and leaves the "how" to you. Here is a practical mapping for engineering and security teams.
Read Rule 6 the way the Board will
The safeguards obligation (Section 8(5) of the Act, given shape by Rule 6) carries the Act's highest penalty ceiling — and, importantly, it applies even without a breach. A complaint or audit that finds personal data unencrypted, access ungoverned, or logs missing is itself a violation. The framing to build against: could you demonstrate to a regulator, with evidence, that unauthorised access is prevented, detected, and investigable?
Control-by-control implementation
1. Encryption / obfuscation
TLS 1.2+ in transit and AES-256 at rest are table stakes — enable them at the platform layer (RDS, EBS, S3, GCS all offer one-flag encryption). The differentiating move is field-level protection for high-value identifiers: tokenize or hash Aadhaar-adjacent numbers, PAN, and payment identifiers rather than relying only on whole-disk encryption, which does nothing against a compromised application credential. Manage keys in a KMS with rotation; never in code or environment files.
2. Access control
Enforce at the service layer, not just database grants — an auditor asks "who could read this data," not "who did." Practical bar: SSO + MFA everywhere, role-based access mapped to job function, no standing production database access for developers (break-glass with approval and logging instead), quarterly access reviews with recorded outcomes, and immediate revocation on exit. The exit-revocation gap is the single most common finding in our assessments.
3. Logging, monitoring — and the one-year retention floor
Rule 6 sets a minimum one-year retention for logs. Engineering implications: centralize application, database, and infrastructure access logs (who accessed which personal data, when, from where); make them tamper-evident — ship to a separate account or WORM/object-lock storage so an attacker with production access cannot erase their trail; and actually alert on anomalies (bulk reads, off-hours admin access, exports). Logs nobody watches satisfy the letter and fail the purpose.
4. Backups
Backups must exist, be encrypted, be access-controlled like production (a common leak path is the permissive backup bucket), and be tested — a restore drill twice a year with documented results. Remember backups interact with erasure obligations: your deletion SOP needs a defined approach for purging or expiring personal data from backup sets.
5. Breach detection and investigation
The Rules give you 72 hours to notify the Data Protection Board once aware of a breach — and the clock's practical start depends on your detection capability. Minimum stack: alerting on the anomalies above, an incident response runbook with named roles, and the forensic basics (preserved logs, image-before-wipe discipline). Run one tabletop exercise a year; teams that have rehearsed hit the 72-hour window, teams that have not, do not.
Score your safeguards against Rule 6
Free 15-point self-check across encryption, access, logging, backups, and detection — get a gap list in 3 minutes.
Run the safeguards check →If you already run ISO 27001 or RBI cyber framework controls
You are roughly 70% of the way there. The DPDP-specific deltas: personal-data-aware logging (you must be able to say whose data was touched, not just which server), consent-state enforcement in access paths (a withdrawn consent should cut off downstream processing), erasure workflows that actually cascade (including processors and backups), and processor contracts updated with DPDP clauses. Map, do not rebuild — a crosswalk from your existing control set to Rule 6 is usually a two-week exercise, not a re-certification.
Evidence to keep on file
Encryption configuration exports, access review records, log retention policy plus a sample retrieval, backup restore test reports, incident runbook with the last tabletop date, and vendor security clauses. When the Board or a client auditor asks, the companies that answer in days rather than months are the ones that treated evidence as a first-class output of each control.
Frequently asked questions
Does Rule 6 mandate specific technologies or standards?
No. It names control outcomes — encryption/obfuscation, access control, logs with one-year retention, backups, breach detection — and leaves implementation choices to the Data Fiduciary. That flexibility cuts both ways: you choose the stack, but you must be able to justify that your choices are "reasonable" for the volume and sensitivity of data you process.
We are a small SaaS team on AWS. What is the minimum credible setup?
Platform encryption on (RDS/S3/EBS), TLS everywhere, SSO+MFA, IAM roles instead of shared credentials, CloudTrail + application access logs shipped to a separate locked account with 1-year retention, automated encrypted backups with a documented restore test, and GuardDuty or equivalent alerting feeding an incident runbook. All of this is configuration, not procurement.
Do these safeguards apply to our vendors and processors too?
Yes — and the liability stays with you as the Data Fiduciary. Your contracts must obligate processors to equivalent safeguards, and your vendor risk process should verify it (questionnaire minimum, evidence for critical vendors). A processor breach is your 72-hour notification to the Board.