Incident response: the first hour

The first hour of an incident decides how much of the rest is recoverable. Most of what goes wrong in a breach is not the breach itself. It is the scramble that follows, when nobody agreed in advance who makes the call, where the evidence lives, or when to pull a system off the network. A SOC analyst on a Tuesday night shift does not have time to invent a process. The process has to already exist.

What follows is how experienced responders order that first hour. It draws on the patterns the Verizon Data Breach Investigations Report sees year after year, on the guidance ENISA and the UK National Cyber Security Centre publish for teams, and on the plain reality of watching people do this work well. The names of the people are kept out of it. A defender who handles a live intrusion at 2am is rarely the person who wants their employer's worst night in a headline.

Confirm it is real before you sound the alarm

An alert is a claim, not a verdict. The first job is to decide whether something has actually happened, because a false alarm that triggers a full response burns the team's credibility for the next one. The responder checks the source of the alert, looks for corroborating signals on other systems, and asks the simplest question available. Does the activity match anything a legitimate user or change would explain?

This is where calm pays for itself. The DBIR has shown for years that a large share of incidents involve credentials and human error rather than exotic technique. So the early check is often mundane. A login from an unusual place, a service account doing something it never does, a file appearing where files do not belong. Confirm the signal, write down the time, and only then escalate.

Name an incident lead and start the clock

The moment something is confirmed, one person takes the lead. Not the most senior person in the building, the person who can run the response. They open a log, note the time the incident was declared, and become the single point through which decisions pass. Everyone else has a defined job. Without this, two engineers reboot the same machine, a third tells a customer something the lead has not approved, and the timeline turns to mud.

The lead also decides who needs to know now and who can wait. Legal, communications, and senior management each have a role, but flooding them in minute three helps nobody. The NCSC's guidance for organisations is consistent on this. A response works when roles are agreed before the incident, rehearsed, and small enough to act fast.

Contain without destroying the evidence

Containment is the instinct that needs the most discipline. The urge to pull the plug is strong, and sometimes pulling the plug is right. But a system powered off in a panic can lose the memory, the live connections, and the running processes that explain what happened. The responder who slows down for thirty seconds to capture that state first is the one whose investigation succeeds.

The practical move is to isolate rather than erase. Cut the affected host off from the network, suspend the compromised account, block the attacker's route in, and leave the rest intact for examination. Containment buys time. It stops the spread without burning the record. The DBIR's recurring finding is that attackers often dwell undetected for a long time, so the goal is not only to stop them tonight but to understand how long they were already there.

Establish scope before you assume it

Once the immediate threat is held, the question becomes how far it reaches. This is where teams either stay honest or start guessing. The responder maps what the intruder touched, which accounts were used, which systems show signs of access, and whether data left the building. Each finding goes in the log with a timestamp. Assumptions get marked as assumptions until evidence confirms them.

Scope shapes everything downstream. It decides whether this is a contained nuisance or a reportable breach, whether regulators need telling within a deadline, and whether customers are affected. Getting it wrong in either direction is costly. Overstate it and you trigger panic and disclosure you may have to walk back. Understate it and you miss the foothold the attacker left for their return. Patience here is not slowness. It is accuracy.

Communicate in facts, not fear

People outside the response need information, and they need it to be true. The lead, or a nominated communicator, gives updates built only on confirmed facts. What is known, what is being done, what is not yet known. Speculation dressed as certainty is how an incident becomes a crisis of trust on top of a technical problem.

Internally, this keeps the team aligned and stops rumour filling the gaps. Externally, it protects the organisation's standing and meets the obligations regulators set. The defenders who do this well share a habit. They tell people what they actually know, they say plainly when they do not know something yet, and they come back when they do. That honesty, held under pressure, is the quality this programme looks for when a response team is put forward for recognition.