Endpoint Security Incident Runbook (2026)

1Tell us where to send it
Your name and work email — nothing more.
2Check your inbox
Your guide arrives in seconds, not days.
3Use it with your team
Editable and ready to share — make it your own.

A peek inside

See exactly what you're getting

Free PDF

Spotsaas · 2026

Endpoint Security Incident Runbook

✓ How to Use This Runbook

✓ The Six-Phase Response

✓ Severity & Response Targets

✓ Decisions Under Pressure

Get the guide →

What it is

An Endpoint Security Incident Runbook is a first-responder playbook for the moment an endpoint is compromised, malware, ransomware, a stolen laptop, or an EDR alert that turns out to be real. It walks the six phases of incident response, preparation, detection, containment, eradication, recovery, and lessons learned, and for each phase it spells out the concrete UEM, MDM, and EDR actions to take. The purpose is to remove improvisation from the worst moments: instead of deciding what to do while an attacker is active, you follow a sequence that isolates fast, preserves evidence, and brings the device back clean.

The runbook is built around the sequence of actions that actually contains an incident correctly. When an endpoint is compromised you isolate it via EDR rather than powering it off, because network isolation cuts the attacker's reach while keeping the device reachable for investigation; powering off destroys volatile evidence and ends your visibility. You revoke the user's access, capture EDR telemetry, and only then eradicate, and for anything beyond trivial adware, especially ransomware or unknown persistence, you reimage rather than clean, because cleaning leaves the risk that something was missed. Recovery relies on escrowed encryption recovery keys and a known-good rebuild, and the lessons-learned phase feeds improvements back into preparation.

Its core insight is that the first ten minutes decide the outcome. Isolate the endpoint, revoke the user's access, and preserve evidence before you wipe, and have isolation tested, recovery keys escrowed, and roles assigned in advance, because improvising the basics mid-incident is exactly what turns one infected laptop into a fleet-wide breach. The runbook also marks the decision points that are easy to get wrong under pressure: when to involve legal or notify regulators (the moment regulated data may have been accessed or exfiltrated), and the wipe-versus-preserve ordering that determines whether you keep the evidence you will later need.

What it's used for

Security and IT teams use an endpoint incident runbook to respond to a compromise calmly and correctly, with the right action at each phase already decided. It supports a focused set of jobs:

✓ Containing a compromised endpoint by isolating it via EDR rather than powering it off, cutting the attacker's network reach while keeping the device reachable for investigation.
✓ Revoking the affected user's access immediately, so a compromised session or stolen credential cannot be used to pivot deeper while the device is being handled.
✓ Preserving evidence before eradication, capturing EDR telemetry and forensic data first, so you can understand the scope and root cause rather than destroying the trail by wiping early.
✓ Eradicating the threat by reimaging rather than cleaning for anything beyond trivial adware, especially ransomware or unknown persistence, so nothing is silently left behind.
✓ Recovering the device cleanly using escrowed encryption recovery keys and a known-good rebuild, restoring the user without reintroducing the compromise.
✓ Making the legal and regulatory call at the right moment, involving legal and considering breach notification as soon as personal or regulated data may have been accessed or exfiltrated.
✓ Feeding lessons learned back into preparation, hardening, isolation testing, key escrow, and role assignment, so the next incident is contained faster than the last.

Who uses it

Incident response is a coordinated effort across security, IT, leadership, and legal, and the runbook assigns each its part so nobody is figuring out their role mid-crisis:

Incident Responders / SecOpsThey execute the containment and eradication, isolate via EDR, capture telemetry, decide clean-versus-reimage, and drive the device back to a clean, trusted state.

Endpoint / MDM AdministratorsThey run the MDM-side actions, remote lock or wipe a stolen device, push the reimage, and restore the device using escrowed recovery keys.

Identity / IAM teamsThey revoke the affected user's access fast, the single most important early step to stop a compromised session or credential from spreading.

CISO / Incident CommanderThey own the overall response, make the escalation and notification calls, and ensure roles, isolation, and key escrow were tested before the incident, not during it.

Legal / Privacy / ComplianceThey are engaged the moment regulated data may be involved, to assess breach-notification obligations and regulatory timelines that the runbook flags as a decision point.

Help Desk / IT OperationsThey are often first to receive the report of a lost laptop or odd behavior, and the runbook gives them the immediate escalation and isolation steps to take before responders arrive.

Context & good to know

Endpoint incidents are not a question of if but when, and the gap between organizations that weather them and those that are devastated is almost entirely a matter of preparation. The runbook codifies the response so the right actions happen automatically rather than being debated while an attacker moves. This matters because the instincts people reach for under pressure are frequently the wrong ones: the urge to power off a ransomware-hit machine destroys the evidence and the forensic trail; the urge to immediately wipe and move on skips the containment and evidence steps that determine whether you actually understand and stop the spread.

The clean-versus-reimage decision is one the runbook is deliberately firm about, because it is where well-meaning teams take on hidden risk. For anything beyond trivial adware, cleaning a machine, removing the malware you can see, leaves open the possibility that persistence mechanisms, secondary payloads, or backdoors remain. Reimaging from a known-good build is the only way to be confident the device is genuinely clean, and it depends on having escrowed recovery keys so the encrypted device can be rebuilt. This is why preparation, key escrow, tested isolation, assigned roles, is treated as the first phase: the quality of your recovery is decided long before the incident starts.

Within the endpoint program, the incident runbook is the reactive counterpart to the preventive controls of hardening and patching, and it draws directly on the same infrastructure. EDR provides the isolation mechanism and the telemetry; escrowed encryption keys, set up during onboarding and tracked in the asset inventory, make clean recovery possible; conditional access and identity make rapid access revocation possible. The runbook also intersects with regulatory obligation in a way the others do not, marking the moment legal must be engaged because regulated data may have been exfiltrated. Tested in advance and rehearsed, it converts the chaos of a live compromise into a sequence the team can execute, which is the difference between one infected laptop and a fleet-wide breach.

✓ Independent · vendors can't pay to rank

Built on verified data, not vendor spin

Every Spotsaas resource draws on the Spotsaas Score — a blend of verified review ratings, review volume, and feature depth across 13 endpoint management software tools. Refreshed regularly; data as of June 2026.

FAQ

Questions, answered

What is an endpoint security incident runbook?

It is a first-responder playbook for when an endpoint is compromised by malware, ransomware, theft, or a real EDR alert. It walks the six incident-response phases, preparation, detection, containment, eradication, recovery, lessons learned, with the specific UEM, MDM, and EDR actions for each. Its purpose is to replace improvisation during a crisis with a pre-decided sequence that isolates fast, preserves evidence, and restores the device clean.

Should I wipe a compromised device right away?

No, not before you contain and preserve evidence. Network-isolate the device first, capture the EDR telemetry, and understand the scope, then eradicate. Wiping immediately destroys the forensic trail you need to know what happened, how far it spread, and whether data was taken. The runbook orders the steps, contain, preserve, then eradicate, precisely so you do not lose the evidence by acting too fast.

Should I isolate or power off a compromised endpoint?

Isolate via EDR; do not power off. Network isolation cuts the attacker's reach while keeping the device running and reachable for investigation. Powering off destroys volatile evidence (memory-resident artifacts) and ends your visibility into what is happening. EDR isolation gives you containment and forensics at the same time, which is why the runbook calls for isolation rather than shutdown.

Should I clean the malware or reimage the device?

For anything beyond trivial adware, especially ransomware or unknown persistence, reimage. Cleaning removes the malware you can see but leaves the risk that persistence mechanisms, secondary payloads, or backdoors remain hidden. Reimaging from a known-good build is the only way to be confident the device is genuinely clean. This is why escrowed recovery keys matter, they make a confident rebuild of an encrypted device possible.

When should I involve legal or notify regulators?

The moment personal or regulated data may have been accessed or exfiltrated. Breach-notification laws carry specific timelines and obligations, so legal must assess the situation early, not after the technical cleanup is done. The runbook flags this as an explicit decision point because the regulatory clock can start before the incident is fully understood, and missing a notification deadline compounds the original harm.

What are the six phases of incident response?

Preparation (getting isolation, key escrow, and roles ready in advance), detection (recognizing the incident), containment (isolating the endpoint and revoking access), eradication (removing the threat, usually by reimaging), recovery (restoring the device clean using escrowed keys), and lessons learned (feeding improvements back into preparation). The runbook gives concrete endpoint actions for each phase so the response is structured rather than improvised.

Why are the first ten minutes so important?

Because the early actions decide the outcome. Isolating the endpoint, revoking the user's access, and preserving evidence in the first minutes contains the spread and protects the forensic trail. Improvising these basics mid-incident, hunting for the isolation button, discovering recovery keys were never escrowed, realizing no one owns the response, is exactly what turns one infected laptop into a fleet-wide breach. Speed on the fundamentals comes from preparation.

How does EDR support incident response?

EDR is central to several phases: it detects the threat, provides the network isolation that contains a compromised endpoint without powering it off, and captures the telemetry you preserve as evidence before eradication. Because EDR keeps the device reachable while isolated, responders can investigate and respond at the same time. A healthy, reporting EDR is therefore a prerequisite for the runbook's containment and forensics steps to work.

What preparation does the runbook require before an incident?

Tested isolation (confirm you can actually isolate a device via EDR), escrowed encryption recovery keys (so a clean reimage of an encrypted device is possible), and assigned roles (so everyone knows their part). Preparation is the first phase precisely because the quality of your containment and recovery is determined before the incident starts. Rehearsing the response is what makes the live execution fast and correct.

What is the difference between this runbook and preventive controls like hardening?

Hardening and patching are preventive, they reduce the chance and impact of a compromise. The incident runbook is reactive, it governs what you do once a compromise has happened anyway. They share infrastructure: EDR, escrowed keys, and conditional access serve both. A mature endpoint program runs both, strong prevention to lower the incident rate, and a rehearsed runbook so the incidents that do occur are contained quickly.

Keep exploring