Incident Response Checklist

Respond quickly without losing control of the evidence

A security incident can become significantly more damaging when decisions are made without a clear sequence. The first objective is not simply to switch systems off. It is to protect people and critical services, preserve evidence, understand the scope of the incident and make controlled containment decisions.

This checklist can be used for suspected ransomware, account compromise, malware, unauthorised access, cloud exposure, data-loss events, suspicious administrator activity and other cyber incidents. Adapt it to your organisation's legal, regulatory and operational requirements.

1. First 15 minutes — confirm, record and escalate

• Record the initial alert. Note the time, reporting person, affected user or system, alert source and what was first observed.
• Open an incident record. Give the incident a unique reference and start a chronological decision log.
• Confirm who is leading the response. Assign an incident lead and identify technical, management, legal, communications and business contacts as required.
• Preserve volatile information. Capture screenshots, alert details, process information, active connections and relevant console data before it disappears.
• Avoid unplanned changes. Do not delete files, wipe devices, reset everything or reboot critical systems until the likely impact on evidence is understood.

2. First hour — establish the scope

• Identify affected accounts, endpoints, servers, cloud services, applications, email systems, APIs and network segments.
• Determine whether the activity is still active and whether the attacker may have persistence or privileged access.
• Review authentication events, endpoint telemetry, security alerts, firewall or proxy logs, email events and cloud audit logs.
• Identify the earliest known suspicious event and build an initial timeline.
• Check for related indicators across other systems rather than treating the first affected device as an isolated problem.
• Classify the incident by severity, business impact, data sensitivity and operational urgency.

3. Contain the threat — but preserve evidence

4. Preserve the evidence

• Export relevant logs before retention periods or system changes remove them.
• Preserve suspicious files, email headers, URLs, hashes, IP addresses, domains and security-alert identifiers.
• Record who collected each item, when it was collected and where it is stored.
• Keep original evidence separate from working copies used for analysis.
• Where forensic imaging is required, use appropriately qualified personnel and a defensible evidence-handling process.

5. Understand what actually happened

Containment alone is not enough. The investigation should establish the likely entry point, attacker activity, systems reached, privileges obtained, data accessed or removed, persistence mechanisms and whether other environments remain exposed.

• Reconstruct the attack path from initial access to the latest confirmed activity.
• Separate confirmed facts from assumptions and unverified indicators.
• Identify exploited vulnerabilities, weak controls, stolen credentials or configuration failures.
• Search the wider environment for the same indicators and techniques.
• Document the evidence that supports each major conclusion.

6. Communications, legal and regulatory decisions

Use an agreed communication channel that is not dependent on systems that may be compromised. Keep leadership informed using confirmed facts, impact, decisions required and next actions rather than unverified technical speculation.

• Determine whether personal, confidential, regulated or commercially sensitive information may be affected.
• Escalate to legal, data-protection, insurance and regulatory contacts where required.
• Coordinate customer, employee, partner and public communications through authorised personnel.
• Do not make attribution claims until there is sufficient evidence.
• Record notification decisions and the reasons for them.

7. Eradication and recovery

• Remove malicious persistence, unauthorised accounts, malicious rules, compromised keys and known attacker tooling.
• Patch exploited vulnerabilities and correct the configuration weaknesses that enabled the incident.
• Reset or rotate credentials according to exposure and privilege, not as an uncontrolled blanket action.
• Restore systems from trusted sources and verify backups before reconnecting services.
• Increase monitoring during recovery and watch for recurrence, re-entry or previously missed persistence.
• Return services in a controlled order based on business priority and security confidence.

8. After the incident — convert lessons into prevention

Close the incident only after containment and recovery actions have been verified. A post-incident review should convert technical findings into specific improvements with owners and target dates.

• Finalise the incident timeline, root-cause assessment and confirmed impact.
• Record what worked, what delayed the response and what information was missing.
• Create prioritised remediation actions across identity, endpoints, network, cloud, email, vulnerability management and monitoring.
• Update playbooks, contact lists, logging, backup procedures and security controls.
• Brief leadership on residual risk and the investment or policy decisions that remain.

Common mistakes that make an incident worse

How SteelCortex can support the response

SteelCortex can help organisations organise incident evidence, reconstruct attack paths, identify related exposure, prioritise containment and remediation actions, and produce decision-ready investigation summaries. The objective is to move from fragmented alerts to a defensible understanding of what happened and what must be fixed next.