Short answer: From 13 May 2027, an app must take reasonable security safeguards to prevent personal data breaches (s.8(5)), and it stays responsible for processing its processors carry out on its behalf (s.8(1)). Rule 6 lists the minimum measures, such as encryption or masking, access controls, monitoring logs kept for one year, backups and security clauses in processor contracts. Failure carries the Act's highest penalty, up to ₹250 crore.
What are reasonable security safeguards under the DPDP Act?
Reasonable security safeguards are the technical and organisational measures a Data Fiduciary must take to prevent a personal data breach, with Rule 6 setting the minimum (s.8(4), s.8(5), Rule 6).
- Personal data breach: any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of personal data (s.2(u)).
- Virtual token: a token mapped to personal data, listed in Rule 6(1)(a) as a security measure alongside encryption, obfuscation and masking.
What does Rule 6 require at a minimum?
Rule 6(1) lists seven minimum measures: encryption, obfuscation, masking or virtual tokens; access controls; logs, monitoring and review; backups and continuity; one-year retention of logs and personal data for investigating unauthorised access; security provisions in processor contracts; and appropriate technical and organisational measures.
| Rule | Minimum measure | Typical app control |
|---|---|---|
| 6(1)(a) | Encryption, obfuscation, masking or virtual tokens mapped to personal data | Encryption in transit and at rest, tokenised identifiers |
| 6(1)(b) | Access controls | Role-based access, least privilege, MFA for staff |
| 6(1)(c) | Logs, monitoring and review | Access logs, alerting, periodic review |
| 6(1)(d) | Backups and continuity measures | Backups, restore testing, incident runbooks |
| 6(1)(e) | Retain logs and personal data for one year to detect and investigate unauthorised access | Log retention policy of at least one year |
| 6(1)(f) | Contractual provision with Data Processors for safeguards | Security clauses in SDK and cloud contracts |
| 6(1)(g) | Appropriate technical and organisational measures | Policies, training, ownership |
The typical controls in the third column are common industry examples, not text from the Rules.
Does hashing or masking take data outside the Act?
Not on the face of the Rules. Rule 6(1)(a) lists masking, obfuscation and virtual tokens mapped to personal data as security measures, not as ways of taking data outside the Act.
- Interpretation: law firm commentary (AMLEGALS) reports that hashing does not take an identifier outside the Act if it remains linkable to an individual. No Board or court ruling exists yet.
Are processors covered?
Yes. The app is responsible for processing carried out on its behalf by a Data Processor, irrespective of any agreement to the contrary (s.8(1)). Rule 6(1)(f) requires a contractual provision with each processor for reasonable safeguards. See processors and SDKs.
How does this sit with existing Indian law?
- IT Act s.43A: compensation for failure to protect sensitive personal data is omitted by s.44(2) of the DPDP Act, which takes effect on 13 May 2027.
- Interpretation: until 13 May 2027, s.43A of the IT Act and the IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 continue to apply, because s.44(2) has not yet commenced. The commencement notification does not say this expressly.
- CERT-In Directions (28 April 2022): a separate regime under the IT Act, already in force, requiring specified cyber incidents to be reported to CERT-In within 6 hours and ICT system logs to be kept for 180 days in India.
What is the penalty for weak security?
Failure to take reasonable security safeguards to prevent a personal data breach carries a penalty of up to ₹250 crore, the highest amount in the Schedule (Schedule item 1). The Board sets the amount after an inquiry, considering factors such as the gravity and duration of the breach and the mitigation taken (s.33). See the penalties page.
What this means for your app
These are practical steps teams commonly consider. They are not a guarantee of compliance.
- Consider mapping each Rule 6(1) measure to a named control and owner, and recording evidence that it operates.
- A common approach is encryption in transit and at rest for all personal data, with tokenised or hashed identifiers in analytics pipelines, while treating these as safeguards rather than exemptions.
- Review staff and vendor access to production data and remove access that is not needed.
- Consider setting log retention to at least one year for systems that process personal data, to meet Rule 6(1)(e) and Rule 8(3).
- Add security clauses to contracts with cloud providers, SDK vendors and other processors (Rule 6(1)(f)).
- Test backups and incident response, and link the runbook to the breach notification steps.
- Track progress in the readiness checklist.