Incident response plan template
with India's clocks built in.
A complete incident response plan you can copy and adapt, with the CERT-In six-hour report, the DPDP 72-hour report, the RBI, SEBI and IRDAI windows, and the log and time-sync duties already written in.
How to use this template
Copy the plan, replace everything in square brackets, delete the lines for regulators that do not supervise you, and get it approved by someone with authority to spend money at 02:00. Then rehearse it. A plan nobody has run is a document, not a capability.
- Names, not job titles. Every role needs a person and a deputy with a phone number
- Register your CERT-In point of contact in the Annexure II format at info@cert-in.org.in before you need it
- Check the clocks. Section 5 lists every clock we could verify; confirm the ones for your sector against the primary text linked below
- Keep it short. The plan is read under pressure. Detail belongs in runbooks the plan points to
The plan
INCIDENT RESPONSE PLAN
[Organisation legal name] | Version [x.y] | Approved by [name, role] on [date]
Next review: [date] | Last rehearsal: [date]
1. PURPOSE AND SCOPE
This plan sets out how [Organisation] detects, reports, contains and recovers from
cyber security incidents and personal data breaches affecting systems and data we
own or operate, including systems run for us by service providers.
2. DEFINITIONS
Incident: any real or suspected adverse event that violates a security policy and
results in unauthorised access, denial of service or disruption, unauthorised use
of a computer resource, or unauthorised change to data.
Personal data breach: any unauthorised processing, or accidental disclosure,
acquisition, sharing, use, alteration, destruction or loss of access to personal
data, that compromises its confidentiality, integrity or availability.
T0: the time anyone in [Organisation] first noticed the incident or was told of it.
Recorded in IST with the time zone. Later confirmation does not move T0.
3. ROLES
Incident lead ........... [name, deputy] Owns the incident from T0 to closure
CERT-In point of contact [name, deputy] Registered with CERT-In; sends the report
Privacy lead ............ [name, deputy] Board intimation and Data Principal notices
Legal counsel ........... [name/firm] Awareness time, content review, privilege
Communications .......... [name] Customer, staff and media messages
Technical lead .......... [name] Containment, forensics, evidence
Executive sponsor ....... [name] Decisions above the incident lead
Out-of-hours rota ....... [link] Someone reachable within 30 minutes, always
4. SEVERITY
SEV1: personal data or regulated data confirmed or likely exposed; critical system
compromised; service down for customers.
SEV2: suspected compromise under investigation; limited service impact.
SEV3: blocked attempt or policy violation with no evidence of impact.
Any incident on the CERT-In Annexure I list is reportable to CERT-In regardless of
severity.
5. REPORTING CLOCKS (all run from T0, including nights and weekends)
T0 + 6h ........ CERT-In report, for any Annexure I incident type
incident@cert-in.org.in | 1800-11-4949 | include logs
T0 + 6h ........ [If regulated] RBI non-bank PSO / SEBI (+ exchange or depository
for brokers and DPs) / IRDAI copy of CERT-In report
T0 + 24h ....... [If SEBI] details on the SEBI Incident Reporting Portal
[If IRDAI] details to IRDAI within 24h of intimation
Without delay .. [From 13 May 2027] each affected Data Principal, and initial
intimation to the Data Protection Board (DPDP Rule 7)
T0 + 72h ....... [From 13 May 2027] detailed report to the Board (Rule 7(2)(b))
T0 + 72h ....... [If GDPR applies] EU supervisory authority, where feasible (Art. 33)
Contractual .... [Customers or controllers we process for: notice period per contract]
6. PHASES
6.1 Detect and log T0. Open the incident record; record T0; page the incident lead.
6.2 Triage (by T0 + 1h). Classify severity and Annexure I type; decide whether
personal data is involved; start the clock sheet.
6.3 Contain. Revoke credentials, isolate systems, preserve evidence before wiping.
6.4 Notify. Send each report on the clock sheet from the one incident record.
6.5 Eradicate and recover. Remove the cause; restore from known-good state; verify.
6.6 Review (within 10 working days). Root cause, what the clocks showed, actions
with owners and dates.
7. EVIDENCE AND LOGS
- ICT logs enabled on all systems and kept for a rolling 180 days in India (CERT-In
direction iv); personal data, traffic data and processing logs for at least one
year from 13 May 2027 (DPDP Rules 6(1)(e) and 8(3)).
- All system clocks synchronised to NIC/NPL NTP or a source that does not deviate
from them; time zone recorded with every timestamp (CERT-In direction i).
- Preserve: affected logs, disk and memory images where needed, access records,
and every notification as sent with its timestamp.
8. COMMUNICATIONS
- Use the approved templates for CERT-In, the Board and Data Principals.
- One incident record is the source for every external statement.
- No public statement before the incident lead and counsel approve it.
9. SERVICE PROVIDERS
- Contracts require providers to tell us of incidents affecting our data within
[x] hours and to cooperate with our reports.
- A provider's report to CERT-In does not replace ours.
10. TESTING AND REVIEW
- Tabletop exercise at least [twice a year], including an out-of-hours scenario.
- Review this plan after every SEV1, and at least annually.
- Record each rehearsal and its findings as evidence.What each section is for
| Section | Why it is there |
|---|---|
| 1–2. Scope and definitions | The incident definition follows CERT-In's; the breach definition follows DPDP section 2(u). Defining T0 is the most useful sentence in the plan, because every clock runs from it and CERT-In counts from 'noticing'. |
| 3. Roles | The CERT-In Directions require a designated point of contact. The out-of-hours rota exists because six hours has no weekend. |
| 4. Severity | Severity drives effort, not reporting. An Annexure I incident is reportable to CERT-In even at SEV3. |
| 5. Clocks | CERT-In six hours; RBI non-bank PSOs six hours; SEBI CSCRF six and 24 hours; IRDAI six and 24 hours; DPDP Rule 7 without delay and 72 hours from 13 May 2027; GDPR Art. 33 72 hours where feasible. Banks and NBFCs: the RBI IT governance direction says 'as per regulatory requirements' without an hour count. |
| 6. Phases | Notification is a phase of its own, run in parallel with containment, not after it. |
| 7. Evidence and logs | CERT-In directions (i) and (iv): clock sync and 180 days of logs in India. DPDP Rules 6(1)(e) and 8(3) add a one-year floor for personal data, traffic data and processing logs from 13 May 2027. |
| 8. Communications | One record, many reports. Inconsistent statements to different authorities are hard to explain later. |
| 9. Service providers | CERT-In's FAQs say the reporting duty cannot be transferred by contract; your vendor reporting does not relieve you. |
| 10. Testing | A rehearsal record is evidence the plan operates, which is what an auditor and a regulator both look for. |
Keep the evidence that the plan works
An incident plan is judged after the fact, so the useful question is what you can show. TryTrustable's evidence ledger is hash-chained and timestamped at collection, and records failing control results as well as passes, which lets you show that controls were operating before an incident rather than after it. The breach simulator runs a scenario against your real data map and drafts the notification, which makes a good tabletop exercise.
For the notices themselves, use the data breach notification templates. For the rules behind section 5, read the CERT-In Directions guide and the CERT-In vs DPDP comparison.
The things people ask us
What should an incident response plan in India include?
Named roles including a CERT-In point of contact, a definition of T0, severity levels, the reporting clocks that apply to you, the phases of response, evidence and log handling, communications rules, service provider duties and a testing schedule. The Indian specifics are the six-hour CERT-In clock, 180-day logs in India, clock sync, and from 13 May 2027 the DPDP Rule 7 duties.
Why define T0 in the plan?
Because every clock runs from it. CERT-In's six hours start on noticing the incident, and DPDP and GDPR run from becoming aware. If the plan does not say what counts, people argue about it during the incident, and the argument itself uses up the hours. A clear rule, such as the first human acknowledgement of an alert, removes that.
Does the CERT-In point of contact have to be a specific person?
The Directions require a designated point of contact, notified to CERT-In in the Annexure II format with name, designation, organisation, address, email, mobile, office phone and fax, and kept up to date. All CERT-In communications go to that person, so name a deputy in the plan and update CERT-In when either changes.
How often should we rehearse the plan?
No Indian law sets a universal frequency, though sector rules may. At least twice a year is a sensible baseline, with one scenario starting outside office hours, because a six-hour clock that starts at 21:30 on a Friday is the realistic test. Record every rehearsal and its findings: that record is evidence the plan works.
Is an ISO 27001 or SOC 2 incident plan enough for India?
It is a good base, not a finished plan. Those frameworks ask for incident management but do not set Indian clocks. Add the CERT-In six hours and point of contact, 180-day log retention in India, NTP sync, your sector regulator's window, and the DPDP Rule 7 duties to notify the Board and each affected person.
Rehearse the plan against your real data.
Thirty minutes. We run the breach simulator on a sample data map and walk the clocks with you.