The first hour, and the first seventy-two

You know now. That is the moment the law cares about, and it is the moment this page is written for.

Everything below is ordered on one rule. Preservation comes before remediation. A rebuilt server is an answer nobody can reconstruct — not for you, not for your board, not for the regulator who will ask when it started.

The sequence is short. Work down it.

The first fifteen minutes

1. Write down two times. The time the incident appears to have occurred, and the time you found out — whether you noticed it yourself or somebody brought it to your notice. Keep them separate; CERT-In's own incident reporting form collects them as two distinct fields, "Occurrence date & time (dd/mm/yyyy hh:mm)" and "Detection date & time (dd/mm/yyyy hh:mm)". The six hours in Direction (ii) runs from the second of them: the moment you noticed, or were brought to notice.

2. Disconnect the affected systems from the network. Do not power them off. Pull the cable, disable the interface, move the port to an isolated VLAN. Isolation ends the attacker's access. Powering down ends the investigation's access at the same time: whatever the machine is holding in memory is gone, and a machine that has been shut down and restarted can no longer be examined in the state it was found.

3. Stop the backup jobs. A scheduled run from this point can overwrite a clean restore point with an encrypted or tampered one, or write attacker activity into the only copy you have. Suspend the schedule now and decide later.

4. Do not restore, re-image, or "just clean it". Each of those answers today's question — make it work again — by destroying tomorrow's, which is how did they get in, what did they take, and are they still here. Restoring from a backup taken after the compromise puts the same door back. Re-imaging removes the only record of what was on the machine.

5. Get one person who can authorise taking systems offline. Not a committee. Somebody who can say yes, the site goes down at 02:00 without a meeting. Containment decisions have to be made faster than an approval chain moves.

Why the order is preservation, then remediation

This is not a preference. The Directions themselves turn on artefacts that a rebuild destroys.

The logs have to exist, and they have to survive. Direction (iv) of the CERT-In Directions of 28 April 2022:

"All service providers, intermediaries, data centres, body corporate and Government organisations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction. These should be provided to CERT-In along with reporting of any incident or when ordered / directed by CERT-In."

Two verbs, doing different work. Shall mandatorily attaches to enabling the logs and keeping them — a rolling 180 days, within Indian jurisdiction. Should attaches to providing them to CERT-In with a report. It is the mandatory half that governs your next hour: those logs have to exist, they have to cover a rolling 180 days, and they have to be maintained securely and within the Indian jurisdiction for the whole of that period. A re-imaged server produces none of them.

CERT-In has published what kinds of logs it has in mind. FAQ Q 37: "The logs that should be maintained depend on the sector that the organisation is in, such as Firewall logs, Intrusion Prevention Systems logs, SIEM logs, web / database/ mail / FTP / Proxy server logs, Event logs of critical systems, Application logs, ATM switch logs, SSH logs, VPN logs etc." The same answer adds that "this list of logs is not exhaustive but has been mentioned to provide flavour of logs to be maintained by the relevant teams" — and then the limb that decides what those logs have to contain: "From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded." Failed logins are evidence. So is the scan that did not work.

And none of it reconstructs anything without synchronised clocks. Direction (i) requires all service providers, intermediaries, data centres, body corporate and Government organisations to connect to the NTP Server of NIC or NPL, or to NTP servers traceable to them, for synchronisation of all their ICT systems clocks. FAQ Q 39 explains why in one sentence: "Without an accurate time stamp it is extremely challenging to re-create accurate sequence of events thus causing serious hindrance while handling cyber incidents."

So the practical form of the rule is this. Before anything is rebuilt, capture the state — the disk, the running system, the logs, and the time. What that capture looks like when you have no forensic tooling and nobody has arrived yet is set out here.

Hours 0–6: the clock, and where it starts

Direction (ii), in full:

"Any service provider, intermediary, data centre, body corporate and Government organisation shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents. The incidents can be reported to CERT-In via email ([email protected]), Phone (1800-11-4949) and Fax (1800-11-6969). The details regarding methods and formats of reporting cyber security incidents is also published on the website of CERT-In www.cert-in.org.in and will be updated from time to time."

Noticing, or being brought to notice. A customer's email starts the clock. A researcher's disclosure starts the clock. A vendor calling to say their platform was breached and your tenant is in it starts the clock. Awareness is the trigger; confirmation and containment come after it. CERT-In restates the same trigger in FAQ Q 24: "The cyber incident needs to be reported to CERT-In within 6 hours of noticing the incident or being brought to notice about such incident."

Suspicion is inside the definition. Rule 2(h) of the CERT-In Rules, 2013, as CERT-In itself reproduces it at FAQ Q 3:

"'Cyber Security Incident' means any real or suspected adverse event in relation to cyber security that violates an explicitly or implicitly applicable security policy resulting in unauthorised access, denial of service or disruption, unauthorised use of a computer resource for processing or storage of information or changes in data, information without authorisation."

Real or suspected is the operative pair, and it sits at the front of the definition. Awareness from any direction is enough on the trigger; a suspected adverse event is already the subject matter.

Who this binds. Direction (ii) names service providers, intermediaries, data centres, body corporate and Government organisations. FAQ Q 25 reproduces the s.43A explanation of "body corporate": "any company and includes a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities." On the s.43A explanation, that reaches a sole proprietorship running a website.

What Direction (ii) puts on the clock. Its subject matter is "cyber incidents as mentioned in Annexure I", and Annexure I lists twenty types. Item (iii) is unauthorised access of IT systems or data. Item (iv) is "Defacement of website or intrusion into a website and unauthorised changes such as inserting malicious code, links to external websites etc." Item (v) is malicious code attacks, and names Ransomware in terms. Item (vii) is identity theft, spoofing and phishing attacks. Items (xi) and (xii) are Data Breach and Data Leak. Item (xvii) is unauthorised access to social media accounts, item (xviii) is attacks or malicious or suspicious activities affecting cloud computing systems, servers, software or applications. Those are eight of the twenty; Direction (ii) puts all twenty on six hours. Read the Annexure and find yours.

Send what you have at hour five. This is CERT-In's own answer to the question the deadline creates — what to send when the facts are not in yet — 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."

So file with what is in front of you at hour five, and report the rest later — "within reasonable time", in CERT-In's own words at Q 30.

What actually goes in the report, field by field, and who signs it: the six-hour report.

Hours 0–6: if the RBI or SEBI regulates you

Then more than one filing falls due before hour six, and for an RBI-regulated entity the two clocks start at different moments.

• The RBI. The incident goes to the RBI on the DAKSH platform (daksh.rbi.org.in) within six hours of detection, under the Directions of 31 July 2026: commercial banks at para 182, small finance banks at para 181, payments banks at para 181, urban co-operative banks at para 88, credit information companies at para 177, NBFCs in the Base Layer with asset size ₹500 crore and above at para 28 (Chapter IV), and NBFCs in the Middle, Upper and Top Layers other than Core Investment Companies and Housing Finance Companies at para 141 (Chapter V). A housing finance company reports its cyber incidents to the National Housing Bank: the note to para 141 of the NBFC Direction. A Core Investment Company, and an NBFC in the Base Layer below ₹500 crore, are placed in Chapter III by that Direction's applicability para 3(2). Each of those Directions separately directs a pro-active notification to CERT-In as well — commercial banks at para 182, small finance banks at 181, payments banks at 181, urban co-operative banks at 87, credit information companies at 177, NBFCs in the Middle, Upper and Top Layers other than Core Investment Companies at 141 — and the CERT-In obligation in Direction (ii) runs on its own trigger for every entity in its list of addressees, whatever else that entity owes. Note the trigger word: RBI says detection, CERT-In says noticing or being brought to notice. For an entity told about its own breach by somebody else, those are two different moments.
• SEBI. For an incident falling under the CERT-In Directions, a regulated entity notifies SEBI and CERT-In within six hours, by email to [email protected], and files on the SEBI Incident Reporting Portal within 24 hours — CSCRF Annexure-O part B clause 1. Stock Brokers and Depository Participants report to their Stock Exchanges and Depositories inside the same six hours. The same clause routes any other cybersecurity incident to SEBI, CERT-In and NCIIPC, as applicable, within 24 hours.

The full divergence — instrument, clock, what each one runs from, channel, and the follow-on calendar — is in the six-hour report.

Hours 0–6: the calls

CERT-In. [email protected], 1800-11-4949, fax 1800-11-6969 — the three channels named in Direction (ii). The line is live whatever time it is: Rule 5 of the CERT-In Rules, 2013 provides that CERT-In "shall function on 24-hours basis on all days of the year including Government and other holidays", and Rule 12(1) puts an Incident Response Help Desk on the same footing.

Your Point of Contact. Direction (iii) requires service providers, intermediaries, data centres, body corporate and Government organisations to designate a Point of Contact to interface with CERT-In, notified in the Annexure II format — name, designation, organisation name, office address, email ID, mobile number, office phone, office fax — sent to [email protected] and kept updated. Direction (iii) also sets out what that designation buys you: "All communications from CERT-In seeking information and providing directions for compliance shall be sent to the said Point of Contact." If yours is designated, that is the person who needs to be awake. If it has yet to go in, send it now — the format is eight fields and one email address.

Your legal or compliance owner, because three things they will ask about are already answered in CERT-In's published FAQ and in the Rules:

• Can our partner file on our behalf? 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." On CERT-In's answer, the duty sits with the entity that noticed the incident.
• Our contract has a confidentiality clause. FAQ Q 22: the reporting obligation "is statutory in nature and overrides any confidentiality clause in any contract by virtue of the provisions of section 81 of the IT Act, 2000."
• And the disclosure objection — reporting makes us public. The Rules answer it directly. Rule 13(2) of the CERT-In Rules, 2013 provides that CERT-In "shall not disclose any information which may lead to identification of individual, group of individuals or organizations affected by cyber security incidents without their explicit written consent or orders of Indian competent courts", and extends the same protection to the identity of whoever reported it.

Us, if you want a team on it. +91 22 4164 2220. Answered 24/7.

Hours 6–48: contain, and find out what you can still produce

Containment runs ahead of the full picture. Close the probable entry points, isolate the compromised systems, revoke every credential that was valid during the window, block the attacker's IPs and domains, and put emergency firewall rules in — within hours, before the attack path is mapped, not after. The object is to stop active data exfiltration and prevent lateral movement while preserving the forensic evidence.

Two things belong in this window and not later, because the answers change what is still possible:

Can you actually produce 180 days of logs, by system? Direction (iv) sets the retention; FAQ Q 37 names the kinds. Walk the list — firewall, IPS, SIEM, web, database, mail, FTP, proxy, event logs of critical systems, application, SSH, VPN — and mark each one with how far back it goes. A shared web host that keeps thirty days of access logs is a finding you want at hour six rather than at day ten, because at hour six there are still things you can do about it.

Find out whether a restore has actually been performed and verified, and on what date. That answer, rather than the existence of a backup set, is what sets the shape of the recovery — and it is worth finding out now, while there is still time to test one.

Keep a register of every containment action as you take it — what was done, by whom, at what time, and what has to be true before it is reversed. You will need it to unwind the emergency controls without reopening the entry point, and the timeline you file later is built from it.

If this is ransomware, the decision you are walking towards over the next two days turns on four inputs, and the filing above is due regardless of how you decide: what the ransom decision turns on. If the visible surface is the victim — a replaced homepage, an injected redirect, a browser interstitial — start here instead.

Days 2–7: the gate before anything comes back online

There is one gate, and it has two conditions.

Eradication first. Every attacker foothold has to be removed — backdoors, persistence mechanisms, compromised accounts, and malicious code — not just the artefact you found first. Credentials that were valid during the compromise are compromised credentials, including service accounts and API keys.

Hardening second. Systems are hardened before being brought back online. The entry point that worked once works again.

Restoring before both are done returns you to hour zero with less evidence than you had the first time. That is the failure mode this whole sequence exists to prevent.

Weeks 2–4: closure

Closure is not "the site is up". It is: the entry point is established, the timeline holds, the scope of what was accessed or taken is settled, the emergency containment controls have been retired against a criterion rather than forgotten, and the follow-on filings your regulator schedules have gone in.

The entry point is established from what still exists — the logs you can still pull, and whether the clocks they were written with agreed. Both are things you can act on today: pull the logs before retention rolls them off, and check the clocks before you read a sequence out of them. How they got in, and why your logs decide whether you can answer.

If you are reading this now

Do the first five. Write down both times, disconnect without powering off, stop the backup jobs, restore nothing, and find the person who can authorise taking systems offline.

Then file, with what you have.

The sequence above, as a document you can print and work through: the page to print, the hour 0 to 1 order, 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, and the clocks by regime. The first 72 hours — incident action pack.

Security Brigade has been CERT-In empanelled since 2008 and works incidents 24/7. +91 22 4164 2220.

Every clause number, quotation and channel above was read from the primary instrument — the CERT-In Directions of 28 April 2022 and their Annexures, the May 2022 CERT-In FAQ, the CERT-In incident reporting form, the CERT-In Rules, 2013, the six Reserve Bank of India cybersecurity Directions of 31 July 2026, and the SEBI Cybersecurity and Cyber Resilience Framework of 20 August 2024 — on 1 September 2026.