The outcome of an incident is decided in the first hours, and almost all of those decisions are organisational rather than technical: who commands, what gets switched off, who is told and what is said. Preparing them after it starts is what turns an incident into a crisis.
What follows: what is decided at the start, who should decide it, what requires judgement, and how it is prepared beforehand.
When suspicious activity is detected, the pressure is immediate and the information scarce. Nobody yet knows the scope, and action is required anyway.
Teams that come through an incident well are rarely the ones that improvise best. They are the ones that had already decided, calmly, who decides what.
What is decided at the start
Whether to contain or to observe. Disconnecting stops the damage and destroys evidence and the ability to understand the scope. Observing preserves both and leaves the attacker inside. There is no universal answer and the choice has to be made in minutes.
Who leads. An incident with several areas acting without coordination produces actions that cancel each other out. The person leading must be named beforehand, with recognised authority to order a disconnection.
Who is notified, and when. The board, legal, and depending on the case customers and the regulator. The deadline is not always discretionary, and discovering it during the incident is too late.
What is communicated. Prolonged silence is read as concealment and premature information usually turns out to be wrong. Both errors cost, and the way out is to communicate early what is known and what is not yet.
What requires judgement
The choice between containing and observing depends on the type of attack and on the value of understanding the scope. Where encryption is under way, containing is obvious; where there is silent access of unknown origin, disconnecting can prevent knowing how they got in and guarantee they return.
Preserving evidence also calls for early judgement. Powering down a machine can erase information that exists only in memory, and that loss is not recoverable. It is worth knowing in advance what gets captured before anything is touched.
And there is an uncomfortable decision worth having discussed: how far service is restored without yet understanding the cause. Restoring quickly onto a system that is still compromised is the most common way to have the same incident twice.
Which obligations come with it
When the incident involves personal data, obligations appear that do not depend on the organisation’s wishes. In Colombia the Habeas Data framework (Ley 1581) and in Mexico the LFPDPPP condition what must be reported and to whom.
Determining whether personal data was accessed, and which, is part of the analysis from the start and not at the end, because deadlines depend on it and they run while the technical team is still working.
Legal is worth involving from the first hour rather than when the technical analysis finishes. Early involvement usually changes what evidence is preserved and how it is documented.
How it is prepared beforehand
Write the crisis directory and keep it outside the systems that might be compromised. A contact that exists only in corporate email is useless on the day email is the problem.
Define the thresholds that turn an event into an incident, and who declares it. Without that definition, the organisation argues about whether this “counts as an incident yet” while the clock runs.
And rehearse. A two-hour tabletop exercise, with the real team and a plausible scenario, reveals more gaps than any document: usually that nobody knows who authorises a disconnection, or that the backup was never tested for that system.
What has to exist first
A named owner with authority to order containment, an alternate communication channel, and a list of critical systems with their owners. All three are prepared in an afternoon and they change the outcome.
It is also worth agreeing external support in advance. Sourcing a forensic analysis provider during the incident adds hours of negotiation at the worst possible moment.
The three questions of the first hour
With incomplete information and high pressure, a short script helps. Three questions order almost any start.
What do we know for certain? Separating the confirmed from the assumed stops an early hypothesis directing every subsequent decision. In most badly handled incidents, the original error was treating an assumption as a fact.
What is at risk right now? Not what might have happened, but which systems and which data remain exposed at this moment. That answer defines what gets contained first.
What do we lose by waiting an hour? This is the question that resolves the contain-or-observe dilemma, because it forces the cost of acting to be compared with the cost of understanding.
After the incident
Technical closure is not the closure of the incident. The post-incident review is still owed, and it is worth doing soon, while the detail is fresh and before the team returns to its usual workload.
That review looks for causes, not culprits. An exercise that ends by pointing at a person guarantees the next incident is reported later, which is exactly the opposite of what is needed.
And it produces a concrete deliverable: what changes in the system, in the process, or in the response script. A review that changes nothing is a meeting.
Should you disconnect immediately?
It depends. It stops the damage and also destroys evidence and the ability to understand the scope. With encryption under way it is usually right; faced with silent access it can prevent knowing how they got in.
Who should lead an incident?
Somebody named beforehand, with recognised authority to order a disconnection. Deciding it during the incident produces uncoordinated actions that cancel each other out.
When should it be communicated?
Early, saying what is known and what is not yet. Prolonged silence is read as concealment and premature information usually turns out to be wrong.
What best prepares a team?
A tabletop exercise with the real team and a plausible scenario. It reveals more gaps than any document, starting with who authorises a disconnection.
