DPDP Rule 6 and Section 8(5) require reasonable security safeguards to prevent a personal data breach. From a mobile app's perspective, that reduces to four points — not the whole Act. It happens to be the clause with ₹250 crore attached.
Rule 6 binds every Data Fiduciary processing personal data through a mobile app, and the Data Processors — like a security SDK vendor — they engage on a contract requiring equivalent safeguards.
We are a Data Processor to you. Rule 6 requires a contract mandating equivalent safeguards — ours is ready to sign.
| Point | What It Means in the App | What Satisfies It in NonaShield |
|---|---|---|
| 1. Hardware-rooted access control | A password or app-level flag isn't access control — it's a claim the app makes about itself, on a device it doesn't control. | A key generated and held in the device's secure element (Android StrongBox/TEE, iOS Secure Enclave), never exportable. |
| 2. Encryption with proof of origin | Encryption alone proves confidentiality, not that the request actually came from your genuine app on the genuine device. | Certificate pinning plus a signed payload on every request — integrity and origin, not just confidentiality. |
| 3. One year of access & processing logs | Rule 6 asks for 365 days of logs; CERT-In's 2022 directions separately ask for 180. Two clocks, easy to under-serve one. | One signed, exportable log retained for a year — the longer of the two requirements, satisfying both at once. |
| 4. The breach class servers cannot see | Overlay attacks, screen capture, keylogging, clipboard scraping and cloned apps take personal data off the device before your servers ever see the request. | On-device RASP detection for exactly this class of attack, at the point of capture — not after the data has already left. |
Instrument: DPDP Act 2023, Section 8(5), and DPDP Rules 2025, Rule 6, Schedule 1. Not legal advice; confirm current requirements with your compliance counsel.
maximum penalty for failing to implement reasonable security safeguards under Section 8(5), per instance, decided by the Data Protection Board of India
maximum penalty for failing to notify the Board and affected data principals of a personal data breach
Both penalties need the same underlying thing to defend against: telemetry the attacker could not have written. A log you can't prove wasn't edited after the fact doesn't help you at the Data Protection Board.
The compliance date for endpoint data-protection safeguards under DPDP Rule 6. Dates are compliance dates, not issue dates, as published by MeitY.
TLS protects data in transit between a genuine app and your server. It says nothing about whether the app itself has been overlaid, screen-captured, or cloned before that request was ever sent — which is exactly the breach class Rule 6's endpoint safeguards target. See how this fits the rest of NonaShield's compliance mapping.
DPDP Rule 6 is one of seven compliance instruments NonaShield maps to on day one — alongside the RBI Digital Payment Security Controls, RBI Authentication Directions, RBI Digital Lending Directions, NPCI's UPI MASF, SEBI CSCRF and CERT-In's retention rules. See the full compliance mapping →
DPDP Rule 6 and Section 8(5) require Data Fiduciaries to take reasonable security safeguards to prevent a personal data breach. From a mobile app's perspective, that reduces to four points: hardware-rooted access control, encryption with proof of origin, one year of access and processing logs, and protection against the breach class a server can't see — overlay, screen capture, keylogging, clipboard and cloned apps.
Up to ₹250 crore for failing to implement reasonable security safeguards under Section 8(5), and up to ₹200 crore for failing to report a breach, decided per instance by the Data Protection Board of India.
No. NonaShield covers the Section 8(5) and Rule 6 security-safeguards clause only — not consent capture, data principal rights, purpose limitation, cross-border transfer governance, or grievance redressal. Those remain the data fiduciary's own privacy programme.
A key in the secure element for access control, pinning and a signed payload for encryption with proof of origin, one year of signed access logs, and on-device detection of overlay, screen capture, keylogging, clipboard and cloned-app attacks — control-mapped on day one, not a roadmap.
Four points, mapped to DPDP Rule 6, for your app.