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.
What is incident response?
Incident response covers incident triage, investigation into entry point, scope, timeline and impact, containment that limits spread without destroying evidence still needed, evidence preservation of volatile data before a rebuild loses it, recovery support that restores operations without reintroducing the problem, a structured post-incident review, and advance preparedness work. A common early mistake is rebuilding or resetting a system before the evidence needed to understand what happened is captured, or restoring from backup while the original access route is still open.
Who needs it? Organizations with an active incident underway where the priority is understanding and control, organizations with a suspected compromise where indicators suggest access but scope is unclear, and organizations wanting response capability and an agreed engagement model in place before an incident happens.
How TMG Security helps. TMG Security triages, investigates and contains incidents without destroying evidence, preserves what a rebuild would lose, supports recovery in an order that does not reintroduce the problem, and delivers a structured post-incident review your team can act on. Availability, engagement model and division of responsibilities are agreed in advance rather than assumed.
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.
How pricing and engagement model work
Incident response can be arranged as a retainer, agreed in advance so availability and response time are known before an incident happens, or engaged on demand when an incident is already underway. Cost depends on factors such as the response time expected, the size and complexity of the environment involved, and whether a retainer or on-demand engagement model is chosen. These factors are agreed during scoping before a quote is provided.
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.
Duration depends on the response time expected, the size and complexity of the environment involved, and whether the engagement is a pre-arranged retainer or an on-demand response to an incident already underway. These factors are agreed during scoping.
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.