While reviewing a draft incident response plan, the information security manager notes it contains detailed technical procedures for analyzing malware but does not say who decides to escalate or who communicates with stakeholders. What is the BEST recommendation?
Select an answer to reveal the explanation.
Short Explanation
A plan that tells you how to dissect malware but not who makes the call is like a fire drill with no one assigned to phone the fire department. The management pieces, roles, escalation and communication, are what make the plan work in a crisis. Adding more technical depth is the trap here.
Full Explanation
An incident response plan is primarily a management document. Its essential elements include defined roles and responsibilities, the criteria and authority for escalation, decision rights for actions with business impact, and processes for communicating with internal stakeholders, senior management, regulators, customers and other external parties. Detailed technical analysis steps are useful supporting material, but without the management elements nobody knows who can authorize containment that disrupts a business service or who speaks for the organization. Moving the technical steps into a runbook may be sensible document structure, but approving the plan without escalation and communication still leaves the critical gaps open. Approving now and deciding during the first real incident guarantees improvisation at the worst possible moment, under time pressure and with incomplete information. Adding more malware procedures deepens the technical content the plan already has and treats escalation as something to be avoided, when escalation of significant incidents is a required control. Exam caveat: communication processes should identify who may speak externally and require legal involvement where notification obligations may apply. Operational check: confirm the plan names an incident manager, escalation thresholds by severity, and a communication owner for each audience.