How to plan and execute incident response using NIST SP 800-61 Rev. 3 and ISO/IEC 27035: roles, playbooks, containment, eradication, recovery and improvement.
Effective incident response rests on two things decided before any attack: a plan that assigns roles, priorities and communication channels, and a team that has practiced executing it. During an incident, the goal is to detect quickly, contain the damage, eradicate the cause, restore services safely and learn from what happened. Current references such as NIST SP 800-61 Revision 3 and ISO/IEC 27035 place this work inside overall cybersecurity risk management rather than treating it as an isolated technical task.
For more than a decade, many teams worked from NIST SP 800-61 Revision 2, with its four-phase life cycle: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. In April 2025, NIST published Revision 3, which supersedes Revision 2. It is written as a community profile of the Cybersecurity Framework (CSF) 2.0 and connects incident response to all six CSF functions:
The practical message is that response quality depends on decisions made long before the alert, and that lessons learned must feed back into every function, not only into the SOC.
ISO/IEC 27035 offers a comparable structure. Part 1 (2023 edition) describes the principles and process, organized around planning and preparation, detection and reporting, assessment and decision, response, and lessons learned. Part 2 (2023 edition) gives guidelines to plan and prepare. Organizations certified or working toward ISO/IEC 27001 often use ISO/IEC 27035 to structure the incident management controls of their ISMS.
A useful plan is short enough to be read under pressure and precise enough to guide decisions. It should define at least:
The plan is supported by playbooks for frequent scenarios such as ransomware, business email compromise, compromised accounts or exploitation of an exposed server. CISA's Cybersecurity Incident and Vulnerability Response Playbooks, cited in SP 800-61r3, are a useful model for the level of detail expected.
A plan cannot be executed without visibility. Preparation covers an up-to-date asset inventory, centralized and time-synchronized logs with sufficient retention, endpoint detection and response on critical systems, and offline or immutable backups that have actually been restored in a test. Administrative accounts used for response should be protected by strong authentication and should not depend on the systems likely to be compromised.
People matter as much as tools. Contact lists must be current, on-call arrangements agreed, and legal or regulatory notification deadlines known in advance, since they vary by sector and jurisdiction.
When an alert arrives, the first task is triage: confirm whether it is a true incident, estimate its scope and assign a severity. Document every action with a timestamp from the start; the incident log becomes essential for later analysis and for any legal follow-up.
Containment aims to stop the spread without destroying evidence. Typical actions include isolating hosts through the EDR, disabling or resetting compromised accounts, blocking indicators on firewalls and proxies, and segmenting affected network zones. Short-term containment buys time; longer-term containment may involve rebuilding systems in a clean environment.
Eradication removes the root cause: malware, persistence mechanisms, backdoor accounts, and the vulnerability or misconfiguration that allowed initial access. Patching alone is not enough if the attacker already has a foothold, so look for signs of compromise before declaring a system clean.
Recovery restores services progressively, starting with the most critical, and monitors them closely for signs of reinfection. Recovery decisions should involve business owners, since the order of restoration is a business choice as much as a technical one.
Once recovery is complete, hold a structured review with all parties involved. Focus on facts and decisions, not on blame: what was detected and when, what worked, what slowed the team down, and which controls would have prevented or shortened the incident. Each finding should become a tracked action with an owner and a deadline. Regular tabletop exercises, based on realistic scenarios, test the plan between real incidents and keep the team familiar with it.
Incident response requires both management and technical skills. Managers and ISMS owners can build a formal incident management capability with the PECB ISO/IEC 27035 Lead Incident Manager course, delivered by Securevalley Training as a PECB Authorized Silver Partner. Technical responders can follow the EC-Council Certified Incident Handler (E|CIH) course, and investigators who need to collect and analyze evidence can complete it with CHFI v11.
Incident response is judged in a few hours but prepared over months. A clear plan, tested playbooks, reliable visibility and a habit of learning from every incident make the difference between a controlled event and a crisis. Aligning this work with NIST SP 800-61r3 or ISO/IEC 27035 gives it a structure that management, auditors and technical teams can share.