By – Manpreet Singh, Co-Founder & Principal Consultant, 5Tattva
At 2:14 a.m. on a Tuesday, an on-call systems administrator at Acme gets a page from the endpoint monitoring tool. A domain controller has spiked to 100% CPU and is making unusual outbound connections to an IP address in a country Acme has no business with. The admin is tired, and has seen plenty of false alarms from that same tool, so he snoozes the alert and goes back to sleep. By 6 a.m., three more servers have joined the beaconing pattern. By 8 a.m., finance can’t log into the ERP system. By 9:30, someone in accounts payable finds a text file on their desktop titled README_RECOVER_FILES.txt.
The scenario is fictional, but the sequence reflects patterns seen across real incidents — the kind of situation an incident response team is often called into after the first 24 hours have already passed. The first 24 hours are where an organization can either contain an incident or let it become a much bigger business disruption. Here’s what actually needs to happen, in order, when an organization realizes it has a problem, and where most of them lose the hours that matter most.
The clock starts at detection, not confirmation
When a security alert comes in at 2 AM the instinct is to wait for certainty. That instinct costs a fortune. Industry research on attacker breakout time has shown that, in many intrusions, the window between initial access and meaningful attacker activity can be measured in hours rather than days.
The first task during the first 24 hours is not investigation. It’s triage. Is it real and if so what do we need to cut off right now to stop it from spreading? That call needs to be made by somebody who can make the call. Not somebody who gets routed up a chain that takes three approvals before somebody will unplug a switch.
Within the first hour you should know if the alert is credible. You should know who has the authority to act. And you should know what systems or accounts need to be immediately contained.
Contain, don’t destroy
After containment, you have two competing goals: limit the damage and preserve evidence. This is when frantic IT teams do real, unnecessary damage. Powering off a compromised host takes away encryption keys, process trees, and maybe even the credentials used to gain entry all stored in volatile memory.
Ideally you isolate at the network layer first (pull the NIC, disable the switch port, block on the firewall) before powering off the host, where possible. Get your volatile memory dump and disk image before anything touches “remediation”. Then remediate. There are a million variations on these steps depending on the situation and systems involved, but that overall flow remains broadly consistent: isolate the threat without killing your ability to learn from it. Doing this requires discipline under pressure; that’s why teams who haven’t practiced it recently will skip it. Teams that ran a table-top exercise last year usually don’t.
Regulatory clocks that don’t care how bad your day is
This is the part generic advisories tend to leave out, and the part that turns a bad day into a legal liability if it’s missed. Depending on where an organization operates and what data was touched, several notification clocks start running and may run in parallel once the relevant reporting threshold is met:
- In India, certain categories of cyber incidents are required to be reported to CERT-In within six hours of noticing the incident.
- Under GDPR, a personal data breach affecting EU data subjects generally has to be reported to the relevant supervisory authority within 72 hours of becoming aware of the breach, where the breach meets the applicable reporting threshold.
- PCI DSS-regulated entities carry card-brand-specific notification obligations that run in parallel with, and independently of, the above.
- U.S. state breach-notification laws vary widely, and sector regulators (HIPAA, the SEC for public companies) can impose additional requirements and timelines depending on the nature of the incident.
Acme’s imaginary IT director spent hours trying to get a handle on the “full scope” before calling in legal and compliance. That instinct, wait until you know everything before you speak, is understandable, and in a regulated environment it’s often the wrong call, sometimes an illegal one. Legal counsel and whoever is responsible for regulatory reporting should be brought into the initial response process, rather than waiting until the forensic investigation is complete. Initial notifications can be caveated appropriately and then updated as facts firm up; waiting for perfect information can itself create unnecessary regulatory risk.
Say something before someone else does
Hour six. Hour seven. Word starts to leak out. An employee posts on social media. A customer sees that the portal is down and asks why on a support forum. A vendor calls and asks what is happening. Silence at this stage buys no time; it reads as incompetence or cover-up to customers, regulators and eventually reporters.
Internal comms need to be fast: employees need to hear from leadership on what is known, what not to do (no external speculation, no posting in public channels) and when they will get an update before rumor fills the void.
There should also be one approved spokesperson for external communications and a holding statement that says what is confirmed without overpromising. “We’re aware of a security incident and are investigating with outside experts” beats both “no comment” and false reassurance. The organisation should also establish a clear cadence for follow-up communications.
Preserve the scene like it’s a crime scene, because it is
Significant activity on impacted systems in that first day should be logged. Who did what to which system at what time. That doesn’t mean excessive bureaucracy for the sake of it. That is how an IR team can recreate actual attacker dwell and access timelines later on, and that’s exactly what your insurer, regulator, or law enforcement many want to see. Companies who can present a clear chain of custody and hour-by-hour activity report will be in a much better position to conduct shorter (and less expensive) investigations than those who can’t.
The goal isn’t to keep a transcript of every keystroke. But to have a dependable record of the decisions made and actions performed that may impact the investigation/recovery/reporting process.
What separates a bad day from a bad year
Organizations that come out the other side of an incident in reasonable shape almost always had three things in place before anything happened: a written incident response plan with actual names and phone numbers attached to it, not just role titles; a retainer with a forensics/IR partner, so the first call during a crisis isn’t also the first sales conversation; and at least one tabletop exercise in the past year that included legal, communications, and executive leadership, not IT alone.
The first 24 hours can be thought of as four priorities: detect and triage quickly, contain without destroying evidence, activate legal and communication processes early, and maintain a clear record of every significant action. None of that is complicated. Almost none of it is expensive relative to the cost of improvising all of it live, during hour one of a real incident. Acme Corp’s fictional leadership found that out the hard way. The lesson is straightforward: incident response is not something an organisation can build after the incident has already started. The preparation has to happen before the first alert.