5.4 Map elements to these steps of analysis based on the NIST.SP800-61
📘Cisco Certified CyberOps Associate (200-201 CBROPS)
What is Post-Incident Analysis?
Post-incident analysis is the process of reviewing and learning from a security incident after it has been contained and resolved. The main goal is to improve an organization’s defenses, response processes, and security awareness.
Think of it as a retrospective: once an incident is over, the team reflects on what happened, what worked, what didn’t, and what can be done better next time.
Why is it Important?
- Prevents future incidents – by understanding the attack methods and weaknesses exploited.
- Improves incident response (IR) process – so your team reacts faster and more efficiently next time.
- Enhances security policies – ensuring rules and controls are updated to protect systems better.
- Supports compliance – many regulations require documenting and learning from incidents.
Key Steps in Post-Incident Analysis (Lessons Learned)
According to NIST SP 800-61, the steps are:
1. Document the Incident
- Record all facts about the incident:
- What happened?
- When did it start and end?
- Which systems were affected?
- Who discovered it?
- How was it contained and eradicated?
Example in IT:
A server was infected with ransomware. The team documents which server, which files were encrypted, how long it was down, and what recovery steps were taken.
2. Conduct a Post-Incident Meeting
- Bring together all team members involved in the incident response:
- Security analysts
- System administrators
- Network engineers
- Discuss:
- What went well?
- What went wrong?
- What tools and techniques were effective?
- Where were the gaps?
Tip for exam: The meeting is often called a “lessons learned review”.
3. Analyze the Root Cause
- Find why the incident happened to prevent it in the future.
- Look beyond the immediate problem to the underlying weakness.
Example in IT:
- Ransomware entered because a user clicked a phishing email link.
- Root cause: no multi-factor authentication and insufficient email filtering.
4. Identify Improvements
- After analyzing, create an action plan to improve security and response.
- Typical improvements:
- Update firewall rules or intrusion detection systems.
- Patch vulnerable systems.
- Train employees on phishing awareness.
- Improve incident response documentation and workflows.
Example in IT:
The team might implement endpoint protection with anti-ransomware capabilities or improve backup strategies to reduce downtime.
5. Update Policies, Procedures, and Documentation
- All lessons learned should be formalized:
- Update incident response playbooks.
- Modify security policies if gaps are found.
- Record lessons in a knowledge base for future reference.
Example in IT:
If a server configuration allowed excessive user privileges, update access control policies and document new best practices.
6. Share Lessons Learned (Optional but Recommended)
- Share anonymized findings with other teams or departments to raise awareness.
- Helps prevent similar incidents in other areas of the organization.
Example in IT:
Security team shares a phishing email template that bypassed spam filters with all employees so they recognize it in the future.
Best Practices for Post-Incident Analysis
- Timely review – conduct the analysis soon after the incident while details are fresh.
- Objective discussion – focus on learning, not blaming.
- Track action items – assign responsibility for each improvement and verify completion.
- Use metrics – track incident frequency, response time, and system downtime to measure improvement.
Summary Table for Exam
| Step | Description | IT Example |
|---|---|---|
| Document Incident | Record details of the incident | Server infected, files encrypted |
| Post-Incident Meeting | Discuss what worked, what didn’t | Security and IT teams review ransomware attack |
| Root Cause Analysis | Find underlying weakness | User clicked phishing link; missing MFA |
| Identify Improvements | Plan fixes to prevent recurrence | Implement anti-ransomware, patch systems |
| Update Policies & Documentation | Update playbooks, policies, knowledge base | Change access control policy, add playbook step |
| Share Lessons Learned | Educate other teams | Send phishing example and awareness tips to all staff |
Key Exam Tips
- NIST SP 800-61 calls this step “Lessons Learned”.
- Focus on improving processes, policies, and awareness.
- Remember the difference between containment/eradication (active incident response) vs post-incident analysis (review and learning).
- Use IT examples like servers, networks, malware, phishing, and backup systems—not non-IT analogies.
