TL;DR: An event is anything observable that happened: a login, a process start, a DNS query, a model API call. An alert is an event or pattern that a detection rule or analyst flagged as worth a human's attention because it may indicate malicious activity. An incident is a confirmed or strongly suspected violation of security policy or threat to the organisation's assets, which triggers the incident response process with owners, communication and evidence handling. Most events never become alerts, most alerts are benign or low value after triage, and the move from alert to incident is a declared decision by an on-call analyst or incident commander against written criteria, because it starts obligations: escalation, containment, legal and regulatory clocks.
How to approach it
Define each term by its role in the workflow and the obligation it creates. Then explain triage as the step between alert and incident, give criteria for declaring an incident, and mention severity, because severity decides who gets woken up.
A strong answer
Event
anything observable
Alert
rule or analyst flag
Triage
analyst judgement
Incident
declared by on-call lead
Response plan
roles and clocks
Event. A record that something happened, usually in a log: authentication success or failure, file access, network connection, configuration change, process execution, an agent's tool call. Organisations generate billions; nearly all are normal. Events are the raw material for detection and for investigation afterwards, which is why retention matters even for events that never trigger anything.
Alert. A detection decided that an event or a combination of events deserves attention: a rule matched (an encoded PowerShell command spawned by Office), a threshold was crossed (hundreds of failed logins), an anomaly model fired, or a third party reported something. An alert is a hypothesis, not a finding. Its quality is measured by precision (how many alerts are real) and by whether it carries enough context to act.
Triage. An analyst checks the alert: is it a true positive, is it malicious or authorised activity (an administrator, a penetration test), what is affected, how severe. Outcomes: close as benign with a reason (and feed that back to tune the detection), escalate for investigation, or declare an incident.
Incident. An adverse event, confirmed or credibly suspected, that threatens confidentiality, integrity or availability, or breaks policy: malware executing, an account compromised, data exposed, an AI agent taking unauthorised actions. Declaring one starts the response process: an incident commander, a channel, evidence preservation, containment decisions, stakeholder communication, and checks for notification duties (for example, personal-data breach notification under GDPR within 72 hours of becoming aware, where it applies).
Who decides, and on what basis. Written criteria, owned by the security team, such as: confirmed malicious code execution on any host; any confirmed account takeover; any exposure of regulated data; any unauthorised change to production; any credible report from a third party. The on-call responder declares; it is better to declare and downgrade than to delay. Severity levels (often SEV1 to SEV4) set response speed and who is involved, based on impact and scope.
Why the distinctions matter. They keep a SOC from treating every alert as a crisis (burnout and ignored alerts) or every incident as a ticket (slow containment). They also make metrics meaningful: alerts per analyst, true positive rate, time to triage, time to declare, time to contain.
What interviewers probe next
- "An alert fires for a known admin running a script. Incident?" Not if confirmed as authorised; close it with the evidence and consider tuning the rule or tagging the admin activity, while watching for the same pattern from other accounts.
- "When does the legal clock start?" Typically when the organisation becomes aware of a qualifying breach, which is why prompt, documented declaration and early legal involvement matter.
- "Is a hallucinated wrong answer from an AI assistant an incident?" Usually a quality issue; it becomes an incident when it causes a security consequence, such as data disclosure, an unauthorised action, or a manipulated output used to defraud.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Overnight, the SIEM records two million login events and raises forty alerts, and one analyst thinks a breach is under way and wants to wake the CISO.
Start here
How do events, alerts and incidents differ?
Which of the three starts obligations?
An event is anything observable: a login, a process start, a DNS query. An alert is an event or pattern a rule or analyst flagged as worth attention. An incident is a confirmed or strongly suspected policy violation or threat to assets, which triggers the response process with owners, communication and evidence handling.
Carry it forwardEvents are observed, alerts are flagged, incidents are declared.
Weak answerCalling every alert an incident.
Constraint changes
What happens to most of the forty alerts?
What fraction of alerts are usually true positives?
Most alerts turn out benign or low value after triage: an admin working late, a misconfigured service, a known scanner. Triage checks context and evidence quickly and closes or escalates each with a reason. The goal is to find the few that matter without ignoring any.
Carry it forwardTriage every alert with a recorded reason.
Weak answerAssuming forty alerts mean forty attacks.
Constraint changes
What should the analyst do before declaring an incident?
What would convince the incident commander?
Gather enough evidence against written criteria: correlated alerts on the same user or host, confirmed malicious activity, or access to sensitive assets. Escalate to the on-call lead or incident commander with that evidence. The criteria exist so declaration is consistent rather than based on worry.
Carry it forwardDeclare against written criteria with evidence.
Weak answerEscalating on instinct without evidence.
Constraint changes
Why is declaring an incident a deliberate decision?
What starts once an incident is declared?
Because it starts obligations: notification clocks, legal involvement, evidence preservation, communications and resource commitments. Declaring too late delays containment; declaring too often wastes effort and erodes trust in the process. Written criteria and a named decision maker balance both.
Carry it forwardDeclaration triggers obligations, so define who decides.
Weak answerAvoiding declaration to avoid paperwork.
Constraint changes
What if the analyst is right and it is a breach?
Why did the detections not make it obvious?
Then declare promptly, preserve evidence, contain and wake the people the plan names. Afterwards, ask why it took an individual's hunch rather than a detection to raise it, and turn that into detection or correlation improvements.
Carry it forwardTurn hunches that were right into detections.
Weak answerTreating a lucky catch as a working process.
Now defend it
How would you set up the flow from events to incidents?
Collect events broadly; alert on behaviours with rules that have runbooks; triage every alert with a recorded outcome; correlate alerts by entity; escalate with evidence to a named decision maker who declares incidents against written criteria; and once declared, follow the plan for containment, evidence, communication and notification, feeding misses back into detections.
How it's scored
Weak: Uses the three words interchangeably.
Hire: Defines each with an example, describes triage, and says incidents trigger the response process.
Strong Hire: Defines each by the obligation it creates, gives declaration criteria and who declares, links severity to response, mentions notification clocks, and connects the distinctions to SOC metrics and alert tuning.
Common mistakes
- Treating every alert as an incident.
- Waiting for certainty before declaring.
- Closing alerts without recording why, so detections never improve.
- No written criteria, so declaration depends on who is on call.