What is incident response?
Incident response (IR) is the structured process an organisation follows when it detects a security incident — a breach, an intrusion, a ransomware event, or any activity that threatens the confidentiality, integrity, or availability of its systems.
The goal isn't just to stop the immediate problem. A well-run response also limits how far an incident spreads, preserves evidence for later analysis, and produces a clear record of what happened so the underlying weakness doesn't simply get exploited again.
The incident response lifecycle
Most incident response frameworks — including the widely referenced NIST model — describe the process in a similar sequence of phases:
Preparation
Building the plan, tooling, and trained team before an incident ever happens.
Detection & Analysis
Identifying that something is actually wrong, and scoping what's affected.
Containment
Stopping the incident from spreading further while preserving evidence.
Eradication
Removing the root cause — malware, unauthorised access, the vulnerability itself.
Recovery
Restoring affected systems to normal operation, carefully and verifiably.
Lessons Learned
A post-incident review — what happened, what worked, what needs to change.
Who's involved
Incident commander
Owns the overall response — makes the calls, coordinates the team, and is the single point of communication upward and outward.
Technical responders
Investigate systems, contain the spread, and carry out remediation. Often split across network, endpoint, and application specialists depending on scope.
Communications lead
Manages internal updates, customer communication, and — where required — regulatory notification, so responders can stay focused on the technical work.
A basic readiness checklist
Things worth having in place before an incident happens, not during one:
- A documented incident response plan that's actually been read by the people who'd use it
- A clear escalation path and an up-to-date on-call contact list
- Logging and monitoring sufficient to reconstruct what happened after the fact
- A tested backup and recovery process — tested, not just scheduled
- A communications template for customers and regulators, drafted in advance
- At least one tabletop exercise run in the last 12 months
Glossary
- IOC
- Indicator of Compromise — a piece of forensic data suggesting a system has been breached.
- Dwell time
- The length of time an attacker has undetected access before being discovered.
- Blast radius
- The scope of systems and data affected by an incident.
- Tabletop exercise
- A discussion-based simulation of an incident, used to test a response plan without a real event.
- Chain of custody
- The documented handling of evidence, preserved so it remains usable later.
- Post-mortem
- A structured review conducted after an incident is resolved.
Public advisory log
A record of general incident-category advisories referenced through this resource. Entries are anonymised and published for informational purposes only.
RECENT ENTRIES
| Date | Category | Sector | Status |
|---|
Frequently asked questions
Is UKSRT a government body or emergency service?
No. UKSRT is an independent, privately maintained reference resource. It holds no statutory or law-enforcement authority and is not affiliated with any government agency.
Should I call UKSRT during an active incident?
This page is an informational reference, not an incident intake line. Organisations experiencing an active incident should follow their own response plan or a retained provider.
How long does a typical incident take to resolve?
It varies enormously — from hours for a contained phishing incident to weeks for a widespread ransomware event. Preparation is the biggest factor in how fast containment happens.
What's the difference between IR and disclosure coordination?
Incident response deals with an active security event happening right now. Vulnerability disclosure (see UKCert) deals with a weakness being reported before it's exploited.