In this article
  1. Before you start
  2. Why interviewers ask this
  3. Incident response for security roles from first principles
  4. Worked example
  5. Trade-offs and edge cases
  6. How to answer it in an interview
  7. Common mistakes
  8. Follow-up questions
  9. Sources

Before you start

This page is one part of the cyber security interview questions learning path.

Why interviewers ask this

A candidate who describes incident response as "find the malware and remove it" has described one slice of the work. A scenario question, such as a laptop showing signs of compromise, is a chance to show that you know the whole shape: who decides, who investigates, who talks to the outside world, and when.

A weak answer lists tools and jumps to isolating the machine. A strong answer starts by asking whether the alert is an incident at all, names the roles involved, ranks the work by risk and says what the team gives up when it contains quickly. A Staff-level answer adds the legal clock and the review at the end. The sibling pages on threat intelligence interview questions and application security interview questions cover the neighboring technical ground.

Incident response for security roles from first principles

Cybersecurity incident
A cybersecurity incident is an occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity or availability of information or an information system, or constitutes a violation or imminent threat of violation of law, security policies, security procedures or acceptable use policies. The National Institute of Standards and Technology (NIST) restates this federal definition (NIST, 2025, p. 2). An event is any observable occurrence involving computing assets, and it becomes an incident only after analysis.
Triage
Triage is the step of ranking incidents and deciding which one gets people and time first, based on risk instead of arrival order. It exists because responders have scarce time and staff. NIST lists six example factors for the ranking, covered in Step 3.
Containment
Containment is the set of actions that prevents an incident from expanding, such as isolating a host or disabling an account. It is not recovery, which restores normal operation, and it is not the removal of the attacker's footholds, which happens afterward.

In plain words

Think of a hospital emergency department. Many people arrive. A nurse decides who is seriously ill. Doctors treat them. Someone speaks to the family. Someone writes the record afterward. Nobody expects one person to do all of it.

The analogy breaks in one place. A hospital patient does not change tactics when the doctor looks at them. An attacker can.

In one precise sentence, incident response is a set of named roles, with written authority and a risk-based order of work, that moves an organization from an observed event to a declared incident, through containment and recovery, and into a review.

Step 1: An event becomes an incident only after analysis

An event becomes an incident only after analysis against criteria. NIST (2025, p. 2) says additional analysis is often needed to determine whether adverse events indicate that an incident has occurred. Adverse events are those associated with a negative consequence regardless of cause.

Declaring an incident is therefore a defined step, not a feeling. NIST's guidance for the Detect function (p. 26) is to apply the incident criteria to the known and assumed characteristics of the analyzed activity and to consider known false positives before an incident is declared.

Input: an alert or observation. Output: a decision, declare or do not declare, with a reason. A SOC analyst often makes the first call. What you now know: the response clock and the roles in the next step only start moving once someone has declared.

Step 2: Roles and authority are written down before an incident starts

Roles and authority are written down before an incident starts. NIST (2025, p. 7-8) names eight groups: leadership, incident handlers, technology professionals, legal, public affairs and media relations, human resources, physical security and facilities management, and asset owners. NIST adds that roles differ for each organization and can differ by incident.

Leadership "oversees incident response, allocates funding, and may have decision-making authority on high-impact response actions" (p. 7). An incident handler is a person who verifies that an incident has occurred, collects and analyzes evidence, prioritizes response work and acts to limit damage, find root causes and restore operations. Handlers can be staff, a managed security service provider (MSSP) or a cloud provider's team.

The missing term is authority. NIST says policy should state which roles may confiscate, disconnect or shut down technology assets (p. 8-9). With a provider, NIST describes a shared responsibility model, so the contract must say who may act (p. 8).

Step 3: Triage ranks incidents by risk, not by arrival order

Triage ranks incidents by risk, not by arrival order. NIST states that because of resource limitations, incidents should not be handled on a first-come, first-served basis (p. 26). It lists six example factors: asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability (p. 27).

Input: a declared incident and what is known about it. Output: a priority and an owner. NIST suggests considering an incident lead for each incident (p. 27). An incident lead is the single person who coordinates one incident, so responders know whom to ask.

Escalation is an increase in resources or time frames, while elevation involves a higher level of management (NIST, p. 28). Say which one you mean in an interview. You now know how work is ordered; the worked example below scores three made-up incidents.

Step 4: Containment trades speed against evidence

Containment trades speed against evidence and observation. NIST says every response strategy decision has trade-offs, and watching an attacker may be at odds with a quick return to normal operations (p. 28). It describes containment as preventing the expansion of an incident (p. 32).

Eradication is the removal of persistence mechanisms and entry points, such as deleting malware, disabling breached accounts and mitigating every exploited vulnerability (p. 33). NIST's example of containment tiers runs from an emergency workaround lasting hours, to a temporary workaround lasting two weeks, to a permanent solution (p. 32).

If a team wants to redirect an attacker into a sandbox, NIST says this delays containment and eradication and that the team should first discuss feasibility with the legal department (p. 32). Recovery includes restoring from clean backups, and NIST says to check backups for indicators of compromise first (p. 33-34).

Step 5: Communication and the review close the loop

Communication and an after-action report close the loop. NIST groups communication into four kinds: incident coordination, incident notification, public communication and incident information sharing (p. 30). Notifications must follow current laws.

One law with a clock is Article 33 of the General Data Protection Regulation (GDPR). A controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. A late notice must carry reasons for the delay, and a processor must tell the controller without undue delay.

The review is the after-action report, which NIST says documents the incident, the actions taken and the lessons learned (p. 34). Exercises and lessons from real incidents are both rated High priority (p. 19). Together these steps give the whole path.

Incident response moves through five steps with named ownersFlow of five steps: an event becomes an incident after analysis, roles and authority are set in advance, triage ranks by risk, containment and recovery trade speed against evidence, and communication and review close the loop.Event to incidentanalyze, declareRoles and authorityset in advanceTriagerank by riskContain, eradicate,recoverspeed vs evidenceCommunicate, reviewafter-action reportDiagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/incident-response-for-security-roles.html

Each step has an owner and a decision, so the response does not depend on one hero.CC BY 4.0 — source: Incident response for security roles: who owns triage, containment and comms
Step-by-step description
  1. Analysis turns an event into a declared incident.
  2. Roles and authority were written down in advance.
  3. Risk factors set the order of work.
  4. Speed is traded against evidence.
  5. Communication and the after-action report close the loop.
  • An event becomes an incident only after analysis against criteria.
  • Roles and authority are written down before an incident starts.
  • Triage ranks incidents by risk, not by arrival order.
  • Containment trades speed against evidence and observation.
  • Communication and an after-action report close the loop.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Worked example

Three hypothetical incidents arrive in this order: A, a phishing click on one laptop; B, ransomware on a file server; C, stolen credentials used on a payroll database. Each is scored from 0 (low) to 3 (high) on NIST's six factors; every score is illustrative, and a higher recoverability score means harder to recover.1

Scored on the six factors, incident B totals 16 and incident C 14 against 6 for incident A, so risk order is B, C, A even though A arrived first.1
FactorA: phishing clickB: ransomware on file serverC: stolen payroll credentials
Asset criticality133
Functional impact132
Data impact123
Stage of observed activity132
Threat actor characterization122
Recoverability132
Total61614

Illustrative totals are 6 for incident A, 16 for incident B and 14 for incident C. Triage handles B first, then C, then A.1 A real team would use its own scale; NIST gives the factors, not the weights.

Risk order differs from arrival order in the triage exampleBar chart of illustrative triage totals: incident A, which arrived first, scores 6; incident B scores 16; incident C scores 14, so B is handled first, then C, then A.Total risk score (points)061218A (1st)B (2nd)C (3rd)Incident (arrival order)61614Diagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/incident-response-for-security-roles.html
Risk order, not arrival order, decides which incident gets people first.CC BY 4.0 — source: Incident response for security roles: who owns triage, containment and comms
Text description of the diagram
  • Illustrative totals are 6 for incident A, 16 for incident B and 14 for incident C.
  • Triage handles B first, then C, then A.

The notification clock is plain arithmetic. Suppose a controller becomes aware of a personal data breach on Friday at 17:00 (illustrative). Seventy-two hours later is Monday at 17:00.1 If awareness comes on Saturday at 02:00, the limit is Tuesday at 02:00.1 The regulation text runs the 72 hours from awareness, not from the end of the investigation. After 30 hours of investigation, at most 42 hours remain.1

The duty is "without undue delay", and 72 hours is only the outer limit. If facts are still missing, the controller can notify now and add information in phases (Article 33(4)). Only a notice later than 72 hours must give reasons for the delay. No notification is needed where the breach "is unlikely to result in a risk to the rights and freedoms of natural persons". A readable reproduction of Article 33 is also online.

Trade-offs and edge cases

The current lifecycle is not the one many articles still teach. NIST released Revision 3 in April 2025 and it supersedes Revision 2, which dates from August 2012. Revision 2 had four phases; Revision 3 uses the six Functions of the NIST Cybersecurity Framework (CSF) 2.0: Govern, Identify, Protect, Detect, Respond and Recover. Govern, Identify and Protect are preparation and not part of the response itself; Detect, Respond and Recover are the response.

Revision 3 maps four old phases onto six Functions, and improvement feeds every Function instead of coming only at the end.

Revision 3 replaces four phases with six FunctionsTable mapping the four phases of the older NIST incident handling model to the six Functions of the current model and showing which are part of the response itself.Old phaseCSF 2.0mappingRole inresponsePreparationGovern, Identify,ProtectPreparation, notresponseDetection and analysisDetect +improvementResponseContain, eradicate,recoverRespond,Recover,improveResponsePost-incident activityIdentify(Improvement)Feeds everyFunctionDiagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/incident-response-for-security-roles.html
Revision 3 splits preparation from response and lets improvement feed every Function.CC BY 4.0 — source: Incident response for security roles: who owns triage, containment and comms
Text description of the diagram
  • Preparation maps to Govern, Identify and Protect.
  • Detection and analysis maps to Detect.
  • Containment, eradication and recovery map to Respond and Recover.
  • Post-incident activity maps to the Improvement Category of the Identify Function.

Preparation maps to Govern, Identify and Protect. Detection and analysis maps to Detect, and containment, eradication and recovery map to Respond and Recover. Post-incident activity maps to the Improvement Category of the Identify Function, and NIST also places that improvement activity inside detection and inside containment, eradication and recovery, so lessons feed every Function (NIST, 2025, Table 1). NIST explains the change: Revision 2 was written when incidents were relatively rare and usually finished within a day or two, while today recovery often takes weeks or months (p. 4).

A second model is common in interviews. The SysAdmin, Audit, Network and Security (SANS) Institute's Incident Handler's Handbook (Kral, 2012) uses six steps: Preparation, Identification, Containment, Eradication, Recovery and Lessons learned. It separates containment, eradication and recovery into three steps and ends with lessons learned, where NIST's current model spreads improvement across every Function. In an interview, name both and say they describe the same work.

Edge cases. Many teams use an incident manager, often called an incident commander, a role borrowed from the Incident Command System of emergency management, who makes the final calls so decisions do not stall in committee, while analysts investigate and contain. A separate communications lead is also common. This is a commonly described industry pattern from a vendor, not a standard, and that vendor recommends a matrix of who is responsible, accountable, consulted and informed (RACI) to separate who decides from who executes.

The same source says a team is a set of roles, not a headcount, so one person can hold several. NIST names only the optional incident lead. Formal evidence handling is not needed for every incident, but NIST says collected data is still considered evidence (p. 29). When evidence matters, record who handled each item (the chain of custody) and collect the most volatile data first, because memory contents vanish before disk contents (Request for Comments 3227, February 2002, §2.1, §4.1). That ties to containment: wiping or reimaging a host destroys memory evidence, so capture what you need first.

A playbook is a document that gives actionable steps for people to perform in a defined scenario. NIST cites the federal playbooks from the Cybersecurity and Infrastructure Security Agency (CISA) as an example; they are written for federal agencies, and CISA encourages public and private partners to review them. Other regimes set other reporting clocks, so check each primary text before you quote one. The identity and access management analyst role often supplies the account actions that containment needs.

How to answer it in an interview

Interviewer asks

How would you handle a suspected security incident, and who is involved?

A strong answer

I treat incident response as a team process with roles set before anything happens. First I check whether the alert meets our incident criteria, because an event is not yet an incident. If it does, someone declares it, an incident lead coordinates and handlers investigate. We triage by risk, not arrival order: asset criticality, impact on data and function, stage of the attack and recoverability. Before containing, I weigh speed against evidence, and I consult legal on anything unusual. Communication follows the law, including regulatory clocks, and we finish with an after-action report.

The spoken structure: say whether it is an incident, name who decides, rank by risk, state the containment trade-off, then communication and review.

Common mistakes

  • "Incident response is the security team's job." (wrong) NIST describes leadership, legal, communications, human resources, asset owners and third parties as part of it. (right) "The security team investigates, and other roles own decisions and communication."
  • "Every alert is an incident." (wrong) Events become incidents after analysis against criteria. (right) "I analyze first, then declare."
  • "I handle incidents in the order they arrive." (wrong) NIST says not first-come, first-served. (right) "I rank by risk factors."
  • "I contain immediately, always." (wrong) Containment trades speed against observation and evidence. (right) "I weigh speed against what we would learn, and I involve legal before letting an attacker run."
  • "The 72 hours start when the investigation ends." (wrong) The clock runs from awareness. (right) "I notify in phases if the facts are incomplete."

Follow-up questions

Who is on an incident response team?

It is a set of roles and not a fixed department. NIST names leadership, incident handlers, technology professionals, legal, public affairs, human resources, physical security and asset owners, and the mix differs by organization and by incident. The cyber security interview guide places this inside the wider topic list.

What is the difference between a security event and an incident?

An event is any observable occurrence involving computing assets. It becomes an incident only after analysis shows it actually or imminently jeopardizes confidentiality, integrity or availability, or violates law or policy.

What does an incident commander do?

In the common industry pattern, the incident commander makes the final calls so decisions do not stall, while analysts investigate and contain; one person can hold several roles (Expel, September 2026, a vendor, not a standard). NIST itself suggests an optional incident lead per incident.

What is the difference between NIST and SANS incident response phases?

The SANS Institute's handbook has six steps (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned), while NIST's older model had four phases and its current one uses six CSF 2.0 Functions. Both cover the same work; the main difference is where improvement sits (Kral, 2012).

When does the 72-hour GDPR notification clock start?

It starts when the controller becomes aware of the personal data breach, not when the investigation finishes. A late notice needs reasons, and information may be given in phases.

Should you contain an incident immediately?

Not automatically. Containment prevents expansion but can end the chance to observe the attacker, so the decision is a trade-off that depends on the risk. When tokens are stolen, containment usually means revoking refresh tokens and rotating the signing key, because a signed JavaScript Object Notation (JSON) Web Token (JWT) stays valid until it expires; JWT interview questions covers why.

Key takeaways
  • Incident response is a team process built on named roles and written authority, not only a security team task.
  • An event is not an incident until analysis against criteria says so.
  • Triage ranks by risk factors, not by arrival order.
  • Containment, eradication and recovery each trade speed against evidence and observation.
  • Notification clocks run from awareness, and an after-action report closes the loop.

Sources

  1. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (NIST SP 800-61 Rev. 3) — NIST, 3 Apr 2025
  2. NIST Revises SP 800-61: Incident Response Recommendations and Considerations — NIST, 3 Apr 2025
  3. Federal Government Cybersecurity Incident and Vulnerability Response Playbooks — CISA, 1 Nov 2021
  4. CISA Incident Response Training — CISA, 1 Aug 2024
  5. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 33, Official Journal L 119 — EUR-Lex (Publications Office of the European Union), 27 Apr 2016
  6. Article 33: Notification of a personal data breach (readable reproduction, pointer only) — gdpr-text.com, 27 Apr 2016
  7. Incident Handler's Handbook (Kral) — SANS Institute, 21 Feb 2012
  8. RFC 3227: Guidelines for Evidence Collection and Archiving — Internet Engineering Task Force, 1 Feb 2002
  9. Incident response team: roles and responsibilities — Expel (vendor, secondary), 25 Sep 2026