TheDPDPAct.com -
Official WhatsApp Channel
Stay updated with the latest DPDP Act news, compliance insights, updates, and resources.
Join Our WhatsApp Channel →Most DPDP compliance conversations start in the legal department. They produce updated privacy policies, revised consent flows, and a gap analysis mapped against the Act's statutory requirements. That work matters. But it addresses roughly half of what the DPDP Act actually demands — and frequently not the half that carries the largest penalty exposure.
Section 8(5) of the Act imposes the obligation to implement reasonable security safeguards to prevent a personal data breach. The penalty for failing this obligation is up to INR 250 crore — the highest figure in the entire penalty schedule, sitting above breach notification failures (INR 200 crore) and Significant Data Fiduciary obligation failures (INR 150 crore). The Act placed its heaviest financial consequence on a technical and infrastructure obligation, not a legal one. That sequencing is deliberate, and it deserves more attention than most compliance programs are currently giving it.
What "Reasonable Security Safeguards" Actually Requires
Rule 6 of the DPDP Rules, 2025 — which operationalizes Section 8(5) — provides the practical architecture of what reasonable security safeguards entail. The Act deliberately avoids mandating specific technical controls to allow for proportionate implementation, but when read alongside India's existing IT Act framework and sector-specific overlays from the RBI, SEBI, IRDAI, and NHA, a practical baseline emerges.
That baseline includes encryption of personal data at rest and in transit using current industry standards — AES-256 for databases, object storage, and backups, with HSM-backed key management for sensitive data sets; TLS 1.2 or higher for all data in transit, with mutual TLS for system-to-system communication, and SSL Labs A+ rating for public endpoints. It includes granular, policy-driven access controls with audit trails, regular access reviews, and documented revocation processes. It includes a functioning vulnerability management program — not a point-in-time scan, but a continuous process of identifying, prioritizing, and remediating weaknesses across the systems that hold personal data. And it includes a tested incident detection and breach response capability that can reliably meet the 72-hour notification requirement to the Data Protection Board.
Critically, Rule 6 also imposes specific obligations around Data Processors — the vendors, cloud platforms, SaaS tools, and third-party services that process personal data on behalf of a Data Fiduciary. The organization remains accountable for the security practices of every processor in its chain, which means third-party security governance isn't a nice-to-have element of DPDP compliance. It's a statutory requirement that needs to be embedded in every vendor contract and validated through assessment.
The Gap Between Policy and Demonstrability
This is where most compliance programs hit their first real obstacle. The standard compliance approach produces documentation: a data processing register, an updated privacy policy, vendor data processing agreements. These are necessary. They are not sufficient.
The key word in Section 8(5) is "reasonable" — and in a regulatory context, reasonable is not assessed against what an organization has documented. It's assessed against what an organization can demonstrate. The question the Data Protection Board will ask, in an investigation or audit, is not "do you have a security policy" but "can you show that your security safeguards were implemented, functioning, and effective." Those are materially different standards.
Demonstrating reasonable security safeguards requires evidence that most organizations haven't assembled in a compliance-ready form. Penetration test reports that identify and document vulnerabilities, with remediation evidence showing those vulnerabilities were closed. Access control documentation showing that personal data can only be reached by those with a legitimate need, with audit logs confirming this in practice. Encryption implementation evidence showing that data at rest and in transit is protected at the required standard. Incident response runbooks that have been exercised end-to-end, with documented outcomes.
This is infrastructure and security work. It cannot be delegated to the legal team, and it cannot be produced by a privacy consultant working from a policy template. It requires the participation of security engineers, cloud architects, infrastructure teams, and in many cases, external specialists who can identify what the internal team is too close to see.
Why the Security Layer Gets Left Until Last
The pattern in compliance programs is predictable and understandable: organizations start with what's visible and documentable — policy updates, privacy notices, consent mechanisms — because those feel like clear, completable tasks. The security evidence layer is harder to scope, harder to execute, and often reveals problems that can't be closed quickly. So it gets deferred.
The cost of that deferral is worth making concrete. Unpatched vulnerabilities, insecure configurations, and exposed applications don't become compliant by virtue of having a privacy policy on the same website. A personal data breach that results from a known, unpatched vulnerability — one that a penetration test would have found and a remediation program would have closed — is not a breach that can be defended as a failure of the attacker's sophistication. It's a failure of reasonable security safeguards, and the Act's penalty schedule treats it accordingly.
The 72-hour breach notification requirement compounds this. An organization that discovers a breach and then spends the first 48 hours establishing what happened, what data was affected, and how far the attacker got is an organization whose incident detection capability wasn't fit for purpose. Meeting the notification timeline requires having detection tooling, logging, and incident response capability in place before an incident — not assembled under pressure during one.
The Infrastructure Dimension: Where Data Lives Matters
* The DPDP framework introduces an infrastructure dimension that many organizations haven't factored into their compliance architecture: the question of where personal data physically lives and who controls the infrastructure running it.
* The government has been explicit that DPDP compliance is not optional — the Financial Express reported in August 2025 that the government has asked all ministries and states to ensure compliance within prescribed timelines. The framing of compliance as mandatory for "government bodies, businesses, and organisations handling personal data" — across government, enterprises, institutions, and every sector of industry — signals an expectation that is broader than the legal framework alone.
* Cross-border data transfer under the DPDPA is currently permitted by default, except to countries specifically restricted by the Central Government. That default permissiveness may not persist, and organizations building their infrastructure architecture now need to build with potential localization requirements in mind — not because they're currently mandated, but because retrofitting data residency constraints into an existing cloud architecture is considerably more expensive than building for that possibility from the start.
* For organizations running personal data on foreign cloud infrastructure with no clear contractual or technical visibility into where that data resides, the compliance question isn't hypothetical. The Data Fiduciary remains accountable for every processor in its chain. If the processor can't demonstrate adequate security safeguards, the accountability sits with the Fiduciary, not the vendor.
The CERT-In Connection
DPDP compliance doesn't exist in isolation from India's existing cybersecurity regulatory framework. CERT-In's 2022 Cyber Security Directions — which require organisations to report cybersecurity incidents within six hours and maintain logs for 180 days — operate alongside the DPDP Act rather than being superseded by it. An organisation subject to both (which is most organisations of any meaningful scale) has a six-hour CERT-In notification window and a 72-hour DPDP breach notification window running simultaneously after an incident.
Meeting both requires the same underlying capability: detection tooling that surfaces an incident quickly, logging that provides the information required for a notification, and an incident response workflow that can produce a notification to two different regulators in different formats within different timeframes. Organizations that treat CERT-In compliance and DPDP compliance as separate programs frequently end up building overlapping infrastructure. Integrated compliance architecture — built around the common technical requirements — is more efficient and more defensible.
What Genuinely Audit-Ready Looks Like -
An organization that is genuinely audit-ready for DPDP's Section 8(5) requirements can produce — without significant additional preparation — the following:
* Current penetration test reports covering the systems that hold personal data, with documented evidence that high-risk findings have been remediated. Not "we have a pen test scheduled" — completed reports with closed findings.
* Access control documentation showing who can access what personal data, why, under what governance process, and with audit logs that confirm the controls are working as documented.
* Encryption evidence showing that personal data at rest and in transit is protected at a standard consistent with the data's sensitivity and the current state of practice.
* A tested incident response workflow — not a written runbook, but a workflow that has been exercised under realistic conditions, with documented outcomes showing that the 72-hour notification timeline is achievable.
* Third-party processor assessments confirming that the security practices of every significant vendor in the data processing chain meet a standard consistent with the Fiduciary's own obligations.
Where the Legal Program Ends and the Real Work Begins?
The reasonable security safeguards obligation under Section 8(5) is precisely where our services connect most directly to DPDP compliance. Penetration testing against the systems holding personal data, cloud security assessments that identify misconfigurations and access control weaknesses, vulnerability assessment programs that produce the ongoing evidence a compliance program needs — these aren't separate from DPDP compliance. They are DPDP compliance, for the half of the Act that legal counsel alone cannot satisfy.
If your DPDP program is advancing on the legal and consent side but hasn't yet built the security evidence layer, the gap is real and it carries the Act's highest penalty exposure. Reach out to Illume to scope what the security safeguards component of your DPDP readiness actually requires — and to start building the evidence that demonstrates it before May 2027 makes the question urgent.
