Incident response
Incident response is the structured process of detecting, containing, eradicating and recovering from a security incident, followed by a review of what allowed it to happen in the first place.
Why having a plan beforehand changes the outcome
Deciding how to contain, investigate and recover from a breach while it is actively happening leads to slower, more error-prone decisions than following a plan written calmly in advance, when there is no pressure and no clock running.
The step most teams skip
The review after recovery, examining what allowed the incident to happen in the first place, is the step most frequently skipped once a service is back online, which is exactly how the same root cause ends up causing a repeat incident later.
For a step-by-step walkthrough of handling a real compromise, see our server breach incident response guide.
How the phases map onto a single VPS
NIST published SP 800-61 Revision 3 in April 2025, replacing the 2012 Revision 2. Its abstract frames incident response as part of everyday cybersecurity risk management (aligned with CSF 2.0) rather than a separate emergency procedure: prepare for incidents, reduce their number and impact, and improve detection, response and recovery. The NIST publication page has the details.
CISA's incident response playbook turns this into five working phases: preparation, detection and analysis, containment, eradication and recovery, and post-incident activities. Its preparation phase includes developing and testing courses of action for containment and eradication, and arranging how forensic data will be collected.
On a small VPS, preparation is mostly a short written page: who holds root, how you reach the server if SSH is unusable (the provider console), which backup you would restore from and when you last tested it, and where a copy of the logs lives off the machine. See the 3-2-1 backup guide and the log analysis guide for the two pieces most often missing.
Preserve evidence before you change things
Every cleanup action overwrites something an investigator would want. RFC 3227 lists evidence from most to least volatile: registers and cache, then the routing table, process table and memory, then temporary file systems, then disk, then remote logging data. It also warns not to trust the programs on the suspect system, since a rootkit can make them lie.
CISA's playbook asks for forensic images to be captured during containment and for evidence to be preserved before eradication begins. If your provider offers snapshots, take one first. For a quick record of live state, save the output somewhere off the server:
ss -tupan > ss.txt
ps auxf > ps.txt
last -a -F > last.txtTreat these as indicative only, because they run the server's own binaries. Do not reboot or reinstall until you have captured what you need: a reboot discards memory and process state. Once evidence is safe, continue with the breach response guide.
Related terms: Containment, RECOVERED vs VERIFIED, File integrity monitoring, SIEM.
Frequently asked questions
Do small businesses actually need a formal incident response plan?
Yes, even a short, simple one. Having pre-agreed steps for containment, communication and recovery measurably reduces both downtime and decision-making stress during a real incident.
What is the first step in incident response?
Containment, meaning stopping the incident from spreading further, generally comes before full investigation or cleanup, since an uncontained breach can keep getting worse while it is being analyzed.
Who should be involved in incident response, even at a small company?
At minimum, whoever has server access and decision-making authority, plus a clear escalation path to anyone else, such as a hosting provider or security contractor, who might need to be brought in.
Is restoring from a backup a complete incident response?
No. CISA lists reimaging from known-good sources as one eradication step, but also requires mitigating the vulnerability or condition that was exploited. A restore that leaves the same weakness in place, or restores a backdoor along with the data, invites a repeat.
When should evidence be collected?
Before eradication. CISA asks responders to confirm that all means of persistent access are accounted for and that all evidence has been collected before they start removing artifacts, and RFC 3227 says to collect the most volatile data first.
Want to see where your own server stands?
Run the free, read-only server check, or open the Security Lab and watch the detect, contain, recover, verify loop in action.
Get your free server checkOpen the Security Lab