The First 72 Hours
Incident Action Pack
The first hour decides what can be answered later. The sixth hour is a statutory deadline, and Direction (ii) starts it when you notice the incident or are brought to notice of it: “noticing such incidents or being brought to notice about such incidents”. Section 0 is one page to print and keep off the network you are about to investigate. Everything after it is worked in order.
The First 72 Hours
Enter your work email for the printable pack — the page to print, the hour 0 to 1 sequence, the four calls and the Point of Contact fields, the CERT-In filing worksheet, the containment log, the 180-day log self-test, the pre-restore gate, the closure artefacts, the clocks by regime, and the timestamp check.
Check your inbox
We've emailed you a link to download The First 72 Hours.
The link expires in 48 hours. If it hasn't arrived in a few minutes, check your spam folder.
We couldn't send the download link. Please try again, or contact us and we'll email you The First 72 Hours.
Hour zero
Four acts, and each one ends an investigation
None of them is careless. Each is a reasonable thing to do to a machine that is behaving badly, and each is available to anyone with a console before a decision-maker has been found. What they share is that the damage does not show: the estate looks tidier afterwards, and the question of how the attacker got in has quietly become unanswerable.
Power the machine off
Everything held only in memory goes with it: running processes, open connections, keys held by a live process, code that never touched disk. The cost is invisible at the time, because the machine looks fine afterwards.
Disconnect at the network and leave it running. A live host can still be captured later; a powered-off one cannot.
Restore from backup
The compromised state is the evidence, and a restore writes over it. It also puts back whatever the backup contains, which may include the way in.
Freeze the schedule and mark the current retention as hold. Rotation runs on a timer and does not wait for the incident meeting to finish.
Re-image and rebuild
Powering off plus the disk, taken together. A rebuilt host is the machine you would have imaged, and nothing on it survives the rebuild to work from.
Say out loud in the first hour that nothing is re-imaged, and name the one person who can authorise it.
“Just clean it”
The timeline. Deleting the artefact deletes the timestamp that dates the intrusion, and the timeline is what the root cause statement is written from.
Screenshot it, record the path and the times, leave it. Section 6 is where removal happens, once the record exists.
Section 1 turns these into eight ordered actions with a write-in beside each: record the time and how you found out, isolate at the network rather than at the power switch, freeze the backup schedule, name who may authorise a rebuild, stop deleting, preserve volatile state where somebody on hand can, investigate with credentials the attacker has not seen, and start one log that every action goes into. Begun at hour one that log is a timeline; begun at hour six it is a reconstruction.
The clocks
Five rows, and the clocks start at different moments
CERT-In’s six hours run from noticing an incident or being brought to notice of it. The RBI filing on DAKSH runs from detection. SEBI’s runs from the earlier of the two. For an entity told about its own breach by a customer, a vendor or a researcher, those are three different times on the same incident — which is why section 0 records all three on the sheet you print, and why section 8 states each row by the class of entity it speaks to. Where more than one row describes you, all of them are owed.
Any service provider, intermediary, data centre, body corporate or Government organisation
Report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about them. [email protected] · 1800-11-4949 · fax 1800-11-6969.
A Commercial Bank as /410 ¶3 defines that term, a Small Finance Bank, Payments Bank, Urban Co-operative Bank, Credit Information Company, an NBFC in the Base Layer with asset size ₹500 crore and above, or an NBFC in the Middle, Upper or Top Layer other than a Core Investment Company or a Housing Finance Company
Report cyber incidents within six hours of detection on the DAKSH platform, https://daksh.rbi.org.in. Detection is a different moment from the trigger in the row above.
A Housing Finance Company
Cyber incidents are reported to the National Housing Bank.
A SEBI regulated entity
Where the cyber-attack, cybersecurity incident or breach falls under the CERT-In Cybersecurity directions, notify SEBI at [email protected] and CERT-In within 6 hours of noticing or detecting the incident, or being brought to notice about it, and file on the SEBI Incident Reporting Portal within 24 hours. Any other cybersecurity incident goes to SEBI, CERT-In and NCIIPC, as applicable, within 24 hours.
A stock broker or depository participant
Also report to your stock exchange or depository, alongside SEBI and CERT-In, within the same 6 hours of noticing or detecting the incident, or being brought to notice about it.
The CERT-In Incident Response Help Desk runs on a 24-hour basis on all days including Government and other public holidays — Rule 12(1) of the CERT-In Rules, 2013 — so hour six is live at 02:00 on a Sunday. Rule 5 puts CERT-In itself on the same footing.
The filing
Send it at hour five with what you hold
Fill what you hold and send it at hour five. CERT-In provides for the rest in its own terms, at FAQ Q 30: “The entities may provide information to the extent available at the time of reporting. Additional information may be reported later within reasonable time to CERT-In.” The 2013 Rules put the same instruction in older words: Rule 12(1)(a) requires the listed types of incident to be reported “as early as possible to leave scope for action”, and service providers, intermediaries, data centres and body corporate to report “within a reasonable time of occurrence or noticing the incident to have scope for timely action”. Both formulations are about preserving somebody’s ability to act, and that is what the deadline is for.
Section 3 lays the reporting form out field by field in its own order, with a column for your answers, so the filing is assembled rather than composed. It marks the two rows that decide whether the rest of the pack works: whether the affected system is critical to your mission, which the form asks in two halves and expects both; and the occurrence and detection times, which the form collects separately and which section 0 keeps apart from the moment you were brought to notice.
Contents
Twelve sections, worked in order
It is a working document, not a guide. Section 0 detaches and stays off the network you are investigating; sections 1 to 9 are filled in as the hours pass; section 10 shows where every clause came from; and section 11 is the only page where we describe what we do.
0. The page to print
One sheet to print now and keep off the network you are about to investigate: the four acts that end an investigation, a deadline block that computes hour six from the moment you were told, and the four calls.
1. Hour 0 to 1: what not to do first
Eight ordered actions. Each costs a few minutes, none requires a specialist, and the point of the hour is to stop the estate changing while you still do not know what happened in it.
2. Hour 0 to 1: who to wake
The four calls and the block that holds them, plus Annexure II’s eight fields — the Point of Contact format, which can be sent to CERT-In today whether or not you are in an incident.
3. Hour 1 to 6: the filing
The CERT-In Incident Reporting Form’s own fields, in its own order, with a column to fill in. Occurrence and detection are collected separately, and section 0 records the third moment the clock actually runs from.
4. Hour 1 to 6: the containment log
Time, action, system, owner — and the column that decides whether a temporary measure is ever undone: the condition that retires the change. Twelve blank rows, and the time zone goes in the cell rather than the heading.
5. Hour 6 to 48: can you produce the logs?
Direction (iv)’s rolling 180 days against CERT-In’s own list at FAQ Q 37, worked as a self-test: retention you hold, where it is stored, who can produce it and how fast, and whether it was retrieved.
6. Days 2 to 7: eradication, and the pre-restore gate
Three eradication rows, then nine that have to be answered before anything returns online. A restore onto the same way in produces a second incident, and the second arrives with the first one’s remediation already spent.
7. Weeks 2 to 4: what closure requires
Nine artefacts: the timeline, a root cause statement that names the access route, the scope finding and its basis, corrective measures with owners and dates, the follow-on filings made and evidenced, the evidence retained and who holds it, the customer, partner and insurer notifications, the retest, and the pack itself updated.
8. The clocks, by regime
Five rows scoped by addressee — who the rule speaks to, what is owed and when, the clause, and a column for the owner on your side. Where more than one row describes you, all of them are owed on the same incident.
9. Timestamps that hold
What to record during the incident, and a four-item synchronisation check to run afterwards. Direction (i), and CERT-In’s own reason for it at FAQ Q 39.
10. Sources
Six primary instruments, each with the clause references used and the sections that use them. Every one was read from the primary text rather than from a secondary summary.
11. Working with Security Brigade
One page: what an engagement covers, what it produces, and the two things in this pack that are worth more done without us.
The two sections that decide the outcome
Whether the logs exist, and what has to be true before the restore
Section 5 — can you produce the logs?
Direction (iv) requires all service providers, intermediaries, data centres, body corporate and Government organisations to mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days, and provides that the same shall be maintained within the Indian jurisdiction. Three things sit in that mandatory limb: the logs are enabled across all ICT systems, held securely for a rolling 180 days, and maintained within the Indian jurisdiction.
The self-test runs the thirteen system classes CERT-In gives at FAQ Q 37 — an answer that opens by saying the logs to be maintained depend on the sector the organisation is in, and a list CERT-In calls not exhaustive — against four columns — the retention you hold, where it is stored, who can produce it and how fast, and whether it was retrieved for this incident. Work it at hour six, while the window is still whatever it is. Where a shared host or a managed platform sets the retention, the answer is theirs: ask them in writing today and record the time you asked beside the answer.
Section 6 — the pre-restore gate
Nine rows that have to be answered before anything goes back online: the initial access route identified and closed, every reachable credential rotated, the search for persistence written down rather than only its results, a restore source dated before the earliest evidence of intrusion, the backups checked for the same persistence, multi-factor authentication on every path that will be live, monitoring for the specific behaviour seen, the containment actions retired against their criteria, and the filings made.
“We are back up” and “we are recovered” are different claims, and the gate is what separates them. Where commercial pressure returns the estate before the rows are answered, the pack asks you to write down which ones were not answered and who decided.
FAQ Q 37 adds a line worth having in front of you while you answer section 5: “From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded.” A record of an authentication that failed is evidence of an attempt that produced no other trace, which is what lets it date the beginning of an intrusion. It is also the record a retention rule built around what happened has no reason on its face to keep, so section 5 asks for the retention you hold rather than the retention your policy claims.
Where we sit
We do the work. The duty stays with your entity
Security Brigade responds to live incidents 24/7 and takes full ownership of CERT-In six-hour incident notification as part of an engagement, handling the concurrent RBI and SEBI notifications where they apply. We do the drafting, the assembly and the sending. What we cannot do is hold the obligation, and CERT-In is explicit about that at FAQ Q 13: “Any entity which notices the cyber security incident, shall report to CERT-In. The obligation of reporting of cyber incident is neither transferrable nor indemnified or dispense with.” We have been CERT-In empanelled since 2008.
Two things this pack names are worth more done without us than with us, and both take an afternoon. Designating a Point of Contact under Direction (iii) is Annexure II’s eight fields sent to [email protected] — name, designation, organisation, office address, email, mobile, office phone, office fax — and it is where all communications from CERT-In seeking information and providing directions for compliance are sent. Direction (iii) also requires that information to be updated from time to time, so the date it last went is the one worth recording. Asking your host or platform provider, in writing, how long they actually keep your logs is the other. Section 2 and section 5 are where the answers go.
Working section 1 right now?
Tell us what you are seeing, what is already isolated, and the time you were brought to notice, or noticed it yourself — whichever came first is what starts the six hours. Security Brigade works incidents 24/7, on +91 22 4164 2220.
Describe the incident