After a ransomware incident, your SOC completes a lessons learned review and identifies several corrective actions, including patching gaps and EDR policy changes. Which addition to the final report most directly makes follow-up accountable?
Select an answer to reveal the explanation.
Short Explanation
Think of a lessons learned report like a punch list after a job: if no one owns it and no date is set, it just sits there. You want each corrective action tied to a person and a deadline, because that's what turns review findings into real work. The trap is dressing up the report with timelines or technique IDs and forgetting accountability.
Full Explanation
The purpose of a lessons learned report in incident response is to convert observations into durable process improvement. When findings identify corrective actions, accountability requires a named owner and a due date for each action; without both, the item remains an observation rather than a tracked remediation task. This is distinct from documenting the incident chronology, enriching the report with adversary technique identifiers, or obtaining executive approval of severity. A root cause and timeline are essential for analysis and reporting, but they do not by themselves assign responsibility or create a deadline. MITRE ATT&CK technique IDs help correlate detection gaps and threat behavior, yet they do not establish who must fix the gap or when it must be completed. Management sign-off on severity classification supports accurate incident categorization and communication, but it does not convert corrective actions into owned, time-bound work items. Exam caveat: CompTIA often rewards the answer that creates measurable follow-up, not the answer that merely makes the report more complete. Operational check: In the final report, create an action table with finding, owner, due date, and verification evidence, then track closure in the ticketing system.