Incident Response Analyst Interview Questions
Interview questions for an incident response analyst, grouped by theme, with what a strong answer contains and the red flags to watch out for.
Hiring an incident response analyst means choosing the person who will be on the front line the day your systems go down. A strong CV says almost nothing about how someone behaves at 3 a.m. while encryption is spreading. Below is a set of questions organised by theme, with what a good answer contains and the signals that should worry you.
Before the interview: know what you are looking for
An incident response analyst (CSIRT or DFIR analyst, depending on the team) is not simply a more senior SOC analyst. The SOC detects and triages; incident response investigates, contains, eradicates and documents. If the scope is still unclear, our guide on hiring a SOC analyst helps draw the line.
Settle three things before the first interview:
- The environment: mostly Windows and Active Directory, cloud, OT, macOS endpoints?
- The expected autonomy: leading incidents, or executing under a lead?
- The pace: on-call duty, client site interventions (for a service provider), crisis work with executives?
Fundamentals and process
"Walk me through the main phases of incident handling."
A good answer names a recognised framework (preparation, detection and analysis, containment, eradication, recovery, lessons learned) and, more importantly, explains the trade-offs between phases: contain too early and you tip off the attacker, contain too late and encryption spreads.
Red flags: a recitation with no example, or forgetting lessons learned entirely.
"What do you preserve first on a compromised machine, and why?"
Expect the order of volatility: memory, network connections, processes, then disk. The candidate should also mention chain of custody and the possibility of a criminal complaint.
Red flag: "I reimage the machine to start clean" as a first reflex.
Windows and Active Directory investigation
"Which artefacts tell you a program was executed?"
A solid answer cites several sources and their limits: Prefetch, Amcache, Shimcache, Sysmon logs if present, process creation events (4688), EDR telemetry. A strong candidate adds that no single artefact is enough.
"How do you spot lateral movement in an Active Directory domain?"
Expect: logon types 3 and 10, privileged accounts on unusual hosts, PsExec, WMI or WinRM usage, remote service creation, signs of Pass-the-Hash or Kerberoasting. The best mention mapping attack paths to domain admin accounts.
Red flag: a list of tools with no idea what traces each one leaves.
Network and logs
"You only have proxy and firewall logs. How do you find a command and control channel?"
You want reasoning: regular connections (beaconing), new or rare domains, unusual outbound volumes, odd user agents, strange DNS resolution. The candidate should also admit what these sources alone cannot prove.
"Which logs are most often missing when you arrive on an incident?"
This one reveals real experience. A practitioner will talk about short retention, no PowerShell logging, cloud logs never enabled, unsynchronised clocks.
Malware basics
An incident responder does not need to be a reverse engineer, but must know how to triage.
"You find a suspicious executable. What do you do, and what do you avoid?"
Good answer: compute hashes, check threat intelligence sources, light static analysis (strings, imports), run it only in an isolated sandbox, extract indicators to hunt across the estate.
Red flags: uploading a possibly targeted file to a public service without thinking about information leakage, or running it on their own laptop.
Ransomware scenario: a worked question
This is the question that separates profiles best. Set the scene, then add information as the candidate answers.
"Monday, 7:30 a.m. Several users report renamed files on a network share. A ransom note appears on two servers. You are the first security person who can be reached."
| Step | What you add | What a good answer contains |
|---|---|---|
| 1 | Nothing, let them talk | Scope the impact, alert the escalation chain, avoid hard shutdowns (memory loss), isolate from the network |
| 2 | "EDR shows a domain admin account active on those servers since Friday night." | Treat the domain as compromised, disable or reset affected accounts methodically, look for the initial access point |
| 3 | "Backups sit on a domain-joined NAS." | Check their integrity urgently, isolate them, assume they may be hit too |
| 4 | "The CEO asks whether to pay." | Do not decide alone, refer to the crisis cell, recall obligations (notifying the CNIL for a personal data breach, police complaint, insurer) |
| 5 | "Three days later, everything is restored." | Lessons learned, report, measures so the same path no longer works |
How the candidate works matters as much as what they say: do they ask questions before acting? Do they prioritise? Can they say "I don't know, here is how I would check"?
Communication and reporting
"Explain this incident to me as if I sat on the executive committee."
Expect: business impact, what is under control, what is not yet, when the next update comes. No jargon, no false certainty.
"What goes into your incident report?"
An executive summary, a timestamped timeline, indicators of compromise, actions taken, root causes and prioritised recommendations. Ask for an anonymised excerpt if they have one: writing quality is judged on evidence.
Judgement under pressure
"Tell me about an incident where you got it wrong."
A good candidate describes a real mistake, what it cost and what they changed afterwards. Be wary of someone who has none.
"A business owner asks you not to isolate a critical server mid-investigation. What do you do?"
Expect a reasoned negotiation: spread risk, alternatives (targeted network filtering, closer monitoring), a decision made and logged by the right person.
Tips for non-technical interviewers
You do not need to know Amcache to run a useful part of the interview.
- Always ask for a lived example: "The last time this happened, what did you do?"
- Follow up with "why": a real practitioner justifies choices; someone reciting runs out quickly.
- Listen for structure: a good answer has an order, priorities and acknowledged limits.
- Score on a shared grid for every candidate, so you compare answers rather than impressions.
- Do not overrate certifications: they prove learning, not practice. Our article on cybersecurity certifications explains what they are really worth.
What a hands-on lab adds
The interview measures reasoning and communication. It is poor at measuring whether someone can find, alone, the right trace in a mass of logs. A short, realistic lab (a compromised Windows host, EDR exports, a timeline to rebuild) fills that gap and grounds the discussion: "Why did you conclude this account was the entry point?"
We cover this approach in our guide to assessing cybersecurity skills. If your candidate comes from another IT role, the lab is also the fairest way to judge them on facts: see hiring career changers in cybersecurity.
In short
A good incident response interview covers fundamentals, Windows investigation, networks, malware triage, an evolving scenario, communication and judgement. It looks for lived examples and clear priorities, not tool lists. Paired with a hands-on lab, it gives you a decision based on evidence.
Hiring an incident response analyst? At Cyber Recrut, a recruiter and a security practitioner run every search together, and shortlisted candidates prove their skills on hands-on labs built around your role. See how we work or share your hiring need.