Written by

Sumeshwar Pandey

View Profile

The 72-Hour Breach Clock: Incident Response Plan for DPDP

How Indian leadership teams can turn DPDP’s breach notification rules and CERT-In’s six-hour clock into a reliable incident response system before May 2027.
Key takeaways
  • Under the DPDP Act and DPDP Rules 2025, every personal-data breach must be notified to the Data Protection Board and affected individuals, with a detailed report due within 72 hours of becoming aware of the breach.
  • CERT-In’s requirement to report specified cyber incidents within six hours runs in parallel with DPDP, so a single event can trigger multiple regulatory clocks and sectoral notifications.
  • A DPDP-ready 72-hour incident response model depends on clear decision rights, fast incident triage, strong logging and data mapping, and contractually enforceable obligations on processors and cloud providers.
  • The cost of missing the breach clock includes potential penalties, intrusive regulatory directions, contractual disputes with enterprise customers, and lasting reputational damage.
  • Boards can test DPDP breach readiness through structured tabletop exercises, metrics on detection and triage times, internal audits, and alignment of global incident response processes with Indian requirements.

When a breach wakes up your leadership team

It is 2:17 a.m. on a Sunday when your phone rings. Your security head is on the line. A production database that holds customer contact details and identity documents has shown signs of abnormal access. The initial view is that an administrator account was compromised and large volumes of records may have been queried. At this point, nobody can yet say with confidence whether data was actually exfiltrated, how many data principals are affected, or whether the incident is still live.
From that moment, however, regulatory time starts to compress. For many Indian organisations, the same incident will trigger at least two hard clocks: CERT-In’s requirement to report specified cyber incidents within six hours of detection, and the DPDP regime’s requirement to first intimate the Data Protection Board and then file a detailed personal-data breach report within 72 hours of becoming aware of the breach. Sectoral regulators such as RBI, SEBI, and IRDAI may add their own timelines, often measured in hours rather than days.
What looks like “three days” on paper is, in practice, a much tighter window once you factor in night-time, weekends, hand-offs between internal teams and external vendors, and the time legal and communications teams need to review public statements. The board will be judged not only on whether the right technical fixes were applied, but also on whether the organisation recognised a personal-data breach in time, escalated it to the right decision makers, and met notification obligations across regulators and data principals.
The real question for leadership is therefore not whether a particular clause in the DPDP Rules applies, but whether your operating model can turn a vague 2 a.m. alert into a defensible regulatory filing and credible communication to affected individuals inside 72 hours, repeatedly and under stress.

The regulatory clocks that matter: DPDP, DPDP Rules 2025, and CERT-In

The Digital Personal Data Protection Act, 2023 establishes the core obligation: when a “personal data breach” occurs, the data fiduciary must intimate the Data Protection Board of India and each affected data principal in the manner to be prescribed. The Act applies broadly to digital personal data about individuals in India, regardless of where the processing takes place, and does not limit breach notification to large enterprises or specific sectors.[1]
According to public drafts and legal analyses, the DPDP Rules 2025 create a layered breach-notification framework. Once a data fiduciary becomes aware of a personal-data breach, it must send an initial intimation to the Data Protection Board without undue delay, followed by a more detailed report within 72 hours of that point of awareness. In parallel, affected data principals must be informed without undue delay. On current indications, the breach obligations under DPDP and the DPDP Rules will become fully enforceable around 13 May 2027, after an implementation window of roughly 18 months.[2][5]
In parallel sits the CERT-In Directions issued under the Information Technology Act. These directions require service providers, intermediaries, data centres, body corporates, and government entities to report specified categories of cyber incidents to CERT-In within six hours of noticing them. The triggers are defined in technical terms, such as targeted scanning, unauthorised access, website defacement, data breaches, and ransomware attacks. The purpose is national cyber incident coordination; whether personal data is involved is not the primary test, but many qualifying incidents will, in practice, also be DPDP-relevant.[6]
Sectoral regulators overlay additional timing constraints. For example, financial-sector entities supervised by RBI or SEBI may be required to report certain cyber incidents within tight windows, often measured in hours rather than days. A single breach can therefore create a stack of obligations: six hours for CERT-In, sectoral reporting soon after, DPDP initial intimation as soon as you are aware that personal data of individuals in India is involved, and a 72-hour deadline for a comprehensive DPDP report. These clocks do not pause for weekends or holidays, so any operating model that assumes “three business days” is likely to fall short.
Key breach and incident-reporting regimes that typically apply when a serious incident involves personal data about individuals in India.
Regime Who is covered Trigger for reporting Indicative timelines Primary regulatory focus
DPDP Act, 2023 Data fiduciaries processing digital personal data about individuals in India, regardless of processing location Occurrence of a personal-data breach affecting data principals linked to India Notification to Data Protection Board and affected data principals in the prescribed manner and timelines under the Rules Protection of data principals’ rights and accountability of data fiduciaries for personal-data handling
DPDP Rules 2025 (breach-notification provisions) Data fiduciaries and, through contracts, their processors handling in-scope personal data Becoming aware of a personal-data breach involving in-scope data sets Initial intimation to the Data Protection Board and affected data principals without undue delay; detailed report to the Board within 72 hours of awareness, once fully operational Operationalisation of DPDP breach duties through prescribed formats, timelines, and required content
CERT-In Directions under the IT Act Service providers, intermediaries, data centres, body corporates, and government entities operating in India Detection of specified cyber incidents (for example, unauthorised access, website defacement, data breaches, ransomware) Report to CERT-In within six hours of noticing the qualifying incident National cyber incident visibility, technical coordination, and response support
Sectoral regulators (for example, RBI, SEBI, IRDAI, health regulators) Regulated entities in the respective sectors, sometimes including critical service providers and participants in market infrastructure Security incidents, outages, frauds, or breaches that meet sector-specific criteria, many of which will overlap with DPDP and CERT-In triggers Often hours to a day for initial reporting, with follow-on reports as investigations progress Financial stability, consumer protection, sector resilience, and supervisory oversight of cyber risk

What DPDP actually demands in a personal-data breach

The DPDP framework is deliberately broad. A personal-data breach is any breach of security that leads to unauthorised access, disclosure, alteration, loss of availability, or processing of personal data. Crucially, the Act does not set an explicit harm threshold for notification. The obligation is framed so that every personal-data breach is in principle notifiable to the Data Protection Board and to affected data principals, regardless of whether the organisation believes the risk of harm is low. That makes the volume of notifiable events a governance question rather than a purely legal one.[3]
Practically, you can think of DPDP breach notification in three layers. The first layer is an initial intimation to the Data Protection Board as soon as practicable after becoming aware of a personal-data breach. This early message is not expected to contain full forensic detail, but it should give the Board a clear basic picture: what kind of systems are affected, what categories of personal data are involved, how many data principals may be impacted at a high level, what immediate containment steps have been taken, and who the Board can contact for further information.
The second layer is communication to affected data principals without undue delay. This is a direct obligation under the Act and is not limited to large incidents. The notice will typically need to explain, in plain language, what happened, when it was discovered, what categories of personal data about the individual are implicated, what the likely implications are, and what steps the individual can take to protect themselves, such as changing passwords or monitoring financial accounts. It should also provide a clear point of contact for queries and complaints, which may include the data protection officer or another authorised representative.
The third layer is a detailed report to the Data Protection Board within 72 hours of becoming aware of the personal-data breach. The DPDP Rules 2025 are expected to set out the required content, but law-firm and consulting analyses point to a familiar pattern: a description of the nature and cause of the breach, the categories and approximate volume of personal data and data principals affected, whether children or other sensitive groups were involved, the technical and organisational measures in place at the time, the likely consequences of the breach, the remedial steps taken or planned, and the status of notifications to data principals and other regulators. Where some information is not yet available within 72 hours, the expectation is that the data fiduciary will file what it knows and commit to further updates rather than waiting indefinitely for a perfect picture.[4]
In-scope incidents therefore include obvious cases such as exfiltration of customer databases, ransomware attacks that encrypt personal data, or unauthorised access to employee HR records. They also include accidental disclosures, such as sending personal data to the wrong recipient, misconfiguring access controls on cloud storage, or leaving physical documents containing digitised personal data in unsecured locations. Borderline situations will occur, for example, when there is a strong attempted attack but logs suggest that personal data was not actually accessed, or when lost devices are strongly encrypted and there is no sign that encryption keys were compromised. In these cases, the Act does not provide a clear exemption, so the organisation’s risk appetite, legal advice, and desire to maintain credibility with the Board will drive decisions on whether to notify.

Designing a 72-hour incident response operating model

Meeting a 72-hour breach reporting deadline is less about reading the statute and more about how your organisation is wired to take decisions under pressure. The first design choice is governance. You need a clearly designated incident leader for DPDP-related events, with the authority to mobilise teams, take systems offline where necessary, and approve notifications. In many organisations this will be the CISO or head of information security working hand-in-hand with the data protection officer and general counsel, but the exact role matters less than the clarity of decision rights. The board, usually through its risk or audit committee, should formally endorse who can take which decisions and under what escalation thresholds so that approvals do not stall when minutes matter.
The next layer is process. Most organisations already have information security incident procedures; these now need to be explicitly mapped to DPDP and CERT-In obligations. Every significant alert should move through a fast triage path that answers a short set of structured questions: does this incident touch systems that hold personal data about individuals in India, are we acting as a data fiduciary in relation to those data sets, is there evidence or a credible risk of unauthorised access, disclosure, or loss of availability of that personal data, and does the incident fall into one of CERT-In’s reportable categories. Once those questions are answered, the incident can be categorised as a DPDP personal-data breach, a non-DPDP cyber incident, both, or neither, with predefined actions tied to each category.
Technology and data discipline are the enablers. Without a reliable inventory of where personal data is stored, which applications and vendors process it, and what logging is in place around those systems, the 72-hour clock quickly becomes unmanageable. At a minimum, leadership should expect that high-value systems containing personal data are tagged, monitored, and integrated into central logging so that investigators can quickly reconstruct what happened. Monitoring does not have to be extravagant, but it does need to answer practical questions fast: which user accounts accessed the data, from where, for how long, what queries were run, whether data was exported, and what security controls were in force at the time.
People, coverage, and external partners complete the operating model. Many breaches are discovered outside normal business hours, so relying purely on a nine-to-five response team is a conscious risk decision rather than a neutral default. Some organisations choose to build a 24/7 internal on-call model; others contract managed security service providers or incident-response firms to provide overnight detection and first-level containment. Regardless of the model, your legal, privacy, security, communications, and business leaders need to know how they will work together in a “war room”, who speaks to regulators and customers, how decisions are recorded, and how conflicts between local DPDP obligations and global group processes will be resolved.

Inside the 72 hours: from first alert to final report

In practice, it helps to think about the first 72 hours after becoming aware of a likely personal-data breach in three distinct phases.
Each phase has a clear leadership focus: confirm what is happening, deepen understanding, and convert facts into regulator-ready filings and communications.
  1. 0–6 hours: confirm the incident and preserve options
    The first six hours after a serious alert are about confirmation, containment, and preserving options. The security team verifies that an incident is genuine, isolates affected systems where needed, begins preserving logs and evidence, and maps the incident to systems known to contain personal data. As soon as there is a credible indication that personal data about individuals in India may be involved, the incident should be escalated to the designated incident leader, the data protection officer, legal, and senior management. In parallel, the CERT-In clock may already be running; if the incident falls into one of CERT-In’s defined categories, a short initial report based on the best available facts should be prepared and submitted rather than waiting for full confirmation.[6]
  2. 6–24 hours: move from triage to structured investigation
    Between six and twenty-four hours, the organisation moves from triage to structured investigation. Technical teams refine their understanding of which data sets and data principals are affected, estimate volumes, and check whether children or other sensitive categories of individuals are involved. They reconstruct a basic timeline of events and validate whether encryption or other controls might have limited exposure. Legal and privacy teams assess whether the incident meets the DPDP definition of a personal-data breach and prepare an initial intimation to the Data Protection Board if that has not already been sent. Communications and customer teams start drafting data principal notices and internal talking points, even if the drafts will be refined later. Key third parties, such as cloud providers and critical processors, are pressed for timely logs and incident details under the breach clauses in their contracts.
  3. 24–72 hours: finalise the DPDP report and notifications
    From twenty-four to seventy-two hours, the focus shifts to formalising what you know and meeting the DPDP detailed-report deadline. Investigation continues, but leadership can no longer wait for every forensic question to be answered before acting. The incident leader, together with legal and the data protection officer, consolidates the known facts into the 72-hour report: nature and cause of the breach as currently understood, categories and approximate numbers of affected data principals and records, systems and locations involved, steps taken to contain the incident, the state of recovery, likely consequences for data principals, and the plan for further remediation. Notices to data principals move from draft to final, with a clear explanation, practical guidance, and contact points. Throughout this period, the organisation should keep a detailed log of decisions, including why certain notifications were sent or not sent and why any gaps in information remain. Regulators are generally more concerned with unexplained silence than with a well-documented report that acknowledges uncertainties and promises updates.

Strategic trade-offs and the cost of missing the breach clock

Executives rarely have the luxury of perfect information in a live incident, so your breach playbook needs to make certain trade-offs explicit in advance. One of the most important is reporting posture. A conservative posture treats most borderline events as notifiable, accepting higher volumes of regulator and data principal notifications in exchange for lower risk of under-reporting. A restrictive posture sets higher internal thresholds, perhaps focusing on larger volumes or more sensitive data, which may reduce noise but raises the stakes if an incident later turns out to be more serious than first thought. Neither posture is automatically right; what matters is that the choice is conscious, documented, and aligned with the board’s risk appetite.
Ownership structure is another strategic choice. A strongly centralised model concentrates breach triage and regulatory engagement in a small group of specialists, which can bring consistency and make it easier to build expertise in DPDP and CERT-In requirements. The potential downside is dependence on a handful of individuals and the risk of bottlenecks if that core team is unavailable when the clock starts. A more distributed model pushes initial triage into business units or regional teams, which can increase speed and local context but must be supported by training, standardised playbooks, and clear escalation rules to avoid fragmented decisions and inconsistent responses to similar incidents.
Resourcing decisions also carry trade-offs. Investing in 24/7 monitoring, mature logging, and retained external incident-response support increases operating cost, but it is often the only realistic way to ensure that a breach detected on a Sunday night does not miss a Monday-morning regulatory deadline. Conversely, relying on office-hours capabilities or ad-hoc access to external specialists may reduce steady-state costs but can leave the organisation scrambling when a high-impact event hits at an awkward time. Executives should treat these as explicit investment choices rather than assuming that current arrangements will scale to meet DPDP-era expectations.
The cost of missing the breach clock is more than a one-off fine. The DPDP Act empowers the Data Protection Board to impose significant monetary penalties for a range of contraventions, including failure to take reasonable security safeguards and failure to notify breaches as required. In serious cases, the Board can also issue directions that impact day-to-day business, such as ordering audits, mandating changes to processing activities, or imposing conditions on how personal data may be handled in future. Beyond formal enforcement, delayed or incomplete notifications can trigger disputes with enterprise customers whose contracts often contain strict breach clauses, complicate insurance claims, and damage trust with regulators, investors, and the public. By the time an incident becomes a headline or a boardroom crisis, it is usually too late to fix the structural weaknesses that caused the delay.[1]
Selected breach-response design choices and how different options play out under DPDP timelines.
Decision area Option Upside Downside
Reporting posture Conservative (notify most borderline cases) Lower risk of under-reporting; signals transparency to regulators and data principals; simpler frontline decision rules in a crisis. Higher notification volumes; more cost and operational effort; potential for “alert fatigue” among customers and regulators if poorly executed.
Reporting posture Restrictive (higher internal thresholds) Fewer notifications; reduced short-term disruption for customers and operations; more focus on serious incidents. Greater downside if an incident later proves more severe; higher evidentiary burden if challenged by the Data Protection Board after a non-notification decision.
Incident ownership model Strongly centralised breach-response team Consistent interpretations of DPDP and CERT-In obligations; deep expertise in a small team; easier to maintain regulator relationships and standard templates. High dependence on a few people; potential bottlenecks and single points of failure during peak incident periods or holidays.
Incident ownership model Distributed triage in business units or regions Faster local response; better context on affected processes and customers; potentially more resilient across time zones and shifts. Requires strong training, common playbooks, and clear escalation criteria to avoid inconsistent decisions and regulatory messaging.
Resourcing and coverage 24/7 monitoring, mature logging, and retained external IR support Higher confidence that incidents detected at awkward times still meet CERT-In and DPDP timelines; more credible with regulators and large enterprise customers. Higher ongoing cost; requires active vendor management and periodic testing to ensure promised capabilities are real in practice.
Resourcing and coverage Office-hours response with limited external support Lower steady-state expense; simpler operating model in smaller organisations with modest breach risk profiles. Higher probability of missing tight regulatory timelines for incidents discovered overnight, on weekends, or during holidays; greater reliance on luck and individual heroics.

Executive checklist for DPDP breach readiness

From a board or CEO perspective, breach readiness under DPDP is less about memorising rules and more about asking disciplined questions. At the governance level, you should know which committee owns oversight of DPDP risk, who the named incident leader and data protection officer are, how they can be reached around the clock, and what authority they have to notify regulators and data principals without waiting for a full board meeting. You should be able to see, on a single page, how DPDP, CERT-In, and any sectoral breach obligations map onto your existing risk and compliance framework.
On the operating side, there should be a documented incident-response playbook that explicitly references DPDP and CERT-In timelines, sets out the triage questions for classifying an event as a personal-data breach, and describes how the organisation will handle multi-regulator notifications. You should expect to see an up-to-date inventory of systems and vendors that process personal data about individuals in India, including which of them are considered material from a DPDP perspective, and evidence that these systems are logged and monitored to a level that supports a 72-hour investigation. Vendor and cloud contracts should contain concrete obligations to notify your organisation of security incidents promptly, to share logs and other evidence, and to cooperate in regulatory reporting.
Evidence of readiness matters. A mature organisation will be able to show that it has run at least one tabletop exercise simulating a DPDP-relevant breach, including CERT-In and sectoral notifications, and that lessons from that exercise have been tracked to closure. Management information should include simple but telling metrics such as average time to detect, time to classify an incident as a personal-data breach or not, and time to submit regulatory notifications during tests. Internal audit or an independent assurance provider can review the incident-response framework against recognised standards such as ISO 27001 or ISO 27701, not because certification automatically guarantees DPDP compliance, but because it demonstrates that controls are being tested systematically. With DPDP breach obligations expected to be fully operational by May 2027, boards have a finite window in which to move from policy awareness to demonstrable operational capability.[5]
A practical way to frame these questions is to treat them as a checklist for your next risk or audit committee meeting:
  • Confirm which board or management committee formally owns DPDP and broader data-breach risk, and that this mandate is reflected in its charter.
  • Ensure there is a named incident leader and data protection officer with clear 24/7 contact routes and documented authority to notify regulators and data principals within defined parameters.
  • Ask for a one-page map of DPDP, DPDP Rules 2025, CERT-In, and key sectoral breach obligations, showing how each links into your risk, compliance, and incident-response frameworks.
  • Review the incident-response playbook to confirm that it incorporates DPDP and CERT-In timelines, structured triage questions, and a clear approach to multi-regulator notifications.
  • Test whether you have an accurate, current inventory of systems and vendors processing personal data about individuals in India and whether logging and monitoring for those systems can realistically support a 72-hour investigation.
  • Check that contracts with processors and cloud providers include prompt incident-notification obligations, rights to obtain logs and forensic information, and cooperation commitments for regulatory filings.
  • Request evidence of at least one recent tabletop exercise simulating a DPDP-relevant breach, with documented findings and tracked remediation actions.
  • Agree a small set of metrics on time to detect, time to classify, and time to prepare notifications in tests, and require periodic assurance—through internal audit or external review—that these metrics are credible in practice.

Common questions from boards about the 72-hour DPDP rule

A recurring question is when the 72-hour DPDP clock actually starts. In practice, “becoming aware” is more than hearing a rumour that something might be wrong, but less than having a completed forensic report. A sensible working standard is the point at which the designated incident leader or data protection officer has enough credible information to conclude that a security incident has resulted in, or is reasonably likely to have resulted in, a breach of personal data about individuals in India for which your organisation is a data fiduciary. Waiting to start the clock until every detail is confirmed is risky; regulators are likely to look at whether your processes were designed to recognise and escalate a suspected breach promptly, not at whether you managed to delay formal awareness.
Boards also ask how to handle near misses or situations where exposure cannot be conclusively proven. Because DPDP does not contain an explicit harm threshold, the law does not clearly exempt small or low-risk incidents from notification. That said, not every security event will qualify as a personal-data breach. If logs show that an attack was blocked before any access to personal data occurred, or if a lost device is strongly encrypted and there is no evidence that encryption keys were compromised, legal advice may support a decision not to notify, provided the reasoning is carefully documented. In grey areas where there is a realistic possibility that personal data was compromised but uncertainty remains, many organisations lean towards at least notifying the Data Protection Board with a clear explanation of the uncertainty, and may decide on data principal notifications based on volume, sensitivity, and the likelihood of misuse.
Another practical concern is breaches originating at processors or cloud providers. Under DPDP, the duty to notify the Data Protection Board and data principals sits with the data fiduciary, not the processor, even if the processor’s systems were the source of the breach. That means your organisation remains accountable for regulatory timelines, regardless of how quickly the vendor chooses to share information. Contracts with processors should therefore include strict incident-notification timeframes, rights to access relevant logs and reports, and clear cooperation obligations for regulatory filings. During a live incident, leadership should not hesitate to escalate within vendor organisations to get the data needed to classify and report the breach.
Multinational groups often ask how DPDP fits with existing global incident-response processes, particularly those built around the GDPR’s 72-hour rule. The good news is that the operational disciplines are similar: fast detection, structured triage, clear governance, and time-boxed investigation. The differences that matter are the absence of an explicit harm threshold in DPDP, the parallel obligation to report technical incidents to CERT-In, and India-specific nuances around data principals and the Data Protection Board. In practice, many groups will integrate DPDP into their global playbooks by adding India-specific decision points and notification templates, designating an Indian incident lead, and ensuring that global teams understand that an incident involving Indian personal data may trigger additional reporting steps even when EU thresholds are not met.
Finally, boards sometimes wonder whether DPDP requires them to report every trivial mishap, such as a single misdirected email containing limited personal data. The legislation as currently framed does not carve out small incidents, and enforcement practice will only become clear over time. In the meantime, leadership can set policy thresholds that take into account volume, sensitivity, and recipients, while recognising that the regulator may expect a relatively broad view of what is notifiable. Whatever thresholds you adopt should be consistently applied, supported by legal advice, and subject to review as Data Protection Board guidance and early decisions emerge.
FAQs

The 72-hour clock starts when your organisation becomes aware of a personal-data breach, not when the underlying vulnerability first appeared or when the incident is fully investigated. In operational terms, this is the point at which the designated incident leader or data protection officer has enough reliable information to conclude that a security incident has resulted in, or is reasonably likely to have resulted in, unauthorised access, disclosure, or loss of availability of personal data about individuals in India for which your organisation is a data fiduciary. You should avoid practices that artificially delay formal awareness, such as keeping serious alerts at a low level until all details are known. Regulators will look at whether escalation paths were clear, whether logs and monitoring were adequate to recognise a breach, and whether the organisation acted without undue delay once material facts were available.

CERT-In and DPDP obligations operate in parallel and are triggered by slightly different tests. CERT-In’s six-hour requirement applies to specified categories of cyber incidents once they are noticed, regardless of whether personal data is involved, and is aimed at national incident visibility. DPDP’s breach rules apply when personal data about individuals in India is compromised and focus on the rights of data principals and accountability of data fiduciaries. The best way to reconcile the two is to build an integrated incident triage process that, for every serious alert, checks both whether the event fits a CERT-In category and whether it involves personal data in a way that meets the DPDP definition of a personal-data breach. A single cross-functional incident team should own regulatory notifications, using consistent facts and timelines to prepare both CERT-In and DPDP filings rather than allowing separate teams to communicate independently.

In-scope incidents are those where a security breach has led to, or is reasonably likely to have led to, unauthorised access, disclosure, alteration, or loss of availability of personal data about individuals in India, in contexts where your organisation is a data fiduciary. This includes criminal attacks, insider misuse, and accidental disclosures. Ambiguous cases arise when evidence is incomplete, for example, suspicious access logs with no confirmed exfiltration or a lost device that is strongly encrypted. Because the DPDP Act does not include a harm threshold, it does not clearly exclude low-risk incidents from notification, but regulators are also unlikely to expect notification of every inconsequential technical glitch. In practice, organisations typically adopt decision criteria that consider the nature of the data, volume, likelihood of misuse, and the presence of strong technical protections, and they document the reasoning for either notifying or not notifying. Consultation with legal counsel is important where the facts are unclear or the incident could set a precedent for future decisions.

Contracts with processors and cloud providers should be structured so that your organisation can still meet DPDP timelines even when the breach originates in a third party’s environment. At a minimum, they should require the processor to notify you of any security incident affecting your personal data within a short, defined period, such as a few hours from discovery, and to provide sufficient information for you to classify the incident under DPDP. They should grant you rights to obtain relevant logs, forensic reports, and other evidence, and to participate in incident investigations where your data principals are affected. Cooperation clauses for regulatory reporting are critical, including support for answering follow-up questions from the Data Protection Board. Without these contractual levers, you may find yourself accountable for breach notification deadlines without having timely access to the facts you need.

Boards can test and evidence breach-readiness through a combination of exercises, metrics, and independent review. A practical starting point is a tabletop exercise that simulates a realistic breach involving personal data about individuals in India and runs through the full 72-hour period, including CERT-In and any sectoral notifications. The exercise should surface decision bottlenecks, gaps in data inventories, unclear ownership, and friction with global processes. Management should then track remediation actions to closure. On an ongoing basis, the board can ask for concise metrics on average time to detect incidents, time to classify potential personal-data breaches, and time taken to prepare draft regulator notifications during tests. Internal audit or an external assurance provider can review the incident-response framework and controls, focusing on whether they are likely to support DPDP timelines in practice. Taken together, these activities create a body of evidence that the organisation is moving from policy commitments to operational capability ahead of the expected May 2027 enforcement horizon.

Sources
  1. DPDP Act and Rules compliance roadmap - KPMG in India
  2. DPDP Rules: An Attempt to Bring Order to the Chaos - CMS IndusLaw
  3. The Digital Personal Data Protection Act, 2023: Comprehensive Framework, Latest Developments, and Compliance Roadmap - The Legal 500 / Maheshwari & Co.
  4. FAQs On Cyber Security Directions of 28.04.2022 - TaxGuru (reproducing CERT-In FAQs)
  5. Government notifies DPDP Rules to empower citizens and protect privacy - Press Information Bureau, Government of India

Related pages

Updated At May 18, 2026

What Counts as a Reasonable Security Safeguard under DPDP?

A strategic guide for Indian CXOs on how DPDP’s “reasonable security safeguards” duty translates into concrete controls, governance, vendor oversight, and audit-ready evidence.

 Updated At Apr 18, 2026

Log Retention, Deletion, and Audit Trails: Building an Evidence Program

A business-style piece for technical evaluators that explains log retention, deletion, and audit trails— building an evidence program and turns policy

 Updated At May 17, 2026

The 2026 DPDP Audit Checklist: 50 Things Auditors Will Ask For

A procurement-focused guide for Indian business leaders that turns the DPDP Act 2023 and DPDP Rules 2025 into a 50-point 2026 audit checklist, with concrete artefacts, RFQ questions, and vendor scorecard criteria.

 Updated At May 31, 2026

Role-Based Access Meets Purpose-Based Access: Designing Internal Controls

A technical guide for Indian engineering leaders on combining role-based and purpose-based access to enforce DPDP-aligned consent, purpose limitation, and audit-ready logs across apps, data platforms, and third parties.

 Updated At May 23, 2026

Release Management for Privacy Features: Pre-Launch Checklist

DPDP-aware pre-launch checklist and validation strategy for releasing privacy and consent features in Indian digital products, aimed at engineering and technical leaders.

 Updated At Apr 18, 2026

Retail Audit Trail: Evidence across Web, App, Support, and Stores

A business-style article for technical evaluators focused on retail audit trail— evidence across web, app, support, and stores so retail and D2C teams can grow

 Updated At Apr 18, 2026

Consent Logging for Regulated Financial Services

A business-style article for technical evaluators about consent logging for regulated financial services, aimed at regulated finance teams balancing customer

 Updated At Apr 18, 2026

Significant Data Fiduciary (SDF) Status: Checklist for Fast-Growing Companies

A business-style piece for decision-makers that explains significant data fiduciary (sdf) status— checklist for fast-growing companies and turns policy

 Updated At May 26, 2026

DPDP Act penalty: board-level view of fines and 72-hour breach timelines

penalties under dpdpd act 2023 is upto 250 carore and breach notification timeline is 72 hours to the Data Protection Board of India

 Updated At Apr 18, 2026

The DPO Handbook for Indian Companies

A business-style piece for decision-makers that explains the dpo handbook for indian companies and turns policy requirements into an operating plan for