A security alert is a question the detection engine is asking the analyst. Is this real, is it malicious, how serious is it, and what should happen next?
Event triage is the work of answering those questions with confidence, and it is a distinct skill from broader incident response. ASSURED is a structured, repeatable methodology for doing that work consistently. The seven letters of Alert, Subject, Scope, Uncover, Risk, Escalation, and Documentation cover the full arc of a triage investigation from the moment an alert fires to the moment the analyst hands off (or closes) the case.
Why ASSURED, why now
Incident Response The organized approach to addressing and managing the aftermath of a security breach or cyberattack, including preparation, detection, analysis, containment, eradication, and recovery. frameworks like NIST 800-61 and SANS PICERL describe what to do once you already know what you are looking at, and knowledge bases like MITRE ATT&CK A globally-accessible knowledge base of adversary tactics and techniques based on real-world observations, used for threat modeling and security operations. catalog adversary behavior once you know which behavior you are looking for. Event Triage The phase that sits between detection and incident response: deciding whether an alert is real, whom it concerns, what its blast radius might be, and whether it crosses an escalation threshold. The ASSURED methodology is a structured way to do triage. is the work before both, and most analysts learn it informally on the job. The gap is widening, not closing: NIST’s 2025 revision of 800-61 (r3) reframes incident response around the CSF 2.0 functions and deliberately drops r2’s step-by-step analysis guidance, leaving the how of alert analysis to each organization. ASSURED is designed to give that informal craft a structure that scales: scaffolding for newer analysts, a checklist for experienced ones (the printable one-page reference), and a shared vocabulary for handoff and review. See Where ASSURED sits for the related-work map, and Development and evidence for the framework’s origin, rejected precursor, applied use, and current validation limits.
Triage is not incident response
ASSURED is a triage methodology. The triage analyst answers four questions, is this real, is it malicious, how serious is it, what should happen next, and either closes the case or hands it to incident response. The IR responder runs the formal lifecycle (NIST 800-61r2: preparation → detection & analysis → containment, eradication & recovery → post-incident activity). Triage produces the decision to escalate; IR runs the response once the decision is made. The two roles share telemetry and vocabulary; they are not the same job. The clearer the line between them, the cleaner the handoff. See the Triage vs. IR page in the Escalation chapter for the full distinction.
Who this is for, and what you should be able to do afterward
Scroll into the diagram below and the pieces assemble themselves to show how the flow works. Each phase contributes specific evidence to the next.
Preparation & Context
Investigation & Assessment
Resolution & Documentation
↻ Feedback loop, refine scope, re-uncover, re-validate
Establishes the foundation for the investigation. What fired, who is involved, where the boundaries are. Without it, every later step is built on a guess.
Pulls in Telemetry Collection and transmission of security-relevant data from remote sources for monitoring and analysis. , correlates it across systems, and decides how to prioritize what was found. The stage where most of the active investigative work happens.
Produces the handoff to the next tier or the closure record that makes the work survive its ending. The stage where institutional memory gets built.
The loop is intentional
Triage is not strictly linear. Risk findings often send the analyst back to Uncover for more evidence. Uncover sometimes reveals new subjects the original alert never mentioned. Discovering a new subject can change the scope of the entire investigation. The dashed feedback arrow in the diagram represents that flow, and embracing it is part of the methodology.
Security analysts at every level of experience meet these problems regularly. Each phase of ASSURED is designed to address one or more of them directly.
SOCs see thousands of alerts per day from heterogeneous sources (Vectra AI’s analyst surveys put the average around 3,000–4,500 daily across 2023–2026), and a small fraction describe real threats. Without a way to separate signal from noise, the events that matter get buried in volume. Addressed by: Alert, especially its validation stage.
Telemetry lives across multi-cloud environments, hybrid datacenters, container platforms, and serverless functions. Cross-tool correlation does not happen by default. Mitigated by: Uncover, which makes source selection and correlation an explicit step instead of an assumption.
Modern intrusions use living-off-the-land techniques, polymorphic payloads, and social engineering. The activity looks like normal operations. Addressed by: behavioral analysis throughout the methodology, especially in Subject and Alert’s validation stage.
Investigations now carry compliance obligations alongside the security work. GDPR, PCI DSS, HIPAA, SOX each impose requirements on documentation, evidence handling, and in some regimes notification. Addressed by: Scope and Documentation.
Analysts juggle SIEM, SOAR, EDR, identity systems, and cloud consoles within a single investigation. Context switching erodes accuracy and accelerates fatigue. Addressed by: the methodology’s structure itself, which gives the analyst a clear next step at every moment.
Inconsistent records make post-mortems painful, trend analysis impossible, and audits stressful. Addressed by: Documentation, which is the final phase precisely because capturing decisions is what makes the work durable.
Three outcomes the methodology aims for at every step. Together they describe what a SOC running ASSURED looks like when it is working well.
The phase structure shows where automation fits: repetitive work like enrichment, correlation, and scoring can be handed to tooling, while the phase boundaries keep human judgment on the decisions that actually need a person. A SOAR that pre-fills Alert and Subject shortens the arc; it doesn’t replace it. The same boundary governs LLM assistants, phase by phase, on the AI-assisted triage page.
Two analysts working the same alert with the same methodology produce comparable outputs. That makes training easier, escalation cleaner, and audits less stressful.
ASSURED works for a one-person SOC and for a follow-the-sun team of forty. Feedback loops keep the framework usable as detection logic evolves and the team grows. The method does not depend on team size or tooling specifics.
The same phase takes very different time depending on who’s working it. A senior analyst who knows the detection logic, the business, and the environment may close Alert in under a minute. A new analyst on their second week may spend 15 minutes on the same alert, partly understanding the detection, partly understanding what the systems involved even do. Both are normal. The ranges below cover all three experience levels so you can recognize where you are. These are operational shift times, not reading times. A careful first read of the full site is a separate ~7 to 10-hour investment including the quizzes and worked examples.
What makes the difference between new and expert
The gap between a new analyst and a senior one is rarely raw speed. It’s three things:
1. Context familiarity. An expert recognizes the detection that fired before they finish reading the alert. They know which mailbox rule on which finance laptop usually triggers it, what a normal Tuesday looks like for dlin (the finance analyst whose case threads through the worked examples), and which on-call to page if the answer isn’t quick. A new analyst has to assemble all of that fresh. The fastest path to closing this gap is shift time, sitting on the same alert queue for six months teaches more about your environment than any course can.
2. Pattern recognition for false positives. Experts close false positives faster because they’ve seen the same false-positive pattern 200 times. The methodology is what lets the new analyst close the first one defensibly, with a record the team can learn from. Read the false-positive page in the Risk chapter early; it’s the highest-leverage page on the site for closing the speed gap.
3. Knowing when to stop. New analysts go down rabbit holes. (Every analyst has a story like it: two hours on a single PowerShell command that turns out to be a sysadmin’s harmless inventory script.) The good news: every rabbit hole you walk out of teaches you what entering one feels like. Six months in you’ll catch yourself reaching for the next log query and recognize the pattern. By year two you’ll stop yourself before you start. The methodology helps by giving you explicit phase boundaries, when Uncover starts feeling open-ended, that’s the moment to step back to Scope and ask whether the boundaries are still right.
These three skills compound. They are also why the time ranges in the table above span an order of magnitude. If you’re at the high end of the New column, that’s where you are; don’t measure yourself against the Expert column on day one.
When you blow past the upper bound
Even an expert hits the upper bound sometimes. Twenty minutes into Alert and still unclear what the detection logic saw? That is usually a sign the alert came from a system you do not yet understand; pull in a peer or a senior analyst. Ninety minutes into Uncover with no convergence? Stop, write down what you know, and either ask for help or formally escalate as “still investigating.” The ranges exist so you notice these moments, not so you race against them.
This table prices the full arc; most alerts never get it
These ranges are the cost of a complete seven-phase investigation. A SOC handling thousands of alerts per day cannot spend it on every alert, and the methodology doesn’t ask it to: most of a healthy queue closes in minutes against documented false-positive patterns, and only the alerts that earn it get the full arc. How an analyst decides how much depth each alert gets (and what a defensible five-minute close looks like) is the fast path.
The letters are the method. Each one is a question the analyst answers before moving on:
Two memory traps are worth defusing now. The two S’s: who before where. The first S resolves the person or system behind the activity; the second draws the lines around how much of the environment matters. You cannot draw boundaries around an actor you have not identified. And the E: Escalation is the decision, not the outcome. The name pulls readers toward escalating, but most triaged cases close at E. The phase exists to make close-or-escalate a deliberate, evidenced call instead of a default in either direction. Those two are naming traps; the thinking traps, anchoring, confirmation bias, and their relatives, get their own page in Cognitive traps in triage.
Recommended path
On a first read, take the letters in order: A, S, S, U, R, E, D. The methodology is structured so each step builds on the previous one. After that, jump straight to whatever phase the day’s case demands; all seven chapters and three glossaries stand alone as references.