Updated At Mar 15, 2026
The 72-Hour Breach Clock: Incident Response Plan for DPDP
A business-style piece for decision-makers that explains the 72-hour breach clock— incident response plan for dpdp and turns policy requirements into an operating plan for leadership teams.
Key takeaways
- Treat the DPDP 72-hour breach deadline as an enterprise operating constraint, not just a legal formality.
- Define precisely when your organisation is considered “aware” of a personal data breach and document that decision path.
- Align DPDP reporting with CERT-In’s 6-hour requirement and any sectoral timelines through a single multi-regulator playbook.
- Pre-breach investments in logging, forensics, contracts and governance dramatically increase the odds of a defensible 72-hour report.
- Use a 0–24–72 hour operating plan, tested through regular tabletop exercises, as a board-level KPI for breach readiness.
Why the DPDP 72-hour breach clock is now a board-level issue
- Regulatory risk is now time-bound: the 72-hour clock converts a legal requirement into a measurable operational SLA for the enterprise.
- Multiple clocks apply at once: DPDP, CERT-In, sectoral regulators, global regimes and cyber insurers all expect rapid, coordinated response.
- Reputational impact is amplified: poor handling in the first 72 hours often drives media narrative, Data Principal trust and future enforcement posture.
- Personal accountability is rising: directors and CXOs are expected to show credible oversight of cyber risk, including incident response capabilities.
| Dimension | Pre-DPDP mindset | DPDP-aligned mindset |
|---|---|---|
| Ownership | IT/security handles incidents; board is informed post-fact. | Board sets risk appetite and response expectations; executives own a time-bound playbook. |
| Time sensitivity | Focus on resolving the incident; notifications often ad hoc or delayed. | Incident handling and notifications are parallel tracks governed by the 72-hour breach clock and other timelines. |
| Success criteria | Systems restored; limited internal disruption; minimal outward communication. | Containment plus defensible, timely reporting to DPBI, CERT-In, sectoral regulators, Data Principals and other stakeholders as required. |
Infographic showing how the 72-hour DPDP breach clock links to board oversight, executive decision-making and operational teams.
What DPDP actually requires in a personal data breach
| Obligation | Who is notified? | Indicative timeline under DPDP | Key information expected (initial vs detailed) |
|---|---|---|---|
| Initial breach intimation | Data Protection Board of India (DPBI) | Without undue delay after becoming aware of a personal data breach. | High-level description of what happened, affected systems, initial assessment of impact and immediate containment actions; more detail to follow. |
| Detailed 72-hour breach report | DPBI (and potentially other regulators where relevant) | Within 72 hours of awareness of the breach, subject to specific rule triggers and formats. | Nature and cause of breach, categories and approximate number of Data Principals and records affected, types of personal data involved, steps taken to mitigate harm, and steps proposed to prevent recurrence, as per applicable formats. |
| Notification to affected Data Principals (if directed or required based on risk of harm) | Impacted Data Principals via appropriate communication channels (e.g., email, SMS, in-app, website notice). | As early as reasonably practicable once impact and affected cohorts are understood and any directions from DPBI are received. | Plain-language summary of the breach, what data was affected, potential risks, steps taken by the organisation, and what Data Principals can do to protect themselves (where relevant). |
- Not every security alert is a reportable personal data breach, but every suspected breach should be triaged against DPDP thresholds and documented.
- Third-party and processor incidents that compromise your Data Principals’ personal data are your problem under DPDP, even if the root cause sits outside your infrastructure.
- Where multiple regulators are involved, the DPDP breach report should be consistent with—but not necessarily identical to—reports sent to other authorities.
Defining awareness and when the 72-hour clock starts
-
Differentiate raw signals from suspected incidentsDefine what counts as a “signal” (e.g., IDS alerts, EDR flags, anomalous access) versus a “suspected personal data breach”. Only after a structured triage should an event be escalated as suspected DPDP-relevant.
- Create severity levels (e.g., Sev 1–4) with clear examples and required response times.
- Ensure your SOC, IT operations and managed security partners understand these definitions.
-
Define a formal trigger for “awareness” under DPDPAdopt a governance rule such as: the organisation is considered aware when an authorised incident commander (e.g., CISO or delegate) concludes, based on available evidence, that there is a probable personal data breach affecting Data Principals.
- Record the exact date and time of this decision in the incident log; this is the start of your 72-hour DPDP clock.
-
Document the decision trail and assumptionsFor each major incident, maintain a short note explaining why the event was classified as a DPDP-reportable breach (or why it was not), who took the decision and what information they relied on at that moment in time.
- This documentation will be critical if your timelines or materiality decisions are later questioned by regulators or auditors.
-
Align awareness definitions across DPDP, CERT-In and sectoral regimesUse one consolidated definition of “noticing” or “awareness” for internal purposes, then map it carefully to each regulator’s wording in your playbook so teams do not run parallel, conflicting clocks for the same incident.
- Avoid tying awareness to board meetings or lengthy committees; the trigger should be an operational decision-maker, not a quarterly forum.
- Calibrate awareness definitions with external counsel in advance so incident commanders are not paralysed during live events.
- Train on real examples (e.g., credential stuffing, lost laptop, cloud misconfiguration) so teams understand when the DPDP clock would start in practice.
Roles, accountability and escalation paths
| Role | Key responsibilities in a DPDP breach | Critical decisions they own/approve |
|---|---|---|
| Board / Risk Committee | Set breach risk appetite, approve incident response framework, receive updates on material breaches and readiness metrics. | Approve high-impact public disclosure strategies and structural remediation where required (e.g., major investments, product changes). |
| CEO / MD | Owns the organisation-wide response, ensures cross-functional coordination (security, legal, business, communications). | Authorises significant trade-offs (e.g., service disruption for containment), approves regulator-facing posture and key external messages in critical incidents. |
| CISO / Head of Cybersecurity (Incident Commander) | Leads technical response, coordinates detection, containment and forensics, maintains incident log and evidence pack. | Declares suspected and confirmed DPDP-reportable breaches (consistent with governance rules), triggers the 72-hour clock internally and recommends regulatory notifications with legal and DPO. |
| DPO / Privacy Officer (where appointed) | Ensures DPDP principles are applied, validates whether incident involves personal data and Data Principals, reviews breach notifications for accuracy and fairness. | Confirms materiality under DPDP, co-approves content of DPBI filings and Data Principal communications with legal and CISO. |
| General Counsel / Legal Head | Advises on regulatory obligations across DPDP, CERT-In, sectoral regulators and foreign regimes; coordinates with external counsel and insurers where needed. | Approves legal content of regulator notifications, decides on privilege strategy and coordinates responses to regulator queries and investigations. |
- Name an alternate incident commander for nights, weekends and holidays so the 72-hour clock is covered 24x7.
- Specify who is authorised to speak to regulators, the media, customers, partners and employees to avoid mixed messages.
- Embed escalation paths into tooling (e.g., incident management systems, on-call rotas, service desk workflows) rather than relying on manual email chains.
A 0–24–72 hour breach response playbook
-
0–6 hours from awareness: stabilise and start the clocksOnce an incident is classified as a probable personal data breach, move quickly to contain damage and trigger relevant reporting timelines.
- Activate the incident response team with clear incident commander and scribe.
- Stabilise systems: isolate affected assets, revoke compromised credentials, secure backups and preserve volatile evidence where possible.
- Confirm whether the incident triggers CERT-In’s 6-hour reporting requirement and, if so, initiate that process in parallel with DPDP planning.
- Capture a first-cut view: what happened, which environments are affected, what categories of personal data may be involved, and whether critical services are impacted.
-
6–24 hours: deepen investigation and prepare initial intimation to DPBIThe first day should convert preliminary facts into a coherent narrative that can support prompt intimation to DPBI and other stakeholders as needed.
- Engage internal or external forensics with a clear scope and legal oversight to preserve evidence and privilege where appropriate.
- Refine impact assessment: number and types of Data Principals affected, sensitivity of data, geographies and business lines involved, and potential harms (financial, identity theft, discrimination, etc.).
- Draft the initial intimation to DPBI with current facts, acknowledging that more detail will follow in the 72-hour report and subsequent updates if required.
- Notify cyber insurers and key external partners (incident response vendors, external counsel) as per policy requirements, so their conditions do not delay notifications later.
-
24–48 hours: build the 72-hour report and Data Principal communication planWith investigation progressing, focus on assembling the information expected in the detailed report and designing Data Principal communications where indicated.
- Consolidate technical, legal and business inputs into a single incident dossier to serve as the basis for regulatory reporting across all regimes.
- Prepare a draft of the 72-hour DPDP report, mapping your facts to the information fields required under the Rules or prescribed formats, leaving placeholders where investigations are ongoing.
- Design Data Principal notifications in plain language, aligned with your brand and legal posture, ensuring they are consistent with what is reported to DPBI and other regulators.
-
48–72 hours: finalise filings and approvals, prepare for follow-throughThe final window is about quality control, coordinated filings and preparing your organisation to execute on commitments made in notifications.
- Secure internal approvals for the DPBI report and other regulator filings from the CISO, DPO, legal and relevant executives, within pre-agreed turnaround times.
- Submit the detailed DPDP breach report within the 72-hour window and diarise any commitments to provide follow-up information as investigations progress.
- Finalise the timing and channels for Data Principal notifications and external communications (website notice, FAQs, media holding statements), ensuring customer support teams are briefed.
- Schedule a management and, where appropriate, board debrief on lessons learned, remediation plans and any required strategic changes.
| Time window (from awareness) | Primary owner(s) | Non-negotiable outcomes by end of window |
|---|---|---|
| 0–6 hours | Incident commander, SOC / IT operations, CISO delegate | Incident declared and logged; awareness time recorded; initial containment actions executed; preliminary scoping of impact and regulatory exposure completed. |
| 6–24 hours | CISO, DPO, Legal, Forensics lead | Initial intimation to DPBI prepared and, where appropriate, submitted; CERT-In reporting initiated if triggered; insurers and key partners notified as required by contract or policy conditions. |
| 24–48 hours | Incident commander, DPO, Legal, Communications, Business owners | Draft 72-hour DPDP report completed; Data Principal communication strategy agreed in principle; cross-regulator consistency check completed for all draft filings and statements. |
| 48–72 hours | CEO/MD, CISO, DPO, Legal, Communications | DPDP 72-hour report filed; other regulator notifications aligned and submitted as required; execution of Data Principal and stakeholder communications underway; board/committee brief scheduled where material. |
Diagram-style infographic mapping activities and owners across the 0–6, 6–24, 24–48 and 48–72 hour windows after breach awareness.
Coordinating DPDP with CERT-In and sectoral timelines
| Regime | When the clock typically starts internally | Indicative first reporting deadline | Operational considerations |
|---|---|---|---|
| DPDP (DPBI breach report) | When a probable personal data breach affecting Data Principals is confirmed by the incident commander under your governance rules. | Prompt intimation without undue delay, followed by a detailed report within 72 hours of awareness, as per Rules and formats. | Can follow, but must remain consistent with, any earlier CERT-In or sectoral filings for the same incident. |
| CERT-In directions (cyber incidents) | When your organisation notices a listed cyber incident or is informed of it by any party (internal or external). | Within 6 hours of noticing the incident or being informed, where the incident falls within specified categories. | Often triggers before DPDP reporting; your playbook should assume a near-immediate CERT-In decision once a serious incident is suspected. |
| Sectoral regulators (e.g., RBI, SEBI, IRDAI where applicable) | As defined by the relevant regulator, often linked to discovery of disruption, fraud risk or customer impact in regulated entities. | Varies by sector; may require near-real-time or same-day reporting for serious incidents, with follow-up reports later. | Your regulatory inventory should map which entities in your group are subject to which timelines and who coordinates each filing. |
- Maintain a single “regulatory response” workstream in each incident, led by legal, that tracks all filings across DPDP, CERT-In, sectoral and foreign regimes.
- Use one master incident narrative and data set to feed all forms, rather than allowing teams to craft separate stories for different regulators.
- Keep a calendar of post-incident obligations (follow-up reports, remediation attestations, audit responses) and assign owners up front.
Systems, data and evidence you need before day zero
- Logging and monitoring: centralised logs from critical applications, databases, identity providers, endpoints and network controls, with reliable time synchronisation and retention aligned to legal and forensic needs.
- Data inventory and mapping: up-to-date register of systems processing personal data, data flows (including cross-border), and categories of Data Principals and data held in each system.
- Identity and access records: auditable history of privileged access, API keys, third-party integrations and significant configuration changes for key environments.
- Incident documentation templates: standard forms for incident logs, regulatory reports, Data Principal communications and board updates, pre-reviewed by legal and leadership.
- Vendor readiness: contractual rights to timely incident notification, cooperation, access to logs and forensics, and alignment on who leads regulator and customer communications in a shared incident.
| What you must answer within 72 hours | Required capability or artefact | Typical owner(s) |
|---|---|---|
| What happened, when and how was it detected? | Event logs, monitoring alerts, incident timeline and detection runbooks tied to specific systems and controls. | CISO, SOC, IT operations |
| Which Data Principals and what personal data were affected, approximately how many records? | Data inventory, system-of-record identification, ability to query impacted tables or objects, mapping to Data Principal cohorts. | Data owners, DPO/privacy, application owners, data engineering teams |
| What steps were taken to mitigate harm and prevent recurrence? | Documented incident response procedures, change management records and remediation tracking tools integrated with ITSM platforms. | CISO, IT operations, risk management, product/engineering leads |
Infographic outlining the components of a DPDP breach “evidence pack” and how they support the 72-hour report and follow-up actions.
Testing, metrics and board reporting
- Mean Time to Detect (MTTD): median time from occurrence of a qualifying incident to internal detection by monitoring or staff escalation.
- Mean Time to Confirm (MTTC): median time from detection to formal declaration of a DPDP-relevant personal data breach (start of the 72-hour clock).
- Mean Time to Notify (MTTN): median time from awareness to filing of the 72-hour DPDP report, measured over real incidents and simulations.
- Exercise coverage: number of major business units and critical vendors covered by at least one tabletop or live simulation per year.
- Issue closure rate: percentage of high-priority findings from drills and incidents that are remediated within agreed timelines.
| Metric / indicator | Current performance (rolling 12 months or last 3 exercises) | Board-approved target / tolerance |
|---|---|---|
| Average time to file 72-hour DPDP report in simulations (from awareness) | E.g., 30–40 hours in last three multi-regulator tabletop exercises (illustrative only). | Target buffer of at least 24 hours before the 72-hour deadline, to allow for unforeseen issues in real incidents. |
| Percentage of significant incidents where awareness time was logged and approved by an authorised incident commander | E.g., 90% of qualifying incidents in the last year recorded this data point (illustrative only). | 100% for Sev 1 and Sev 2 incidents; lower tolerance for minor events by design. |
Key takeaways
- Agree a small set of breach readiness KPIs, tie them to executive objectives and track them over time rather than treating each incident as a one-off crisis.
- Run cross-functional tabletop exercises at least annually, with realistic DPDP, CERT-In and sectoral reporting timelines built into the scenario design.
- Use board dashboards to track both speed (e.g., time to notify) and quality (e.g., completeness of evidence, remediation follow-through) of breach handling.
Implementation roadmap for Indian enterprises
-
0–3 months: establish governance and understand your baselineFocus on clarity of scope, ownership and current capability before investing heavily in tools or external services.
- Confirm whether you are, or are likely to become, a Significant Data Fiduciary and what that implies for expectations on breach handling maturity.
- Map all entities in your group that process personal data relating to Data Principals in India and identify applicable regulators (DPBI, CERT-In, sectoral, foreign).
- Perform a gap assessment of existing incident response, logging, forensics and reporting capabilities against DPDP-informed requirements.
-
3–6 months: design the operating model and playbooksTranslate policy and gaps into a practical operating model, with clear roles, processes and artefacts that can be tested in the real world.
- Define escalation paths, awareness triggers and incident severity levels; update policies and on-call procedures accordingly.
- Author 0–24–72 hour playbooks for at least your top 3–5 realistic breach scenarios (e.g., ransomware, credential compromise, cloud misconfiguration, insider data exfiltration).
- Develop regulator reporting templates, Data Principal notification drafts and board update formats, pre-reviewed by legal and communications teams.
-
6–12 months: harden tooling, train teams and test at scaleWith design in place, invest in the people, processes and technologies that will make 72-hour reporting achievable under pressure.
- Upgrade logging, monitoring and forensic tooling where necessary, prioritising systems that process sensitive or large volumes of personal data.
- Run cross-functional tabletop exercises including external counsel, insurers and key vendors, using your real playbooks and templates under timed conditions.
- Refine KPIs, dashboards and board reporting format based on lessons from exercises and any real incidents or near-misses during the period.
- For SMEs: focus on clarity (who does what), minimal but reliable tooling, and tested relationships with at least one trusted incident-response partner and legal advisor.
- For larger or regulated entities: invest in automation (e.g., SOAR workflows for escalations), deeper scenario playbooks, and integrated reporting across DPDP, CERT-In and sector regulators.
Common questions from leadership teams
FAQs
No. DPDP focuses on personal data breaches that impact Data Principals, not every malware detection or unsuccessful attack. However, you should define and document thresholds for what is DPDP-reportable based on factors such as whether personal data was accessed, altered, lost or made unavailable, the sensitivity of that data and the risk of harm to Data Principals.
Treat the first intimation as a concise, good-faith account of what you know at the time: a short description of the incident, affected systems or environments, the type of personal data likely involved, an initial sense of scale (even if approximate), immediate containment steps taken and a statement that a more detailed report will follow within the 72-hour window or as directed.
From a DPDP standpoint, you remain responsible for protecting Data Principals’ personal data even when processing is outsourced. Your contracts should require prompt notification, cooperation and forensic support from processors. In a breach, coordinate closely with the vendor but avoid assuming that their notifications to regulators or affected parties cover your obligations; your own reporting duties, particularly to DPBI and Data Principals, still apply.
DPDP’s timelines and thresholds are distinct from GDPR and other foreign regimes, even if some elements appear similar. For cross-border groups, it is usually best to maintain a single global incident record and master timeline, then map that record to each jurisdiction’s specific triggers, deadlines and required content. Where multiple regimes are engaged for the same incident, aim for consistent facts and carefully reconciled differences in legal characterisation or level of detail.
If you are likely to miss or have already missed the 72-hour window, consult counsel immediately. In general, it is better to notify late with a transparent explanation than not to notify at all. Your incident records—showing when you became aware, what you did to investigate and why delays occurred—will be important in demonstrating good-faith compliance efforts if the timeline is later scrutinised.
Common mistakes leadership teams make around the 72-hour clock
- Treating DPDP breach reporting as a legal or compliance task alone, without defining operational owners and timelines across IT, security, business and communications.
- Waiting for complete forensic certainty before notifying regulators, rather than providing an initial good-faith intimation followed by more detailed updates as facts emerge.
- Assuming that CERT-In or sectoral reporting covers DPDP obligations (or vice versa), leading to gaps or inconsistencies in notifications for the same incident.
- Over-relying on manual coordination (emails, spreadsheets, chat threads) rather than embedding breach workflows and escalation paths into incident management and ticketing systems.
- Underestimating the time needed for internal approvals and alignment with external counsel, especially when group structures, joint ventures or strategic partners are involved.
Summary checklist for operating within the 72-hour breach clock
Key takeaways
- Codify when the DPDP 72-hour clock starts, who can start it and how that decision is recorded.
- Design a 0–24–72 hour operating plan that integrates DPDP, CERT-In and sectoral timelines with clear owners and artefacts.
- Invest early in logging, forensics, data mapping and vendor readiness so the facts needed for breach reporting are actually available within 72 hours.
- Measure and regularly test breach readiness through KPIs and cross-functional tabletop exercises, with results reported to the board.
- Before incidents: approve governance documents (policies, RACI, awareness definition), maintain an updated regulatory inventory, and ensure contracts with processors and key vendors include robust incident cooperation clauses.
- During incidents (0–24 hours): immediately appoint an incident commander, log awareness time, stabilise systems, begin CERT-In assessment, and draft initial DPBI intimation using pre-approved templates.
- During incidents (24–72 hours): refine incident facts, complete the DPDP 72-hour report, align filings across regulators, and finalise Data Principal notifications and board/management updates.
- After incidents: complete root cause and lessons-learned reviews, update controls and playbooks, track remediation actions, and refresh training and exercises based on what you learned.
Sources
- DPDP Act and Rules compliance roadmap - KPMG in India
- DPDP Rules: An Attempt to Bring Order to the Chaos - CMS IndusLaw
- The Digital Personal Data Protection Act, 2023: Comprehensive Framework, Latest Developments, and Compliance Roadmap - The Legal 500 / Maheshwari & Co.
- FAQs On Cyber Security Directions of 28.04.2022 - TaxGuru (reproducing CERT-In FAQs)
- Government notifies DPDP Rules to empower citizens and protect privacy - Press Information Bureau, Government of India