Recovery Validation, Forensics, and Post-Incident Review
Prove recovery and learn from the incident
The exam tests whether you can validate that restored services are trustworthy and capture lessons without destroying evidence. Recovery validation goes beyond systems being up. It confirms functional correctness, data integrity, security cleanliness, performance, and business acceptance. Forensics preserves evidence for legal, regulatory, insurance, and root-cause purposes. Post-incident review turns the timeline into corrective action.
Core rules
- Validation checklist: authentication and authorization, integrations, transaction processing, data reconciliation, file integrity, malware-free status, patching, logging, and monitoring. Obtain business sign-off.
- Reconcile data against known totals or control records. Check for gaps, duplicates, and corruption introduced during restore or replay.
- Security validation includes credential rotation, removal of attacker persistence, EDR coverage, and network segmentation before reconnection.
- Forensics follows order of volatility: memory, network state, running processes, then disk. Use write blockers, hash evidence, maintain chain of custody, and document every action.
- Post-incident review should be blameless and evidence-based: timeline, root cause, contributing factors, what worked, what failed, metrics, and owned corrective actions with dates.
- Update the BIA, risk register, playbooks, backup design, and test plan based on findings.
Worked example
An ERP system is restored after ransomware. The team confirms the application starts, then reconciles accounts payable balances, checks the transaction log for gaps, scans for malware, rotates service accounts, and has finance sign off on a sample of payments. Before rebuilding, forensics images the compromised server and captures memory. The post-incident review finds that the initial access was an unpatched VPN appliance and that backup restoration took six hours against a four-hour RTO. Both findings get owners and retest dates.
Traps
Do not declare recovery when only the login page works. Do not skip reconciliation or business acceptance. Do not reboot or rebuild before capturing volatile evidence. Do not break chain of custody. Do not turn the review into a blame session or close findings without verification.