Initial Security Incident Questionnaire for Responders

When you take charge of a security incident, this cheat sheet gives you the questions to ask: verify the incident is real, set up communications and decision rights, scope it across systems and identities, review what the initial survey changed, and plan containment. It also lists the details to capture for the incident report.

This cheat sheet outlines the questions to ask when you take charge of a security incident, and the details to capture for the incident report. To print, use the one-page PDF version. You can also edit the Word version for your own needs.

If you’re a system administrator deciding whether a suspicious situation is a security incident, see the companion Security Incident Survey Cheat Sheet for Server Administrators. For DDoS incidents, a separate cheat sheet is available.

Verify the Incident

• What was observed, how was it detected, when, and by whom?
• What rules out a benign explanation, such as maintenance, a scan, or a new vendor tool?
• If an outsider reported the incident, do we own the resources they named, and do our observations match theirs?
• If we can’t yet confirm or rule out an incident, who’ll gather more information, and when will we reassess?
• Is data being destroyed, encrypted, or stolen right now? If so, contain first, then return here.

Organize the Response

• Where will we keep this incident’s case notes, and how often will we send status updates?
• Who is authorized to make business decisions about the affected operations?
• Which containment actions can the response team take on its own authority, and who’ll approve the other actions?
• How will the team communicate, assuming the attacker can read the systems under investigation?
• Who’ll interface with legal, executives, public relations, law enforcement, and the cyber insurer?

Scope the Incident

• Which systems, applications, data, business processes, and outside organizations are affected?
• Which user or service accounts, tokens, or keys are involved, and what can they access?
• Which indicators can we search for across the environment, and with what tools?
• What is the earliest evidence of the attacker’s activity, and how far back do our logs reach?
• Which outside parties, such as suppliers or service providers, hold credentials or network paths into the environment?
• What data has the attacker accessed or taken so far, and what evidence shows it?
• When did we first detect the incident, and who’ll determine whether we must notify anyone?

Review the Initial Survey’s Results

• What did the admin check in the initial survey, including cloud or SaaS logs, and what did they see?
• Did anyone reset passwords, delete files, patch, reboot, or reply to the attacker, and when? If so, we may have lost evidence and warned the attacker.
• What evidence will we lose soon, such as cloud resources, rotating logs, or a host’s memory, and who’ll preserve it?

Plan Containment and Next Steps

• Which response procedures, insurance terms, or legal holds apply, including which forensics firms we may hire?
• Which clean device and account will responders use, so the attacker can’t watch them or capture their credentials?
• If we need a system’s memory or live connections as evidence, who’ll capture them before we isolate it?
• Besides passwords, what else might give the attacker access, such as sessions, tokens, or mailbox rules, and who’ll revoke it?
• Which backups are reachable from the compromised accounts or network, and which predate the attacker’s initial access?
• Who’ll approve closing the incident, and how will we know the attacker is gone and operations restored?

Start the Incident Report

• Record each event’s date, time, time zone, and source, since the timeline and any deadlines depend on them.
• Record the severity, the affected business processes and third parties, and any personal data exposed, with the countries where it was stored.
• Record the root cause theory, its evidence, and your confidence, updating them as you learn more.
• Track completed actions with dates, pending actions with owners and deadlines, and lessons as they surface.
• Capture each decision, who made it, and why, so the report can explain it later.

Incident Response Steps

1. Identify and verify: Confirm the event is a real incident, and record why.
2. Triage with decision-makers: Agree on priority, resources, and acceptable disruption.
3. Scope, contain, eradicate, recover: Find every affected resource, cut off the attacker, remove their footholds, restore operations, and repeat until nothing new appears.
4. Close and learn: Have a decision-maker accept the remaining risk, and report what happened and why.

Other Incident Response Resources

• Survey Cheat Sheet and IR report template. IR steps adapted from Dynamic Incident Response by Joshua Wright (CC BY 4.0).

Post-Scriptum

Special thanks for feedback to Jack McCarthy and Patrick Nolan. If you have suggestions for improving this cheat sheet, please let me know. This cheat sheet is distributed under the Creative Commons Attribution 4.0 International License. Take a look at my other security cheat sheets.