The India CISO Incident Response Playbook

PROACTIVE DATA SYSTEMS  ·  AN OPERATIONAL PLAYBOOK FOR INDIAN ENTERPRISES

CERT-In and DPDP Ready in the First Six Hours

Four dimensions, five time targets, the 20 reportable categories, a severity matrix and a 90-day roadmap for passing the six-hour test

Your CERT-In clock starts the moment you know, not when you are ready. The cost of a data breach in India averaged INR 220 million in 2025, up 13% from INR 195 million in 2024 (IBM Cost of a Data Breach Report, India segment). A late or badly documented CERT-In report adds regulatory exposure on top of that, and it is the part of a breach most within your control.
Most organisations we meet have an incident response policy. The question this playbook asks is different: has anyone tested whether the first six hours work at 11 pm on a Friday, with the CISO out of reach? In Proactive's readiness assessments, the most common answer is no. The policy exists on paper and has never been timed.
Proactive Data Systems, a Cisco Preferred Partner across all five architectures with 35 years in Indian enterprise infrastructure, has run six-hour readiness assessments and simulated drills for over 500 Indian enterprises since 2025. The time targets in this playbook are the targets we set and test in those engagements.

Four structural failure patterns recur across BFSI, IT/ITeS and manufacturing. They are the predictable result of investing in detection technology without investing equally in the process and governance that turns a detection signal into a defensible regulatory response.

These are process and governance failures, not technology failures, and all four are fixable before an incident.

Who Is This Playbook For?

CISOs, CROs, legal counsel and security operations leaders accountable for CERT-In and DPDP compliance. It is an operational document, meant to be used on the day of an incident, not only read in preparation for one. Three reader groups will use it differently.

What Is the Six-Hour Assurance Model?

The Six-Hour Assurance Model is the readiness model Proactive uses to score CERT-In reporting capability on four dimensions: Signal Integrity, Classification Discipline, Escalation Certainty and Evidence Defensibility. The dimensions themselves are standard incident response (detect, classify, escalate, evidence). What the model adds is India-specific time targets for each one and a direct mapping to the CERT-In categories. Failure in any one dimension is enough to miss the window.

The Six-Hour Assurance Model: four dimensions of incident response readiness.

Dimension 1: Signal Integrity

Can you generate accurate, correlated detection signals across identity, endpoint, network and cloud within minutes of an anomalous event? Everything else depends on this. Without it, the other three dimensions do not matter because the incident is not yet known.
The usual failure is not a lack of tools. It is fragmented telemetry: identity logs in one place, endpoint logs in another, MFA records not centralised, cloud control plane events in a system separate from the on-premises SIEM. When retrieval takes several manual steps across several systems, the 30 to 60 minute validation target is out of reach.

Dimension 2: Classification Discipline

Can your team apply a severity matrix aligned to CERT-In triggers without debate or delay? Classification is separate from investigation. It answers one question: does this incident meet the threshold for regulatory reporting? That question must be answerable within 30 to 60 minutes of validation. If classification needs legal debate or senior approval every time, the process depends on who is available, not on agreed criteria. The matrix removes that dependency by fixing the criteria in advance.

Dimension 3: Escalation Certainty

Is reporting ownership predefined, rehearsed and workable across shifts? At any hour, on any day, there must be one named individual whose job is to authorise and submit the CERT-In notification. The failure mode is structural ambiguity: the SOC assumes Legal will decide, Legal assumes the CISO will escalate, the CISO is not on call. Ownership must be documented, tested and on a rotation.

Dimension 4: Evidence Defensibility

Can your team produce a complete, auditable incident timeline with preserved artefacts under regulatory scrutiny? This is the standard a CERT-In inspection or a later legal challenge will apply. The requirement is not a perfect investigation. It is disciplined documentation: every detection event, log retrieval, classification decision, escalation and submission carries a timestamp and an accountable name, with chain of custody kept from the moment of detection.
If you already run ISO 27035 or NIST CSF 2.0, the model sits on top as a CERT-In compliance layer: it maps to the ISO Detect and Assess phases and to the NIST Respond function, and adds the time targets and ownership rules neither prescribes.

The First Six Hours Operating Model

The operating model turns the four dimensions into a sequence of time-bound steps from detection to submission. Each step has a named owner and a time target. If either is missing, that is a gap to fix.

First six hours operational flow: detection to reporting, with regulatory decision gates.

What are the time targets for each step?

Five targets, from 30 to 60 minutes for detection-to-validation through to CERT-In submission within six hours of detection. These are the targets Proactive sets and tests in readiness engagements. They are not legal thresholds and not measured industry medians; they are what we have found an organisation needs to hit, with margin, to submit inside six hours under normal conditions. High-risk sectors and complex log environments should aim for the lower end of each range.

If you cannot measure these five intervals today, your six-hour readiness is assumed, not confirmed.

How does six hours compare with other jurisdictions?

It is the shortest mandatory cyber incident reporting window among major jurisdictions. The EU gives 72 hours, Singapore three days, the US four business days for listed companies, and Australia 30 days to assess.

Windows are as published by each regulator at the time of writing and are triggered by different events (awareness, assessment, materiality). Confirm the current text before relying on any of them.

What Do CERT-In and DPDP Actually Require You to Do?

CERT-In requires an initial report within six hours of detection or awareness, whichever is earlier. DPDP requires breach intimation to the Data Protection Board without delay, a detailed report within 72 hours, and notice to affected individuals without delay. Regulatory text describes obligations; this section turns them into operational actions. CISOs and Legal should review it together.

CERT-In: the six-hour reporting obligation

Under the CERT-In Directions of 28 April 2022, issued under Section 70B(6) of the IT Act, 2000, the six-hour clock creates four operational requirements, plus two standing ones.

• Detect and validate incidents continuously, across all material systems.
• Decide reportability quickly, on pre-agreed criteria, not in-flight deliberation.
• Submit an initial report with available facts. Completeness is not required at T+6 hours. Submission is.
• Preserve a defensible evidence trail from the moment of detection.
• Standing: keep logs of all ICT systems for a rolling 180 days, within Indian jurisdiction.
• Standing: synchronise system clocks to the NIC or NPL NTP servers, or servers traceable to them.

Which incidents must be reported to CERT-In?

Twenty categories, listed in Annexure I of the Directions. Any incident in one of them is reportable within six hours, whatever its scale. Map your severity matrix to this list, not to a generic one.

Wording condensed from Annexure I. Use the official text in your severity matrix.

How do you submit a CERT-In report?

By email to [email protected], by phone on 1800-11-4949 or fax on 1800-11-6969, using the incident reporting format published on cert-in.org.in. Pre-fill the format with your organisation details and keep it, with the minimum viable dataset fields blank, in the reporting officer's offline kit. Nobody should be opening the format for the first time at 2 am.

Four grey areas to interpret before an incident

BFSI organisations answer to several regulators at once. CERT-In's obligation sits alongside RBI's cybersecurity framework for banks and NBFCs, SEBI's cyber resilience framework for market participants and IRDAI's guidelines for insurers. They share principles but differ in timelines and formats. 

• Align the CERT-In severity matrix with RBI, SEBI and IRDAI obligations. One incident may need several notifications, in sequence or in parallel.

• Bring fraud operations into the first-six-hour workflow. Fraud indicators often precede or accompany identity-based breaches.

• Aim for the lower end of every detection benchmark. Board scrutiny in BFSI is immediate.

• Keep regulator-ready evidence in separate log repositories that containment actions cannot modify.

Manufacturing and Industrial

IT/OT convergence creates scope validation problems that can consume the whole six-hour window. A detection architecture that covers only IT is incomplete for this sector.

• Include OT log visibility in the readiness scope. If OT telemetry cannot be queried within 30 minutes, that is a Signal Integrity gap.

• Validate IT/OT segmentation as a live control, with penetration tests of the boundary in every readiness exercise.

• Give vendor access governance an immediate revocation capability. Third-party access is a primary breach vector in manufacturing.

• Protect plant-level configuration backups as incident evidence. They are frequently overwritten during recovery.

Information Technology and IT-Enabled Services

For IT/ITeS, contractual exposure to clients can match or exceed regulatory exposure. The operating model has to satisfy CERT-In and client notification timelines at the same time.

• Centralise cloud control plane and SaaS logs into the primary SIEM. Cloud is the main attack surface for this sector.

• Map client contractual notification obligations before an incident. Some enterprise contracts require notice within two to four hours.

• Treat remote workforce identity risk as a continuous, elevated-priority signal.

• Write client communication templates in advance. Drafting them during an incident costs time you do not have.

What Will the Board Ask After an Incident?

Three questions: was reporting timely, was decision-making documented, and was evidence preserved? Regulators and auditors examine the same three. Incident response maturity is a governance issue, not only a technical one, and DPDP's governance provisions put directors within reach of scrutiny when documentation is weak.

Governance Safeguards

• Board-approved incident reporting owner, documented and reviewed annually.

• Quarterly readiness score presented to the Audit or Risk Committee, using the four Assurance Model dimensions.

• Tabletop exercises minuted and available for regulator review.

• Post-incident review reports shared with the Audit Committee within 30 days of closure.

• Legal counsel briefed on CERT-In and DPDP before an incident, not during one.

Where Does Your Organisation Sit? The Readiness Scorecard

In Proactive's readiness assessments, the most common starting point is Level 2: processes exist on paper and have not been timed. Score each of the four dimensions quarterly on the scale below. The IR Lead scores, in consultation with Legal, and presents to the CISO and Audit Committee. The gap between Level 2 and Level 3 is a process and rehearsal investment, not a technology one.

If you cannot place your organisation at Level 3 on all four dimensions, your six-hour window is at risk. The roadmap below is built to get you there in 90 days.

How Do You Reach Level 3 in 90 Days?

In three phases: fix ownership, the matrix and the log inventory in days 1 to 30; build runbooks, the DPDP checklist and the first tabletop in days 31 to 60; run a full timed simulation and present it to the Audit Committee in days 61 to 90. Each activity has an owner and maps to an Assurance Model dimension. Organisations with an existing IR programme should use this as a gap assessment, not a from-scratch build.

What should you be able to prove at day 90?

Six outcomes. Use them as acceptance criteria.

• Detection-to-escalation under two hours, tested under simulation.

• Named reporting officer with documented deputy and out-of-hours rotation.

• Critical log retrieval under 30 minutes, verified by rehearsal.

• Severity matrix applied without Legal debate in a tabletop exercise.

• CERT-In initial submission template pre-populated and approved.

• Simulation results documented and presented to the Audit Committee.

If you cannot show these six, readiness is still assumed, not confirmed.

Which Controls Shorten the First Six Hours?

Six control domains, led by centralised identity logging and unified XDR telemetry, because every dominant breach vector targets identity first. Controls must compress response time and reduce ambiguity. The table maps each to its operational benefit, its reporting benefit and the dimension it strengthens. Use it to prioritise technology investment where readiness is the objective.

Architecture decides whether six-hour readiness is achievable or permanently aspirational. An organisation with fragmented log infrastructure cannot meet the Signal Integrity benchmarks however much process it adds. Both are needed. Verizon's 2025 DBIR identifies credential abuse, token replay in cloud control planes, privileged account exploitation and vendor trust abuse as the dominant breach vectors globally, and finds around 68% of breaches involve the human element. Verizon does not publish an India breakdown. A detection architecture without identity telemetry as a primary signal will keep missing the early stages of these attacks.

Six Hours, Engineered

Six hours is a test of four things at once: the quality of your detection signals, the clarity of your decision criteria, the discipline of your governance and the strength of your evidence chain. Most Indian enterprises have invested in detection technology. Fewer have tested whether process and governance can turn a signal into a defensible CERT-In submission inside the window. Fewer still have measured that under realistic conditions and shown the board the result. Readiness is a demonstrated, time-stamped, board-reviewed capability, not a posture.

Proactive Data Systems, a Cisco Preferred Partner across all five architectures with 35 years in Indian enterprise infrastructure, helps Indian enterprises engineer the first six hours. We design and deploy identity, access, segmentation and detection architectures on Cisco Duo, Cisco ISE, Cisco Secure Access and Cisco XDR, then test them under realistic incident conditions. Every engagement ends with a scored assessment against the Six-Hour Assurance Model, a quantified gap report, a 90-day remediation plan and a simulated six-hour drill with documented results.

Want to know your level? Ask Proactive for a six-hour readiness assessment. We will score your four dimensions, run the drill, and give you the evidence for your next Audit Committee meeting.

(Request a Six-Hour Readiness Assessment)

Sources

• CERT-In Directions under Section 70B(6) of the IT Act, 2000, dated 28 April 2022, including Annexure I, and associated FAQs. Ministry of Electronics and Information Technology, Government of India.

• Information Technology Act, 2000, Section 70B(7).

• GDPR Article 33; Singapore PDPA Part 6A; US SEC Form 8-K Item 1.05; Australia Privacy Act 1988 Part IIIC.

• Digital Personal Data Protection Act, 2023, and Digital Personal Data Protection Rules, 2025 (notified 13 November 2025). Government of India.

• IBM Security. Cost of a Data Breach Report 2024 and 2025, India segment data.

• Verizon. Data Breach Investigations Report 2025.

• ISO/IEC 27035-1:2023, Information security incident management.

• NIST Cybersecurity Framework 2.0.

Figures are drawn from published research and vary by source, methodology and year. Verizon does not publish an India breakdown; global figures are cited as directional context. Verify current data before citing externally.