Incident Response
When a security incident occurs, the first priority is understanding what happened and controlling the situation.
Incidents are decided in the first few hours, and mostly by preparation. Whether logs exist, whether someone can authorise disconnecting a system, whether anyone knows who to call — these are settled long before the incident starts.
Response work is deliberately unglamorous: establish what is actually happening, stop it spreading, preserve what you will need later, and restore operations in an order that does not undo the containment.
The order matters. Each stage depends on the one before it having been done properly.
- ALERTAlertSomething is reported, detected or noticed
- TRIAGETriageEstablish whether this is an incident and how serious
- CONTAINMENTContainmentLimit spread while preserving what will be needed
- INVESTIGATIONInvestigationEstablish scope, entry point and timeline
- ERADICATIONEradicationRemove the access and the mechanism behind it
- RECOVERYRecoveryRestore operations in a controlled order
- LESSONS LEARNEDLessons learnedTurn the event into changes that hold
Conceptual model of an incident response process. Actual engagement scope and the division of responsibilities are agreed in advance.
The costly mistakes happen early
The instinct during an incident is to make it stop — rebuild the machine, reset everything, get back online. That instinct frequently destroys the evidence needed to understand what happened and to know whether it is actually over.
The other common failure is partial containment. If the original access route is still open, restoring from backup returns the environment to the state that was compromised in the first place.
How an incident is tracked.
States used to communicate where an incident stands. Illustrative — not a live status board.
The state an incident is in determines what your team is being asked to decide.
What response covers
Availability, engagement model and division of responsibilities are agreed in advance rather than assumed.
When Do You Need Response Capability in Place?
Output your team can act on.
Which of these apply depends on engagement scope.
A clearer view of what activity is happening across the environment in scope.
What the monitored signals show over time, and what changed.
Activity identified as worth attention, with the reasoning behind it.
What was examined, what it indicated and what was ruled out.
A written account of an incident: timeline, impact and actions taken.
Recommended actions, and where a decision needs to sit with your team.
Where detection, logging or process could be strengthened.
The rest of the operations lifecycle.
Questions we get asked before an engagement.
Availability and engagement model are agreed in advance rather than assumed. We would rather set out clearly what is available under your agreement than imply an emergency capability you have not arranged — which is exactly the kind of assumption that fails during an incident.
Preserve rather than repair. Avoid rebuilding or wiping affected systems, keep the logs you have, and note what was observed and when. Isolating a system from the network is usually safer than powering it off, because shutting down discards volatile evidence.
Yes, and that is a common arrangement. Recovery usually depends on whoever runs the infrastructure, so response works better as a coordinated effort than as a parallel one.
A post-incident review: what happened, how it was possible, what was done, and what should change. The value of an incident is almost entirely in whether that review produces changes that actually get made.
Talk to a Security Expert
Whether you are dealing with something now or preparing for the possibility, the conversation starts the same way: what happened, what you can see, and what you can act on.