CERT-In security advisories and the DPDP Rules: how technical patching meets the 72-hour breach clock

Every week, the Indian Computer Emergency Response Team publishes high-severity advisories flagging remote code execution flaws, authentication bypasses and cryptographic weaknesses in enterprise software, web servers, digital signature tools and cloud platforms used across India. When an unpatched vulnerability crosses from a technical weakness into unauthorized access or disclosure of customer or employee records, the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 turn an engineering ticket into a regulated personal data breach.

How a software advisory connects to reasonable security safeguards

Under the data protection law, every Data Fiduciary must protect personal data in its possession or under its control by taking reasonable security safeguards to prevent a personal data breach. The Rules spell out the baseline categories of those safeguards, including encryption, obfuscation or masking, access control over computer resources, visibility logs that detect unauthorized access, backup recovery measures and contractual security clauses with every Data Processor.

While the data protection rules do not name specific software versions or patch cycles, ignoring a public high-severity vulnerability advisory on an internet-facing portal or database server directly undermines your ability to show that reasonable security safeguards were maintained. In a post-incident inquiry by the Data Protection Board of India, one of the first factual questions will be whether the exploited flaw had already been flagged in a public security advisory and whether access controls and monitoring logs were active.

Why the law has no minimum size threshold for a personal data breach

A common misconception among engineering and operations teams is that only massive data dumps sold on dark-web forums count as reportable breaches. The statutory definition is much broader: any unauthorized processing of personal data, or any accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data that compromises its confidentiality, integrity or availability is a personal data breach.

When a breach occurs—whether through an unpatched web runtime, a misconfigured cloud storage bucket, a compromised vendor API token or ransomware locking a hospital database—the law sets no minimum headcount before reporting is triggered. From 13 May 2027, every confirmed personal data breach requires notifying both the Data Protection Board of India and each affected Data Principal without delay.

What must go into the 72-hour Board report and individual notice

Once your team becomes aware that a vulnerability or attack has resulted in a personal data breach, two parallel communication tracks start running:

• Immediate notice to each affected person: You must send every affected Data Principal a concise, plain-language notice without delay through their user account or registered contact method. It must state a description of the breach (including its nature, extent and the timing of occurrence), the consequences relevant to that person that are likely to arise, the risk-mitigation measures you have implemented and are implementing, the safety measures the person may take to protect their interests, and the business contact information of the person who can respond to queries.
• Immediate intimation and 72-hour report to the Board: You must inform the Board without delay with a description of the breach, including its nature, extent, timing, location and likely impact. Within 72 hours of becoming aware of the breach—or within a longer period if the Board allows it on a written request—you must submit updated details, the broad facts of the events and circumstances that led to the breach, the measures implemented or proposed to mitigate risk, any findings regarding the person who caused the breach, the remedial measures taken to prevent recurrence, and a report regarding the intimations given to affected individuals.

Why one-year visibility logs decide whether you can answer in 72 hours

When an advisory warns that a web server package, VPN appliance or database driver has an active exploit, security teams must answer a hard question fast: did anyone exploit this flaw on our servers before we patched it? Without structured application, authentication and database query logs retained for at least one year, an organisation cannot prove which records were touched—and may be forced to assume that every record on the server was exposed.

The Rules require maintaining appropriate logs for visibility and retaining logs and traffic data for a minimum of one year. Keeping centralised, tamper-evident logs allows your team to scope an incident accurately within hours rather than weeks.

Our view: six habits to link vulnerability patching with DPDP readiness

In our view, engineering leads, security officers and compliance teams should build six habits before 13 May 2027: