Closing the loop
On this page
Seven chapters, seven letters, one methodology. This page closes the loop: what you now have, what ASSURED is and is not, and where to take it next. Each closed case becomes feedback for the next one; the five downstream uses of that feedback are covered in the chapter overview.
What you have, across all seven chapters
Across seven chapters, the methodology gave you four things. A vocabulary: seven letters, each answering one question, a shared language that travels across teams and cases and survives turnover. A structure: three stages that group the seven phases, Orient (Alert, Subject, Scope), Investigate (Uncover, Risk), and Resolve (Escalation decision, Documentation), so the structure does the orienting and attention goes to the evidence. A discipline: each phase hands one deliverable forward, and a skipped phase shows up downstream, however small the case. And a scaffold: a map for new analysts and a checklist for experienced ones, which improves as cases reveal where it bends.
Each phase answers one question and hands one deliverable forward, and each deliverable lands somewhere specific in the record:
| Phase | Anchor question | Deliverable | Where it lands in the record |
|---|---|---|---|
| Alert | What fired, and why? | The validated alert and its detection context | 01 Event overview |
| Subject | Who is involved? | Entity assessments | 03 Origin and scope |
| Scope | Where are the lines? | The boundary: entities, time window, systems in and out | 03 Origin and scope |
| Uncover | What does the evidence say? | The evidence chain, with confidence labels and coverage gaps | 02 Timeline, 03, 06 Indicators and observables |
| Risk | How bad is it, and how confident are we? | Impact, likelihood, confidence, matrix cell, priority, and a recommended move | Decision header, 05 Business impact |
| Escalation decision | Close or escalate, and who needs to know? | The documented close or the handoff packet, plus the communication record | Decision header, 04 Actions taken, 09 Appendices |
| Documentation | What did we decide, and what did we learn? | The event report, reviewed and linked | 07 Lessons learned, 08 Post-event recommendations |
What ASSURED is, and is not
ASSURED is a triage methodology: seven phases (Alert, Subject, Scope, Uncover, Risk, Escalation decision, Documentation) that take an analyst from “an alert fired” to “the case is closed or handed off, and the record survives.” It is neither an incident-response framework nor a SOAR playbook but the analyst’s decision work between those two points, building on whatever automation has already enriched and handing IR a structured starting point; the introduction sets out the whole arc, the positioning page shows how it compares with the frameworks around it, and the standards mapping shows where its records meet NIST CSF 2.0, ISO/IEC 27001 and the other frameworks an auditor tests against.
The methodology's four commitments
Decisions are based on named inputs, not feelings. Two analysts working the same alert should reach comparable outputs, because every input is explicit, from the detection logic that fired to the matrix cell, with confidence recorded beside the rating.
Roles and handoffs are explicit. Risk recommends; the Escalation decision decides close or escalate, and records it. The triage analyst owns that decision, the verdict, and the handoff packet. The incident responder owns the incident lifecycle once the packet is accepted. The SOC manager owns the closure review: per case for Level 2, P1/P2 and escalated-then-closed records, and through the weekly QA sample for Level 0 and 1 closes. When the handoff is structured, no role does the other’s work.
Benign closes are first-class cases. A documented close carries the same evidentiary weight as a documented escalation. The methodology refuses the “just a false positive” shrug: a full-arc investigation gets the nine-section event report whichever way the verdict lands, and even a Level 0 pattern close gets its five-field record (the fast path). Depth follows the case; the discipline of writing it down does not. Those records are also the audit evidence for CSF 2.0 DE.AE-08 and ISO/IEC 27001 A.5.25; the standards mapping lists which record serves which outcome.
The loop is real. Scope → Uncover → Risk iterates as new evidence surfaces. Refining a scope mid-case is the methodology working, not the methodology failing.
Where to go from here
Cumulative review
Twenty questions that mix all seven phases, in no particular order, on situations the chapter quizzes did not use. Retrieval across chapters is what makes the method stick; if an answer surprises you, go back to that chapter before moving on.
Cumulative review: all seven phases
No grades. The questions jump between phases on purpose, the way a real case does.
An EDR alert fires on a scheduled task created on a finance laptop. Before looking at the host, the analyst opens the rule definition. What is that step for?
Alert asks what fired and why, and its deliverable names the detection mechanism and its trust level. The rule's severity is an input to Risk, not the priority; earlier fires on the host are prevalence, not a verdict; and the vendor's description is no substitute for reading the logic.
A sign-in alert for a domain admin account matches a pattern-library entry exactly: same VPN egress, same managed device, every discriminator passes. Can it close at Level 0?
Discriminators and the eligibility gate are separate tests. The gate fails on any privileged identity, whatever the discriminators say, and a privileged identity is itself a Level 2 trigger. Sign-in patterns can be library entries; this one cannot close at Level 0 because of who the subject is.
Four alerts fire within ten minutes: three on one user's laptop and one on the same user's mailbox. One of the laptop alerts matches a Level 0 pattern. How does the work proceed?
The case, not the alert, is the unit of work. Alerts on the same entity in the same window form one case, which takes the level of its riskiest member, and a grouped case never closes at Level 0 if any member fails eligibility. Splitting off the matching alert is how a real intrusion loses its first clue.
While working a bulk-download alert, a teammate passes on office talk about the employee's private life and suggests it explains a motive. What goes into the case record?
Analysts record observable technical activity. HR-held context reaches the case only through the insider-risk route, and never as analyst-collected notes, however well meant. Talk about someone's private life is not an indicator an analyst writes down, labeled, sanitized or otherwise.
Subject comes back clean on all four dimensions, and a sanctioned change ticket explains the alert. What does the analyst hand Scope?
A clean Subject still produces a deliverable: the clean verdict, written down, and a narrow recommendation. The remaining phases run at Level 1 as single moves toward a documented close at the Escalation decision. Skipping them leaves no record of why the case closed; widening the scope anyway spends effort the evidence does not justify.
The user's baseline says they always sign in from one city, but the baseline covers only the nine days since a log-source migration. How should it be recorded?
Subject's baselines carry confidence labels for exactly this reason. A short window is still evidence, but a reader needs to know how much weight it bears. Calling it settled overstates it; discarding it throws away what little there is; burying the migration in an appendix hides the reason it is weak.
Midway through Scope, the analyst finds that the compromised mailbox held EU customer records the attacker plausibly read. Nothing is confirmed yet. What does the analyst do about the GDPR clock?
The GDPR clock runs from awareness, a reasonable degree of certainty that personal data was compromised, not from confirmation. The analyst recognizes, timestamps and routes; counsel and the privacy owners decide whether the clock started and whether to notify. Waiting or deferring loses hours the owner may need; notifying directly takes a decision that is not the analyst's.
The scope's time window covers two days when the proxy logs for the affected site were not collected. Where does that go?
The visibility map is part of the one-page scope: what the tooling cannot see, named. Naming the gap keeps Uncover from reading silence as a clean result and keeps Risk honest about confidence. Shortening the window to fit the logs hides the gap instead of recording it.
In Uncover, the analyst finds a second laptop that received the same lure email, though nothing shows it was opened. The signed boundary covers only the first laptop. What now?
Scope, Uncover and Risk loop as new evidence surfaces, and refining the lines mid-case is expected. A received but unopened lure is not attacker activity on a second host, so no criterion is confirmed; it is a reason to widen the boundary. Splitting it into a new case or parking it as an open question loses the connection.
A query for outbound connections from the host over the incident window returns no rows. How does the hypothesis ledger record it?
Negative findings name what was examined. An empty result means something only relative to the source, the query and the window, and only for what that source can see; 'no exfiltration' claims more than the query showed, and 'nothing found' cannot be checked. Recorded negatives are part of Uncover's deliverable, not something to drop.
An AI assistant drafts a timeline row saying the attacker created a mailbox rule at 10:14. The analyst has not opened the audit log. What is the status of that row?
AI output is a draft, not evidence. Before a row enters the record, the analyst finds the raw field behind it and labels it on the rubric like any other claim. Declaring AI use is required, but it does not verify anything; and a confidence label applied to an unchecked claim is a guess with a label on it.
EDR shows a non-browser process reading the browser's cookie store, and the identity provider shows that session used from a hosting address minutes later. The plausible alternatives were tested and ruled out. What confidence does the theft claim earn?
That is the High definition on the rubric: direct evidence from a source trusted for this kind of claim, corroborated by an independent source, with the alternatives tested and ruled out. The rubric does not require a reviewer's sign-off or a particular artifact type, and two independent telemetry sources are direct evidence of the theft chain.
Logs from a production database server for the suspicious window could not be retrieved. The analyst rates likelihood Low because nothing bad was found. What is the correct read?
Evidence that could not be examined means low confidence, never low likelihood. On a high-impact asset the override reads missing evidence as Medium likelihood at minimum, which makes the cell High/Medium, P2, and an escalation within 4 hours. Leaving it unrated lets the clock run with no decision at all.
Risk lands at High/Low, P3. The analyst writes 'close' as the outcome of the Risk section. What is wrong?
Risk produces the ratings, the cell, the priority and a recommended move; the Escalation decision makes and records close or escalate. High/Low is P3 on the high-impact clock: keep working, re-score within hours on the named trigger, then close or escalate. Writing 'close' at Risk skips both the trigger and the owner of the decision.
EDR quarantined a malicious attachment as it was downloaded. No process ran from it, and there is no follow-on activity anywhere. How is the case recorded?
The first escalation criterion is confirmed malicious activity not fully contained by a control. Blocked or quarantined, with no execution or follow-on evidence, is the contained-by-control path: recorded at P3 or P4, never paged. The detection was correct and the file was malicious, so it is a true positive, not a false positive of any kind.
A P4 case closes with a full written rationale. A colleague reads it and says, 'So it was nothing.' What is the methodology's position?
Most verdicts close, and a documented close carries the same evidentiary weight as a documented escalation. The rationale is what lets the next analyst, the reviewer and the auditor see why it closed. Inflating the priority to make it count, or waiting for IR to bless it, misreads what a close is.
At 10:05, still in Subject, the analyst confirms at High confidence that the attacker's session reached a second host. The matrix has not been scored. What happens?
Attacker activity reaching a second host is the lateral-movement criterion, and once it is confirmed (High on the rubric) it escalates from any phase and makes the case P1 whatever the cell. The escalation is an early E decision, recorded in the E fields. Finishing the phases first is how a tripwire met at 09:24 gets acted on at 14:00.
An identity compromise is confirmed, and the protocol pre-authorizes session revocation for this scenario. What comes first?
Preserve before you contain: the preservation step comes before the pre-authorized action, because revocation destroys the session evidence. A password reset is not reversible, so it needs IR or owner approval unless the protocol lists it explicitly. Doing nothing while waiting lets both the attacker and the retention window keep running.
After a case closes, a reviewer finds that the timeline gives 09:40 for a step the SIEM records at 09:14. How is it corrected?
Entries lock at handoff or close, and corrections are appended with author, time and reason, never overwritten. The record then shows both what was believed and what was corrected, which is what makes it trustworthy as evidence. Leaving a known error in place is not what locking means.
A case closes as a benign true positive: the rule correctly caught an authorized admin tool doing what it is approved to do. What does Documentation send to detection engineering?
The detection was right and the activity was authorized, so there is no logic defect to fix. The feedback is a pattern-entry proposal or a scoped, expiring exception keyed to that tool, with an owner and re-fire triggers. A permanent exclusion for a whole team is the blind spot an attacker using the same tool would hide in.
Worth revisiting
Key takeaway
The methodology is a shared way of working. The picture you assembled across seven chapters is the framework. The cases you apply it to are the practice. And the documentation you produce becomes the feedback loop that improves the next case.Next up
Cognitive traps
The method is complete. Next: the reasoning failures it is built to catch, and the counter for each.
Read cognitive trapsTechnical details verified . Product names, defaults and retention change; check your own tenant.