During a post-incident review, participants begin blaming the engineer who misconfigured the firewall rule that the attacker exploited. What should the security manager do?
Select an answer to reveal the explanation.
Short Explanation
If one typo can sink the ship, the problem isn't just the person who made the typo; it's that nobody double-checks the hull. A blameless review asks why the process let the mistake through. Start pointing fingers and people stop telling you the truth.
Full Explanation
Post-incident reviews are most effective when they are blameless: they treat human error as a symptom of conditions in processes, tools and controls rather than the root cause. A misconfiguration that leads to compromise raises questions such as why change review did not catch it, whether configuration standards and automated checks existed, and why monitoring did not detect the exposure sooner. Refocusing the review on those gaps produces corrective actions that reduce the chance of any engineer repeating the error, and it keeps participants willing to share information openly. Recording the engineer's name to establish accountability shifts the report toward blame, discourages candour in future reviews and implies that replacing a person will fix a process weakness. Ending the review and referring the matter for discipline abandons the improvement purpose of the review and signals to staff that reporting mistakes is dangerous. Letting the blame continue misstates the review's purpose and generates conflict rather than learning. Exam caveat: blameless does not mean ignoring deliberate misconduct or policy violations, which are handled through separate HR and legal processes. Operational check: confirm the review output lists process and control improvements with owners, rather than individuals at fault.