Incident Response Planning for Regulated Entities in India

Every regulated entity has an incident response plan. It sits in a policy document, usually last updated during the previous audit cycle, and describes a theoretical process for handling security incidents. The problem is that most plans are designed to pass an audit, not to handle an incident. When a real security event occurs, the plan fails for predictable reasons. The escalation contacts are outdated. The classification criteria are too vague to apply to the actual incident. The communication templates do not cover the specific regulatory reporting requirements. The technical team has never practiced the containment procedures. The legal team has not reviewed the breach notification language. The regulatory reporting timelines are documented but the process for gathering the required information within those timelines has never been tested. The organizations that respond effectively to incidents are those that treat the incident response plan as an operational procedure that is practiced, tested, and updated regularly - not a compliance document that is reviewed annually. If your team's first encounter with the incident response plan is during an actual incident, your response will be improvised regardless of what the plan says.

Indian regulated entities face incident response obligations from multiple regulators, each with specific requirements. RBI requires banks, NBFCs, and PSOs to report cyber incidents to RBI and CERT-In within specified timelines. The reporting includes the nature of the incident, systems affected, estimated impact, containment actions, and remediation plans. For RBI-regulated entities, the cyber crisis management plan is a specific requirement separate from the general incident response plan. SEBI's CSCRF requires regulated entities to report cyber incidents to SEBI and CERT-In within 6 hours of detection. The reporting framework includes a prescribed format and specific categories of reportable incidents. SEBI also expects post-incident analysis and lessons learned reports within 14 days. DPDP Act requires notification to the Data Protection Board and affected data principals when a personal data breach occurs. The notification must include the nature of the breach, the categories of personal data affected, and the measures the data principal can take to protect themselves. The timeline for notification is prescribed in the DPDP Rules. PCI DSS Requirement 12.10 mandates an incident response plan that addresses specific elements - roles and responsibilities, communication and contact strategies, media handling, legal analysis, containment and mitigation, business recovery, and lessons learned. PCI forensic investigation may be required for breaches involving cardholder data. Building a single incident response framework that satisfies all these requirements simultaneously requires careful mapping and integration.

Start with incident classification. Define categories that map across all applicable regulations - data breach involving personal data, data breach involving cardholder data, system compromise, denial of service, malware infection, insider threat, and third-party breach. For each category, document which regulatory notifications are required, the reporting timeline for each regulator, the information required in each notification, and the internal escalation path. Build a notification decision matrix. When an incident is detected, the response team needs to quickly determine which notifications are required. A compromise of a payment system that also processes personal data triggers PCI DSS forensic investigation requirements, RBI incident reporting, CERT-In reporting, and DPDP breach notification - four separate notification processes with different timelines and different information requirements. Pre-draft your notification templates. For each regulator, prepare notification templates that include the required fields with placeholders for incident-specific information. During an actual incident, your team should be filling in the specifics, not figuring out the reporting format. Have legal review these templates in advance. Establish clear roles and responsibilities. Designate an incident commander who owns the overall response. Assign specific individuals to technical containment, forensic evidence preservation, regulatory notification, internal communication, external communication, and legal coordination. Each role should have a primary and backup individual, with contact information verified quarterly.

Hour 0-1: Detection and initial triage. When a potential incident is detected - through SOC monitoring, user report, third-party notification, or automated alert - the on-call security analyst conducts initial triage. Is this a true positive? What systems are affected? Is the incident ongoing? What is the initial severity classification? Notify the incident commander. Hour 1-4: Containment and assessment. The incident commander activates the response team based on the incident classification. Technical team implements immediate containment - isolating affected systems, blocking malicious IPs, disabling compromised accounts - while preserving forensic evidence. Parallel track: begin gathering information required for regulatory notifications. For SEBI-regulated entities, the 6-hour notification clock is running. Hour 4-6: Regulatory notification preparation. Based on the incident assessment, determine which regulatory notifications are required. Complete the notification templates with available information - you do not need to wait for a complete picture before notifying. Initial notifications are expected to be preliminary, with follow-up reports providing additional detail. Submit notifications to the relevant regulators within their prescribed timelines. Hour 6-24: Deep investigation and remediation. With containment in place and initial notifications submitted, the focus shifts to understanding the full scope of the incident, identifying the root cause, assessing the extent of data exposure or system compromise, and planning remediation. Continue updating regulators as new information becomes available. Engage external forensic investigators if the incident involves cardholder data or if the scope exceeds your internal team's capability.

The single most effective way to improve your incident response capability is to practice it. Tabletop exercises simulate security incidents and walk your response team through the process without the pressure of a real event. Conduct these exercises quarterly, rotating through different incident scenarios. Design scenarios that test specific response capabilities. A ransomware scenario tests your backup and recovery procedures, communication with law enforcement, and decision-making around ransom payment. A data breach scenario tests your forensic investigation capability, regulatory notification process, and customer communication. A third-party breach scenario tests your vendor notification procedures and supply chain risk assessment. A DDoS scenario tests your business continuity procedures and customer communication. Each tabletop exercise should involve the full response team - technical, legal, compliance, communications, and executive leadership. The exercise should follow the timeline pressure of a real incident, including simulated regulatory notification deadlines. After each exercise, conduct a structured debrief identifying what worked, what failed, and what needs to change in the incident response plan. Document the findings and track the implementation of improvements. When a regulator asks whether your incident response plan has been tested, the exercise records, debrief reports, and improvement tracking provide concrete evidence. This is significantly more valuable than simply stating that the plan was reviewed annually.

A: CERT-In requires reporting of cyber security incidents within 6 hours of the entity becoming aware of the incident. This applies to all entities, not just regulated financial institutions.

A: Not always, but your payment brand or acquirer may require a PFI investigation for breaches involving cardholder data. Engage your QSA and acquiring bank immediately when a potential cardholder data breach is identified.

A: Quarterly tabletop exercises with different scenarios. Additionally, conduct at least one full simulation exercise annually that tests your complete response capability including regulatory notification.