A phishing-driven account compromise has been eradicated and all systems are restored. Several weeks earlier a similar incident occurred. Which post-incident activity should the team perform to prevent another recurrence?
Select an answer to reveal the explanation.
Short Explanation
Fixing it twice and not asking why is how you end up fixing it a third time. Lessons learned plus root cause analysis digs past 'a user clicked a link' to why the click worked. Closing the ticket because things are back up is the trap - restored isn't the same as prevented.
Full Explanation
Post-incident activities turn an incident into improvement. A lessons-learned review brings responders and stakeholders together to examine what happened, what worked, and what did not, while root cause analysis looks beyond the immediate trigger, here a phishing click, to the underlying causes, such as missing phishing-resistant MFA, weak email filtering, or delayed detection. Because a similar incident recurred, identifying and fixing those causes is essential, and the results feed a post-incident report with assigned corrective actions. Closing the ticket simply because systems are restored treats recovery as the end of the process and guarantees the root cause remains. Running a new tabletop exercise without first documenting this incident skips the analysis that would make the exercise relevant; exercises should incorporate the findings, not precede them. Reimaging every server is a broad, disruptive action with no evidence-based justification; the incident was eradicated, and indiscriminate rebuilding does not address the conditions that let phishing succeed. Exam caveat: lessons-learned sessions should be blameless enough that people report candidly, or root causes stay hidden. Operational check: confirm each identified root cause has a corrective action with an owner and due date, and track those actions to completion in the post-incident report.