5.4Elements of incident response

When an incident actually strikes, the strong organization is one that can act along documents and procedures decided in advance, not by improvisation on the spot. This section covers the differing roles of three document elements—policy (stating the stance), plan (defining preparation and action), and procedure (showing the concrete work)—and the stages and order of the widely referenced NIST SP 800-61 incident-response lifecycle: preparation -> detection/analysis -> containment/eradication/recovery -> post-incident (lessons learned). Getting the order right is this section's biggest aim.

5.4.1The differing roles of policy, plan, and procedure

• Policy is the document stating the organization's high-level intent: "what and why we protect," "what counts as an incident," and "who is responsible." It does not spell out individual methods but sets the overall direction and principles, serving as a management-approved foundation.
• Plan is the document that, following the policy, defines how to prepare, who plays what role, and in what flow to act—the contact structure, role assignments, escalation paths, and needed resources. It is the blueprint for how the organization moves.
• Procedure is the guide that breaks the plan down to concrete task level—the detailed steps the field actually performs, like "when this alert fires, run this command and check in this order." The relationship descends from abstract to concrete: policy -> plan -> procedure.

5.4.2The NIST SP 800-61 lifecycle

• (1) Preparation—advance readiness: setting up the team, tools, procedures, and drills, and preparing log collection and contact lists. (2) Detection and Analysis—noticing an anomaly and determining whether it is truly an incident and its scope and severity. First "notice and assess."
• (3) Containment, Eradication and Recovery—stopping the spread (containment), removing the cause such as malware (eradication), and restoring normal state (recovery). It is important that this comes after detection/analysis—do not contain blindly before assessing.
• (4) Post-Incident Activity (lessons learned)—reviewing the response and compiling "what went well and what to improve" as lessons, feeding them back into preparation. The improvements here strengthen the next preparation. The whole cycle runs preparation -> detection/analysis -> containment/eradication/recovery -> post-incident, with the lessons circulating.

One morning, monitoring reports that "one server is suspected of malware infection." What if a flustered responder, thinking "just stop the infection," immediately cuts that server off the network, wipes it, and rushes all the way to recovery? It looks speedy, but it is a risky response that skips the order of the NIST SP 800-61 lifecycle—because detection/analysis is not yet done. Before assessing whether it is truly an incident, whether only one server is infected, and by what path they got in, they jumped to containment, eradication, and recovery. Wiping only one server without confirming the scope may leave the infection already spread to others, or invite reinfection if the entry point is not closed. The correct flow: first move along the team and procedures readied in (1) preparation; in (2) detection/analysis assess "is it truly an incident, and what are the scope and severity"; based on that judgment perform (3) containment/eradication/recovery—stop the spread, remove the cause, restore normal state; and finally in (4) post-incident (lessons learned) reflect on "why the first response nearly skipped scope confirmation," improve the procedure, and feed it into the next preparation. The lesson: incident response is not about spirit or speed but about acting along a decided order (preparation -> detection/analysis -> containment/eradication/recovery -> post-incident), and especially the sense of order—"do not contain before assessing" and "when done, carry the lessons forward"—is what separates minimizing damage and preventing recurrence.

5.4.3Section summary

• Policy (stance—what/why) -> plan (blueprint for preparation and action) -> procedure (detailed field steps): roles split from abstract to concrete
• The NIST SP 800-61 lifecycle runs preparation -> detection/analysis -> containment/eradication/recovery -> post-incident (lessons learned)—do not reorder it
• The sense of order—do not contain before assessing, and circulate post-incident lessons into the next preparation—separates minimizing damage and preventing recurrence