1. Purpose
A Post-Incident Review (PIR) is a structured review conducted after a security incident has been contained, investigated, and recovered from.
The purpose is to determine:
- What happened
- Why it happened
- What worked well
- What did not work as expected
- Whether the incident response was effective
- Whether security controls operated as intended
- What risks remain
- What corrective and preventive actions are required
- What should be improved before the next incident
The objective is learning and improvement, not assigning blame.
2. When to Conduct a Post-Incident Review
A PIR should be conducted after:
- SEV-1 or SEV-2 incidents
- Significant data breaches
- Cloud compromises
- Account compromises
- Ransomware or malware incidents
- Major phishing or business email compromise
- Production security incidents
- Supplier or third-party security incidents
- Incidents affecting customers
- Incidents involving personal or regulated information
- Incidents that expose a significant control weakness
- Repeated incidents of the same type
For lower-severity incidents, the organization may use a lightweight review.
3. Post-Incident Review Information
| Field | Details |
|---|---|
| Incident ID | |
| Incident Title | |
| Incident Type | |
| Severity | |
| Date Detected | |
| Date Contained | |
| Date Recovered | |
| Date Closed | |
| Review Date | |
| Incident Commander | |
| Security Lead | |
| Business Owner | |
| Review Participants | |
| Customer Impact | Yes / No |
| Personal Data Involved | Yes / No / Unknown |
| Supplier Involved | Yes / No |
| Regulatory/Contractual Impact | Yes / No / Unknown |
4. Incident Summary
Provide a factual summary of the incident.
Include:
- What happened
- How it was detected
- Affected systems
- Affected information
- Affected users/customers
- Initial impact
- Final confirmed impact
- How the incident was contained
- How recovery was completed
Example
A developer account was compromised following a phishing attack. The attacker authenticated to the company’s cloud environment and created an unauthorized IAM role. The security team detected the activity through cloud monitoring, disabled the compromised credentials, investigated CloudTrail activity, reviewed access to production resources, rotated affected secrets, and restored the affected configuration.
5. What Happened?
Document the incident based on verified evidence.
Questions
- What was the initial security event?
- What was the initial attack vector?
- Which account, system, application, supplier, or infrastructure component was involved?
- What actions did the attacker or unauthorized party perform?
- What information or systems were accessed?
- Was privilege escalation observed?
- Was persistence established?
- Was lateral movement identified?
- Was data accessed, modified, deleted, or exfiltrated?
- When was the activity detected?
- When was the incident contained?
Separate:
- Confirmed facts
- Reasonable conclusions
- Unknowns
- Assumptions
6. Incident Timeline Review
Review the timeline from the first suspicious activity through closure.
| Date/Time | Event | Evidence | Source | Confirmed? |
|---|---|---|---|---|
| Initial activity | ||||
| Detection | ||||
| Investigation started | ||||
| Escalation | ||||
| Containment | ||||
| Eradication | ||||
| Recovery | ||||
| Verification | ||||
| Closure |
Review whether there were any significant delays between:
Activity → Detection → Reporting → Validation → Escalation → Containment → Investigation → Recovery
7. Root Cause Review
Determine the underlying cause of the incident.
Consider:
Technical Root Cause
- Vulnerability
- Misconfiguration
- Excessive privilege
- Weak authentication
- Missing MFA
- Exposed credential
- Insecure application
- Unpatched system
- Cloud configuration weakness
- Logging/monitoring gap
- Supplier weakness
Human/Process Root Cause
- Phishing
- Lack of awareness
- Incorrect procedure
- Inadequate approval
- Weak access review
- Poor change management
- Incomplete onboarding/offboarding
- Inadequate supplier management
- Missing security review
Governance Root Cause
- Missing policy
- Unclear ownership
- Inadequate risk assessment
- Accepted risk without adequate controls
- Control not implemented
- Control implemented but ineffective
- Monitoring not performed
Root Cause Statement
Primary Root Cause:
Contributing Factors:
Underlying Control Weakness:
8. What Worked Well?
Identify controls and response activities that worked effectively.
Consider:
- Detection
- Monitoring
- Alerting
- Incident reporting
- Escalation
- Evidence preservation
- Access controls
- MFA
- Logging
- Backup
- Business continuity
- Communication
- Customer notification
- Supplier coordination
- Cloud security controls
- Incident response procedures
| Area | What Worked? | Evidence |
|---|---|---|
| Detection | ||
| Reporting | ||
| Escalation | ||
| Containment | ||
| Investigation | ||
| Communication | ||
| Recovery | ||
| Monitoring |
9. What Did Not Work Well?
Identify weaknesses without assigning blame.
Consider:
- Delayed detection
- Delayed reporting
- Unclear ownership
- Slow escalation
- Missing evidence
- Incomplete logs
- Excessive permissions
- Poor communication
- Unclear customer communication process
- Missing documentation
- Recovery difficulties
- Backup limitations
- Supplier delays
- Tool limitations
- Lack of trained personnel
| Area | Problem Observed | Impact | Improvement Required |
|---|---|---|---|
| Detection | |||
| Reporting | |||
| Escalation | |||
| Containment | |||
| Investigation | |||
| Communication | |||
| Recovery |
10. Security Control Effectiveness Review
Review the controls associated with the incident.
| Control Area | Control Expected | Worked? | Evidence | Improvement |
|---|---|---|---|---|
| IAM | Yes/No/Partial | |||
| MFA | ||||
| Privileged Access | ||||
| Logging | ||||
| Monitoring | ||||
| Vulnerability Management | ||||
| Endpoint Security | ||||
| Network Security | ||||
| Backup | ||||
| Incident Response | ||||
| Supplier Security | ||||
| Security Awareness | ||||
| Change Management |
A control should not automatically be considered effective merely because it exists in a policy. Review whether it operated effectively during the incident.
11. Detection Effectiveness
Evaluate how quickly the organization detected the incident.
Metrics
| Metric | Result |
|---|---|
| Time of Initial Malicious Activity | |
| Time Detected | |
| Time Reported | |
| Time Validated | |
| Time Escalated | |
| Time Contained | |
| Time Recovered | |
| Time Closed |
Key Measures
Time to Detect (TTD):
Detection Time − Initial Known Malicious Activity
Time to Respond (TTR):
Response/Containment Time − Detection Time
Total Incident Duration:
Closure Time − Initial Known Activity
Where the initial activity time is unknown, document the limitation rather than creating an unsupported estimate.
12. Response Effectiveness Review
Evaluate each phase.
| Phase | Effective? | Observations |
|---|---|---|
| Detection | ||
| Reporting | ||
| Validation | ||
| Classification | ||
| Escalation | ||
| Containment | ||
| Evidence Preservation | ||
| Investigation | ||
| Eradication | ||
| Recovery | ||
| Verification | ||
| Communication | ||
| Closure |
13. Communication Review
Review internal and external communications.
Consider:
- Was the incident reported quickly?
- Were the correct people notified?
- Was escalation timely?
- Were communications based on verified facts?
- Were sensitive details protected?
- Were customers informed when required?
- Were suppliers involved appropriately?
- Were legal/privacy requirements assessed?
- Was management kept informed?
Communication Findings
What worked:
What could improve:
Required action:
14. Customer and Data Impact Review
Determine whether the incident affected:
- Customer information
- Personal information
- Financial information
- Authentication information
- Confidential business information
- Source code
- Intellectual property
- Production systems
- Availability of customer services
Data Impact
| Question | Result |
|---|---|
| Was data accessed? | |
| Was data modified? | |
| Was data deleted? | |
| Was data exfiltrated? | |
| Was personal data involved? | |
| Was regulated data involved? | |
| Were customers affected? | |
| Was notification assessed? | |
| Was notification required? | |
| Was notification completed? |
15. Cloud / AWS Review
For AWS-based SaaS environments, review:
- IAM users and roles
- MFA
- Access keys
- CloudTrail
- CloudWatch
- GuardDuty
- Security Hub
- VPC Flow Logs
- WAF
- S3
- RDS
- ECS/EKS
- Lambda
- Secrets Manager
- KMS
- Security Groups
- Network ACLs
- CI/CD
- Infrastructure as Code
- Backup and recovery
- Logging configuration
Example
If a developer account was compromised:
Developer Identity → AWS Authentication → IAM Role → Privilege Change → Resource Access → Data Access → Containment → Credential Rotation → Recovery → Monitoring
The review should determine not only what the attacker did, but also why the attack was possible and why existing controls did or did not prevent or detect it.
16. Evidence Review
Confirm that investigation evidence was properly preserved.
| Evidence | Available? | Integrity Verified? | Location | Reviewed? |
|---|---|---|---|---|
| Authentication Logs | ||||
| Cloud Logs | ||||
| Application Logs | ||||
| Network Logs | ||||
| Endpoint Evidence | ||||
| Email Evidence | ||||
| Configuration Records | ||||
| Incident Communications | ||||
| Screenshots/Documents |
Document any evidence that could not be obtained and why.
17. Incident Response Capability Gaps
Identify gaps discovered during the incident.
People
- Lack of trained responders
- Lack of clear ownership
- Limited specialist availability
Process
- Missing procedure
- Outdated playbook
- Unclear escalation
- Inadequate communication process
Technology
- Missing monitoring
- Insufficient logging
- Limited detection capability
- Inadequate backup
- Tool integration gaps
Governance
- Unclear risk ownership
- Incomplete policy
- Weak control oversight
- Inadequate management review
18. Corrective and Preventive Actions
Convert findings into measurable actions.
| Action ID | Finding | Root Cause | Corrective Action | Owner | Priority | Target Date | Evidence | Status |
|---|---|---|---|---|---|---|---|---|
| CA-001 | High | |||||||
| CA-002 | Medium |
Actions should be:
- Specific
- Risk-based
- Assigned to an owner
- Given a target date
- Supported by implementation evidence
- Independently verified where appropriate
- Closed only after effectiveness is assessed
19. Risk Reassessment
Determine whether the incident changes the organization’s information-security risk.
| Risk | Before Incident | After Incident | Treatment Required | Owner |
|---|---|---|---|---|
Consider:
- New threats
- New vulnerabilities
- Changed likelihood
- Changed impact
- New attack paths
- Changed business exposure
- Customer requirements
- Regulatory obligations
- Supplier dependencies
- Residual risk
Where appropriate, update the organization’s Risk Register and Statement of Applicability-related control considerations.
20. Lessons Learned
Document the most important lessons.
Lesson 1
Observation:
Lesson:
Action:
Lesson 2
Observation:
Lesson:
Action:
Lesson 3
Observation:
Lesson:
Action:
21. Incident Response Playbook Review
Determine whether existing playbooks remain adequate.
| Playbook | Current? | Update Required? | Owner |
|---|---|---|---|
| Account Compromise | |||
| Phishing | |||
| Ransomware | |||
| Data Breach | |||
| Cloud Compromise | |||
| Malware | |||
| Supplier Incident |
If the incident exposed a scenario not covered by an existing playbook, create or update the relevant playbook.
22. Training and Awareness Review
Determine whether additional training is required.
Possible areas:
- Phishing awareness
- Incident reporting
- Secure password practices
- MFA
- Privileged access
- Cloud security
- Data handling
- Secure development
- Supplier security
- Incident response roles
Training Required:
Target Audience:
Completion Date:
Evidence:
23. Management Review
Management should review significant findings and actions.
Management Questions
- Was the incident response adequate?
- Was customer/business impact appropriately assessed?
- Were notification obligations assessed?
- Were security controls effective?
- Are additional resources required?
- Has the risk profile changed?
- Are corrective actions adequately prioritized?
- Are residual risks acceptable?
- Are policy or procedure changes required?
- Should additional testing or tabletop exercises be conducted?
Management Decision
24. Post-Incident Review Findings
Summarize the final findings.
| Finding ID | Finding | Risk | Action Required | Owner | Due Date |
|---|---|---|---|---|---|
| PIR-001 | |||||
| PIR-002 |
Classify findings where appropriate:
- Improvement Opportunity
- Control Weakness
- Corrective Action
- Risk Treatment
- Policy/Procedure Update
- Training Requirement
- Technology Improvement
- Supplier Action
25. Review Closure Criteria
The Post-Incident Review can be closed when:
- Incident investigation is complete
- Timeline has been reviewed
- Root cause has been documented
- Impact has been assessed
- Evidence has been preserved
- Security controls have been reviewed
- Response effectiveness has been assessed
- Lessons learned have been documented
- Corrective actions have owners
- Target dates have been established
- Risk has been reassessed
- Required notifications have been assessed/completed
- Management review has occurred where required
- Required playbooks/procedures have been updated
- Residual risk has been documented
- PIR approval has been recorded
26. Approval
| Role | Name | Decision | Date | Signature/Approval |
|---|---|---|---|---|
| Incident Commander | ||||
| Security Lead | ||||
| Business Owner | ||||
| Management |
Review Status: Open / Completed / Awaiting Actions / Closed
27. Recommended Evidence
Maintain evidence supporting the review, such as:
- Incident Report
- Incident Register entry
- Incident Timeline
- Investigation Report
- Evidence Register
- Logs
- Screenshots
- Communication records
- Customer notifications
- Regulatory assessments
- Root Cause Analysis
- Corrective Action Tracker
- Risk Register updates
- Updated procedures
- Updated playbooks
- Training records
- Tabletop exercise results
- Management review records
28. Relationship With Other Incident Records
The Post-Incident Review should not operate as an isolated document.
Security Event → Incident → Investigation → Evidence → Timeline → Containment → Recovery → Closure → Post-Incident Review → Corrective Actions → Risk Reassessment → Management Review → Continual Improvement
Related records may include:
- Security Event Register
- Incident Register
- Incident Reporting Form
- Incident Severity Matrix
- Incident Escalation Matrix
- Incident Investigation Template
- Incident Timeline
- Evidence Preservation Procedure
- Incident Closure Report
- Corrective Action Tracker
- Risk Register
- Management Review
- Incident Response Tabletop Exercise
29. ISO 27001 Alignment
A Post-Incident Review supports the organization’s Information Security Management System by providing evidence that security incidents are not simply closed after recovery.
The review helps demonstrate:
- Incident response effectiveness
- Evidence-based investigation
- Root-cause analysis
- Corrective action
- Risk reassessment
- Control effectiveness review
- Continual improvement
- Management oversight
The specific format of a Post-Incident Review is an organizational implementation choice. Its content should be proportionate to the organization’s risks, incident severity, contractual obligations, and regulatory requirements.
30. Startup-Friendly Implementation
A startup does not need a lengthy report for every minor incident.
For a significant incident, a practical PIR can be maintained as a 2–5 page review plus linked evidence.
Minimum fields:
Incident ID → What Happened → Timeline → Impact → Root Cause → What Worked → What Failed → Control Review → Lessons Learned → Corrective Actions → Risk Reassessment → Management Decision
For an AWS SaaS startup, the PIR can link directly to:
- AWS CloudTrail evidence
- IAM investigation
- Security alerts
- Application logs
- Incident timeline
- Corrective Action Tracker
- Risk Register
This keeps the review evidence-based without creating unnecessary documentation.
31. Final Post-Incident Audit Trail
Incident Detected → Incident Reported → Incident Classified → Response Activated → Incident Contained → Evidence Preserved → Investigation Completed → Impact Assessed → Root Cause Identified → Recovery Verified → Incident Closed → Post-Incident Review Conducted → Control Effectiveness Reviewed → Lessons Learned → Corrective Actions Assigned → Risk Reassessed → Management Review → Improvements Implemented → Effectiveness Verified → PIR Closed
Final Principle
Don’t Just Close the Incident — Learn From It.
Investigate the Facts + Understand the Root Cause + Review Control Effectiveness + Assess the Impact + Capture Lessons + Assign Corrective Actions + Reassess Risk + Verify Improvements + Document Management Decisions.