Introduction
A data breach is no longer a question of 'if' but 'when.' In India's regulatory environment, the consequences of a breach are compounded by the dual notification requirements of the DPDPA and CERT-In directions. The DPDPA mandates notification to the Data Protection Board of India (DPBI) and affected Data Principals without undue delay, while CERT-In requires incident reporting within six hours of becoming aware of the breach. Failure to notify under the DPDPA carries penalties of up to Rs 150 crore, and non-compliance with CERT-In can result in penalties under the IT Act. Organisations without a well-rehearsed breach response plan will find it nearly impossible to meet both requirements simultaneously while managing the technical, legal, and reputational fallout of a breach. This guide provides a practical, step-by-step playbook for building a breach response plan that addresses both frameworks.
Understanding the Dual Notification Regime
India is unique in having two parallel mandatory breach notification frameworks that organisations must satisfy. The CERT-In directions require reporting of cybersecurity incidents - including data breaches - within six hours of awareness, focusing on the technical details of the incident: systems affected, attack vectors, scope of compromise, and remediation actions. The DPDPA requires notification to the DPBI and each affected Data Principal without undue delay, focusing on the personal data angle: what personal data was compromised, how many individuals are affected, what steps the organisation is taking to mitigate harm, and what the individuals should do to protect themselves. These two notifications serve different purposes and have different audiences, formats, and content requirements. A breach response plan must address both in parallel, with dedicated workstreams for technical incident reporting and data protection notification.
- CERT-In notification: within 6 hours, focused on technical incident details, reported to CERT-In
- DPDPA DPBI notification: without undue delay, focused on personal data impact, reported to DPBI
- DPDPA Data Principal notification: without undue delay, informing affected individuals of the breach
- Sectoral notifications: RBI, SEBI, or IRDAI may require additional breach reporting for regulated entities
Phase 1: Preparation
The most critical phase of breach response happens before any breach occurs. Preparation involves establishing the team, defining roles, creating playbooks, and deploying the tools needed for rapid detection and response. An Incident Response Team (IRT) should be formally established with representation from IT security, legal, compliance, communications, and executive leadership. Each member's role during a breach should be clearly defined - who leads the technical investigation, who handles regulatory notifications, who manages communications with affected individuals, and who authorises expenditures for containment and remediation. The IRT should have access to pre-drafted notification templates for CERT-In, DPBI, and affected individuals, pre-negotiated retainers with external forensic investigators and legal counsel, and secure communication channels that remain operational even if primary systems are compromised.
- Establish a cross-functional Incident Response Team with defined roles and escalation paths
- Create and maintain pre-drafted notification templates for CERT-In and DPBI submissions
- Negotiate retainer agreements with external forensic investigators and breach response legal counsel
- Deploy endpoint detection and response (EDR) and SIEM tools for continuous monitoring
- Establish secure out-of-band communication channels for the IRT
- Maintain an updated data inventory mapping personal data to systems, processors, and Data Principals
Phase 2: Detection and Assessment
The 6-hour CERT-In clock starts the moment the organisation becomes aware of the incident, making rapid detection and initial assessment critical. Detection can come from multiple sources - automated security tools (SIEM alerts, EDR detections, anomaly detection), internal reports (employees noticing unusual activity), external notifications (customers, partners, or law enforcement informing of compromised data), or threat intelligence feeds. Once a potential breach is detected, the IRT must conduct a rapid initial assessment within the first hour to determine the nature and scope of the incident, whether personal data is involved, an initial estimate of the systems and data affected, and whether the incident falls within CERT-In's 20 reportable categories. This initial assessment does not need to be complete or conclusive - it needs to provide enough information to trigger the notification process and guide the containment response. Waiting for a full forensic investigation before reporting is not an option under the 6-hour timeline.
Phase 3: Containment and CERT-In Notification
Within the first six hours, two parallel workstreams must execute simultaneously: technical containment and CERT-In notification. The containment workstream focuses on stopping the breach from spreading - isolating affected systems, revoking compromised credentials, blocking malicious IP addresses, and preserving forensic evidence. Critically, containment actions must not destroy evidence that will be needed for the investigation. The CERT-In notification workstream must prepare and submit the incident report using the prescribed format, including the nature of the incident, systems affected, estimated scope, and immediate actions taken. The initial CERT-In report can be based on preliminary findings and updated as more information becomes available. CERT-In expects timely updates as the investigation progresses. It is essential that the notification team and containment team coordinate closely - the notification must accurately reflect the containment actions being taken, and containment decisions should consider the reporting implications.
Phase 4: Investigation and DPDPA Notification
Once containment is achieved and the CERT-In notification is submitted, the focus shifts to a thorough investigation and DPDPA notification. The investigation must determine precisely what personal data was compromised, identify all affected Data Principals, establish the root cause and attack vector, assess the potential harm to affected individuals, and document the timeline of events from initial compromise to detection and containment. Based on the investigation findings, the DPDPA notification to the DPBI must be prepared, including the nature and scope of the breach, the categories and approximate number of Data Principals affected, the likely consequences of the breach, the measures taken to address the breach, and the contact details of the Data Protection Officer. Simultaneously, a notification to affected Data Principals must be prepared in clear, plain language that explains what happened, what data was compromised, what the organisation is doing about it, and what steps the individual should take to protect themselves.
- Conduct thorough forensic investigation to determine the full scope of personal data compromised
- Identify all affected Data Principals through data mapping and breach scope analysis
- Prepare DPBI notification with prescribed details including scope, impact, and remediation measures
- Draft Data Principal notifications in clear, plain language with actionable guidance
- For regulated entities, prepare additional notifications to RBI, SEBI, or IRDAI as applicable
- Document all decisions, actions, and timelines for regulatory and audit purposes
Phase 5: Recovery and Remediation
After containment and notification, the organisation must focus on restoring normal operations and implementing measures to prevent recurrence. Recovery involves restoring affected systems from clean backups, rebuilding compromised infrastructure, resetting credentials across the organisation, and validating that the attacker's access has been completely eliminated. Remediation goes further - addressing the root cause of the breach through security control enhancements, patching exploited vulnerabilities, improving monitoring capabilities, and updating security policies and procedures. A post-incident review should be conducted within 30 days of the breach, involving all IRT members and executive leadership, to identify lessons learned and drive improvements to the breach response plan.
Testing Your Breach Response Plan
A breach response plan that has never been tested is a plan that will fail when needed. Organisations should conduct regular exercises to validate and improve their plans.
- Tabletop exercises quarterly - walk through breach scenarios with the IRT to test decision-making and coordination
- Technical simulation exercises annually - simulate actual breach scenarios in a controlled environment to test detection and containment capabilities
- Notification timeline drills - run timed exercises to validate that the CERT-In 6-hour reporting deadline can be met end-to-end
- Communication drills - test the Data Principal notification process including template generation, channel delivery, and helpdesk readiness
- Third-party coordination tests - validate that external forensic investigators and legal counsel can be engaged within the required timelines
How Kraver.ai Automates Breach Response
Kraver.ai's breach response module is purpose-built for India's dual notification regime. Our AI-powered detection engine continuously monitors your infrastructure and automatically classifies incidents against both CERT-In reportable categories and DPDPA breach criteria. When a breach is detected, Kraver.ai triggers parallel notification workflows - generating CERT-In incident reports within minutes and preparing DPBI notifications with automatically populated personal data impact assessments drawn from our real-time data inventory. Affected Data Principals are identified instantly through our data mapping engine, and personalised notification communications are generated in the Data Principal's preferred language. The entire detection-to-notification timeline is documented in an immutable audit trail, providing the evidence regulators expect. Kraver.ai transforms breach response from a chaotic, manual scramble into an orchestrated, automated process that meets every regulatory deadline.