What it means
An alert packages a detection condition for attention. It might come from a fixed rule, a statistical model, or a person noticing something unusual. Its title is a hypothesis, and its severity is an initial assessment. An alert should point to the underlying observations and explain why the detector matched. Several alerts can describe one incident; an incident can also begin with a customer report and no machine alert. Some alerts are handled automatically, but their meaning and allowed response still need clear boundaries.
See the idea / Detection
A signal asks for a closer look.
One size rule creates an alert with source evidence and sends it to a review queue. Investigation remains open.
Illustrative export test: record E42 names job TEST-7 and 200 test records. Rule R4 alerts above 100; the SOC queue receives alert A17.
01 / 04
Observe
Application record E42 identifies job TEST-7 exporting 200 test records at 02:06. The record is an observation. No alert has been raised or delivered yet.
More about this step
This controlled example supplies one complete export record and an illustrative fixed rule. The application log retains E42 throughout the flow. The job’s approval and surrounding activity have not been investigated here.
Step through at your own pace.
Keep in mindThis figure ends at alert delivery. Authorization and incident declaration need further evidence. The size rule and queue are illustrative; other alerts can come from models or people.
Read the visual, step by step
- Observe. Application record E42 identifies job TEST-7 exporting 200 test records at 02:06. The record is an observation. No alert has been raised or delivered yet. This controlled example supplies one complete export record and an illustrative fixed rule. The application log retains E42 throughout the flow. The job’s approval and surrounding activity have not been investigated here.
- Match. The detection service reads E42 and evaluates rule R4: export above 100 records. Two hundred matches that condition. The match establishes size; it does not establish theft or unauthorized activity. The moving E42 label represents the record information consumed by the detector. The source log stays in place. This is a literal size condition, rather than a claim that a real product uses this threshold or treats every large export as an incident.
- Create. The completed R4 match causes the service to create alert A17. It includes references to source record E42 and rule R4 so a reviewer can see what happened and why the detector matched. The R4 label carries the completed match into alert creation. A17 appears after that creation completes; it is not a second source event. The alert retains the matching record and rule references. No queue receipt, investigation, disposition, or incident declaration is implied.
- Deliver. Alert A17 travels to the SOC review queue. The queue shows receipt only after arrival and keeps the source and rule references. The next task is investigation: check the job’s authorization and context. Incident status remains undetermined. The detector retains its alert while a notification copy is delivered to the receiving queue. Received describes the queue’s state, not an analyst acknowledgement or a resolution. This example ends before the reviewer gathers approval and audit context, applies incident criteria, or labels the alert true or false. NIST separates sending alerts to authorized staff from declaring incidents after analysis.
This figure ends at alert delivery. Authorization and incident declaration need further evidence. The size rule and queue are illustrative; other alerts can come from models or people.
Flow references: NIST SP 800-61 Revision 3: DE.AE-02, DE.AE-06, and DE.AE-08 · NCSC: Detection practices
AN ILLUSTRATIVE SCENARIO
An unfamiliar sign-in location
A finance employee’s account signs in from two distant locations within minutes. The alert could indicate stolen access, but a corporate network gateway can also explain the location change. The analyst checks timestamps, session identifiers, device information, and subsequent account actions. Finding a new payment instruction changes the urgency; the geographic label alone does not establish fraud or justify every possible containment action.
Put it to work
- Describe the behavior a detection is intended to catch and which records trigger it. Give each alert enough evidence to start investigation without guessing.
- Assign a responsible queue, expected response time, and escalation conditions. Distinguish an analyst’s acknowledgement from investigation or resolution.
- Record the disposition and supporting reason. Use reviewed outcomes to improve the detection, while retaining examples that reveal unexpected legitimate behavior.
How to check your work
Trigger a harmless test that meets the detection condition. Check that it reaches the right queue, contains source evidence, and has an actionable next step. Test a similar legitimate case to understand noise.
Connect the ideas
- Log
A record emitted by a system that something happened, which may later be used as evidence.
- Incident
An event or set of events that actually or potentially causes a security loss requiring coordinated handling.
- Triage
A short, time-boxed judgment of severity, uncertainty, and next action when an alert arrives.
- False positive
An alert that did not represent the harmful event the detector was meant to catch.