Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Review your organization’s cybersecurity after a cyberattack by preserving evidence, reconstructing the incident, examining decisions and controls, validating eradication and recovery, and converting every supported finding into owned, tested corrective work. Treat the review as a risk-management activity involving leadership, security, IT, legal, communications, continuity, and other affected functions—not as an IT-only blame exercise.
Use qualified incident responders and applicable counsel for incident-specific forensic, notification, and legal decisions. A review can reduce the chance and impact of another attack, but no retrospective or exercise can guarantee prevention.
What a post-attack cybersecurity review should accomplish
A useful review answers four practical questions:
- What happened, which services and information were affected, and what remains uncertain?
- Which preventive, detective, response, communication, and recovery measures worked, failed, or were unavailable?
- Which decisions reduced harm, and which delays or assumptions increased it?
- What specific changes will be funded, owned, completed, and tested?
NIST’s current incident-response publication is SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, published April 3, 2025. It supersedes Rev. 2 from 2012. NIST describes incident response as part of broader cybersecurity risk management, with preparation, detection, response, recovery, and continuing improvement connected rather than treated as separate projects.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesNIST’s project guidance captures the operating principle: “The lessons learned from performing all activities in all Functions are fed into Improvement, and those lessons are analyzed, prioritized, and used to inform all of the Functions.” The review therefore should update everyday risk management, not merely close an incident ticket.
#1 Best Overall
1. Set scope and preserve records before changing anything
Write a short scope statement before interviews begin. Define the incident period, affected business services, systems, accounts, facilities, cloud tenants, suppliers, and data using verified information. Mark assumptions and unknowns explicitly. A scope that says “the network was compromised” is less useful than one that identifies the customer portal, identity provider, two administrator accounts, and the dates currently supported by evidence.
Coordinate with the incident commander, qualified responders, and counsel before reimaging devices, deleting accounts, rotating logs, or making other changes that could destroy evidence or interrupt an investigation. The review team may analyze records, but it should not perform forensic collection beyond its competence.
Evidence to preserve or request
- System images and memory captures collected by qualified responders when appropriate.
- Endpoint, email, identity, firewall, VPN, cloud, application, backup, and network logs.
- Malware samples, hashes, indicators of compromise, detection rules, and alert history.
- Ticketing records, help-desk reports, responder notes, chat messages, meeting minutes, and decision approvals.
- Identity-provider events, privileged-access records, authentication changes, and cloud audit trails.
- Backup catalogs, restore logs, recovery-point tests, and records showing when systems were reconnected.
Prioritize volatile or limited-retention sources. Record who supplied each item, when it was obtained, its time zone, and how it was stored. Keep an evidence register separate from the analytical report so later reviewers can distinguish original records from interpretations.
2. Reconstruct what happened without overstating certainty
Build one authoritative timeline and make it readable to both technical and nontechnical decision-makers. Normalize timestamps to a stated time zone while retaining the original timestamp. For every event, record the source, confidence, affected asset or account, action taken, owner, and consequence.
| Timeline field | What to record |
|---|---|
| Time and time zone | Original timestamp and normalized time used in the report |
| Event | Observed login, alert, file change, service outage, containment step, or decision |
| Source | Endpoint telemetry, identity log, network record, ticket, interview, or responder note |
| Confidence | Confirmed, probable, possible, or unresolved |
| Impact | Service, account, data, safety, financial, or regulatory consequence known at that time |
| Decision and owner | Who approved the action, what alternatives were considered, and why |
Compare prevention and detection sources rather than relying on the first alert. CISA’s joint #StopRansomware Guide recommends examining affected systems and organizational detection tools and logs to identify additional systems or earlier malicious activity. Look for the earliest credible access, privilege changes, persistence, lateral movement, data access or encryption, discovery by staff or tools, containment, eradication, and restoration.
Handle gaps and conflicting records
Do not turn an absence of logs into proof that an event did not occur. State when retention limits, clock drift, disabled telemetry, encrypted traffic, or a rebuilt system prevents a conclusion. If an interview conflicts with a log, preserve both accounts, identify the conflict, and assign a follow-up action. Separate root cause from contributing conditions: an exposed credential may be the initial access path, while weak multifactor enforcement, excessive privilege, and missing alerting explain why the intrusion expanded.
3. Review response decisions and coordination
Interview people who made or executed decisions, including the incident lead, system owners, service desk, executives, communications, legal, privacy, continuity, facilities, procurement, insurers, and relevant suppliers. Use a blameless format that asks what information was available at the time, what constraint applied, and what would make the desired action easier next time.
Questions for the response review
- Were incident roles, deputies, escalation thresholds, and decision authority clear?
- Could staff reach the response plan, contact lists, privileged accounts, and backup procedures if normal systems were unavailable?
- Were compromised hosts, accounts, tokens, and network segments isolated quickly enough, and did isolation create avoidable safety or business harm?
- Were critical services prioritized according to an approved business-impact analysis?
- Did leaders receive a shared picture of facts, uncertainty, business impact, and options?
- Were legal counsel, insurers, vendors, regulators, law enforcement, and other authorities engaged according to the plan and applicable requirements?
- Were internal and external statements accurate, coordinated, approved, and updated as facts changed?
- Did third parties know what evidence, access, notifications, and service-level decisions were required of them?
Evaluate communications as an operational control. Check whether a single source of truth existed, whether employees received safe instructions through an alternate channel, and whether public statements avoided speculation while meeting applicable duties. Notification obligations vary by jurisdiction, sector, affected information, contracts, and incident facts; consult counsel and the relevant regulators or authorities rather than applying a generic deadline.
4. Examine prevention and detection controls
Map each confirmed attack action to the control that should have prevented, limited, detected, or reported it. This turns a narrative into a testable control review.
| Attack activity | Controls to examine | Evidence of effectiveness |
|---|---|---|
| Initial access | Multifactor authentication, external exposure, email and web protections, vulnerability management, supplier access | Configuration records, exposure scans, patch history, blocked events, exception approvals |
| Privilege escalation | Privileged-access management, least privilege, administrator separation, credential rotation | Access reviews, authentication logs, role assignments, emergency-account use |
| Lateral movement | Network segmentation, workstation hardening, remote-service restrictions, endpoint controls | Firewall rules, endpoint detections, segmentation tests, remote-session records |
| Data theft or disruption | Data classification, egress monitoring, application controls, immutable or offline backups | Data-access logs, transfer alerts, backup-integrity and restore tests |
| Detection delay | Centralized logging, alert coverage, triage procedures, staffing and escalation | Retention settings, alert examples, mean-time records, missed-detection analysis |
For every control, ask whether it existed, was configured correctly, was monitored, generated an actionable signal, and had an owner able to respond. Record exceptions and compensating measures. A policy that requires quarterly access review is not evidence that a review occurred; attach the completed review and any unresolved findings.
5. Review eradication and recovery, especially ransomware recovery
Recovery is complete only when services are operating safely, access paths are addressed, monitoring is active, and the organization has evidence that restored systems are not immediately reinfected.
Eradication checks
- Identify and close the initial access path where possible, including exploited vulnerabilities, exposed services, stolen credentials, malicious tokens, or supplier connections.
- Reset or revoke affected credentials, sessions, keys, certificates, and service accounts according to responder and counsel guidance.
- Remove persistence and unauthorized tools, rebuild systems when integrity cannot be established, and validate security baselines before reconnection.
- Increase monitoring for related indicators and test that alerts reach a staffed escalation path.
Recovery checks
- Were critical services restored in an order approved by business owners and continuity leaders?
- Were backups offline or otherwise protected from attackers, encrypted where appropriate, and validated before use?
- Did the team test restoration, dependencies, application integrity, identity services, and data completeness rather than only confirming that a server booted?
- Were clean systems protected from reinfection during network reconnection?
- Were recovery decisions, failed restores, workarounds, and residual risks documented?
CISA’s ransomware guidance emphasizes restoring from offline, encrypted backups according to critical-service priorities and documenting lessons from recovery. Keep this advice framed for ransomware; other incidents may require different containment, evidence, or restoration choices.
6. Assess business impact and resilience
Measure impact in terms leaders can act on: unavailable services, delayed operations, affected customers, safety implications, data exposure, contractual consequences, manual-work hours, supplier dependency, and decisions that could not be made because information or authority was unavailable. Distinguish confirmed impact from estimated impact and state the measurement period.
Review continuity assumptions against what actually happened. Did alternate sites, manual procedures, emergency communications, backups, power, facilities, and supplier arrangements work together? Did a dependency—such as identity, DNS, endpoint management, or a cloud control plane—make otherwise healthy applications unusable? Update recovery priorities and minimum staffing based on observed dependencies, not only the original plan.
7. Convert findings into an accountable improvement plan
Do not finish with a list of observations. Create an action register in which every finding has evidence, a business consequence, a practical remedy, an accountable owner, a priority, a due date, and a validation method.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Field | Example entry |
|---|---|
| Finding and evidence | Two administrator accounts lacked multifactor authentication; identity records and approved exception list attached |
| Business impact | Compromise of one account could reach three production services |
| Corrective action | Enforce multifactor authentication, remove the exception, and create a monitored emergency-access process |
| Owner and priority | Identity engineering manager; high priority |
| Due date | Specific date agreed with the risk owner |
| Validation | Configuration export, access test, alert test, and independent review |
Prioritize rationally
Address first the changes that close the demonstrated access path, protect critical services, improve visibility, or reduce the consequence of another compromise. Consider exploitability, business criticality, exposure, dependency, implementation effort, and residual risk. If a fix cannot be completed by the target date, document an interim control and have the appropriate risk owner accept or reject the remaining exposure.
Update the right documents and capabilities
- Incident-response, crisis-management, communications, continuity, and disaster-recovery plans.
- Policies for identity, privileged access, logging, vulnerability handling, supplier access, data protection, and backups.
- Detection content, log retention, alert routing, on-call coverage, and escalation contacts.
- Asset inventories, service dependencies, recovery priorities, restoration runbooks, and alternate communications.
- Training for executives, service owners, help-desk staff, administrators, and communications teams.
NIST’s model treats improvement as information that feeds every cybersecurity function. Therefore, route findings to the owners of governance, protection, detection, response, and recovery capabilities rather than leaving them in a security-team spreadsheet.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.8. Exercise the changes and revisit open risk
Choose an exercise that tests the specific weakness found. A tabletop can test authority, escalation, communications, and prioritization. A technical recovery exercise can test restoration, identity recovery, segmentation, endpoint rebuilding, and monitoring. A combined exercise is appropriate when business decisions depend on technical sequencing.
Design an effective exercise
- Set objectives tied to completed corrective actions and define what evidence will count as success.
- Use a realistic scenario involving the affected services, dependencies, and decision-makers.
- Include senior leaders and the functions that must act during an incident, not only security specialists.
- Inject uncertainty, unavailable systems, supplier delays, conflicting reports, or communication outages.
- Record decisions, time to escalation, blocked procedures, workarounds, and unresolved questions.
- Assign new actions and schedule a retest.
A tabletop validates decision processes; it does not by itself prove that a technical backup restore, clean rebuild, or failover will work. Revisit the action register at regular risk-governance meetings and measure whether changes improved detection, containment, restoration, communication, or decision speed.
When to use an independent assessment
External help is useful when the incident involves disputed facts, specialized technology, limited internal capacity, independence requirements, or a need to demonstrate remediation to stakeholders. Select an assessor based on scope, relevant technical and sector expertise, independence, evidence-handling practices, deliverables, and fit with your systems and budget—not on a generic ranking.
Agree in writing on whether the work is forensic, control-focused, resilience-focused, legal-supporting, or exercise-based; who owns evidence; what access is permitted; how sensitive findings are protected; and what the final report will contain. CISA’s Cyber Resilience Review is an interview-based assessment that maps relative maturity across ten operational-resilience and cybersecurity domains. Check current eligibility and availability before relying on it. CISA also lists ransomware-readiness and scanning/testing resources that may complement, but not replace, incident-specific response work.
Quick Recap
Practical review checklist
- Scope: Incident period, affected services, systems, accounts, data, dependencies, and unknowns are documented.
- Evidence: Logs, images, memory captures, malware, indicators, notes, and backup records are preserved with handling records.
- Timeline: Events, decisions, sources, confidence, and impact are reconciled.
- Response: Roles, isolation, escalation, priorities, stakeholder engagement, and communications are evaluated.
- Controls: Prevention, detection, identity, segmentation, logging, supplier access, and backup protections are mapped to observed attack actions.
- Recovery: Access paths were addressed; credentials were handled; clean, protected backups were tested; reconnection avoided reinfection.
- Improvement: Findings have evidence, owners, priorities, dates, interim controls, and validation methods.
- Exercises: Changes are tested with the leaders and functions that must make decisions, then retested after gaps are closed.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
