Shift handover and operating variants
On this page
The chapters follow one analyst who carries a case from alert to verdict. Real queues break that picture in three common ways. The shift ends before the case does. The analyst works for a provider, not for the company that owns the asset. Or the company’s first line of triage is somebody else’s analyst. At the other extreme sits the team of one, where every role on this site is the same person. The method is the same in all four; what changes is who holds the facts, who owns the next action, and how ownership moves.
One rule runs underneath all of them: the case record carries the case, not the person. Every variant below is a way of making that true at the moment it is most likely to fail.
What this page assumes
This page uses the depth ladder, the hypothesis ledger, the handoff packet and the default clocks for each band. Read it after the Escalation decision chapter, or keep those pages open beside it.
Shift handover
A shift handover Shift Handover The written record and the live conversation that transfer open cases, running clocks, pending callbacks and containment in effect at a shift change. Ownership moves at the receipt: until the incoming analyst fills it in, the outgoing analyst still owns every open case. See Shift handover. is an escalation that stays in the same tier. The case changes owner, and every failure the handoff packet guards against can happen here too: lost context, a clock nobody is watching, a guess that hardens into a finding. It happens more often than an escalation, and with less ceremony.
Medicine has measured what structure buys at this moment. In a study of the I-PASS handoff program across residency programs at nine US hospitals, the medical-error rate fell by 23 percent and preventable adverse events by 30 percent (relative reductions), and spoken handoffs took no longer (Starmer et al., “Changes in Medical Errors after Implementation of a Handoff Program”, New England Journal of Medicine 371(19), 2014, doi:10.1056/NEJMsa1405556). ASSURED has no equivalent measurement for SOC handovers, so it borrows the structure, not the result.
What transfers
| What | For each item, the handover names | Why it cannot stay in someone’s head |
|---|---|---|
| Open cases | Case ID, priority and matrix cell, depth level, the owner after handover, the ledger state (leading hypothesis, live alternatives, what was refuted), the next action, and the result that would change the verdict | The next analyst needs the open questions, not the conclusion so far |
| Clocks running | The band’s acknowledgment or decision clock, the P3 re-score deadline, page fallbacks, and any candidate regulatory timestamp already flagged to its owner, each with its deadline in UTC | A clock does not restart because the owner changed |
| Pending callbacks | Who was asked what, on which channel, when, and when to chase: users, asset owners, vendors, pages awaiting acknowledgment | An answer that arrives to nobody is lost evidence |
| Containment in effect | Each pre-authorized action still in force, what was preserved first, how it was verified, and when it is reversed or reviewed; actions awaiting IR or owner approval | An isolated host nobody remembers is an outage; a forgotten approval is an open door |
| Watches and evidence at risk | Forward windows Forward Watch A time-boxed, owned watch on an entity for named events, set by Scope or Risk, with an expiry. Its end, or a named event during it, is a re-score trigger. Scope set (“who watches this account overnight”), and sources whose retention or export window closes before the next handover | The coverage model is only real if someone inherits the watch |
| Queue and detection state | Queue depth and oldest-item age by priority, rules firing outside their normal volume, pattern entries suspended or due for review, sensors gone quiet | A silent sensor and a noisy rule both change how the next shift should read its queue |
Five rules govern the transfer:
P1 and P2 transfer warm
A live call, bridge or desk-side handover in which the incoming analyst confirms ownership, the same warm handoff an escalation uses. P3 and P4 cases may transfer through the written record alone, but each still names an owner and a next action.
No clock crosses the boundary silently
A P2 due within 4 hours is either decided before the handover or handed over warm with its deadline restated. Clocks run from their trigger, not from the new owner’s arrival.
Ownership moves at the receipt
Until the incoming analyst fills the receipt line, the outgoing analyst still owns every case and every clock on the list, as with the packet’s receipt.
Hand over, do not clear the board
A case that cannot be finished is handed over, not closed to empty the queue, and no new Level 2 case starts in the last stretch of a shift without a named owner for the next one (see state traps).
The handover links; the case record holds
The handover points at each case record and does not retell it. Anything learned during the handover goes into the case record, timestamped, where the next reader will look (see timeliness).
The template
The shipped template, shift-handover.md, carries a metadata block with the receipt, one block per P1 and P2 case, one table row per P3 and P4 case, and tables for clocks and callbacks, containment in effect, watches and evidence at risk, and queue state. An MSSP or MDR fills one per customer. Insider-route cases appear by case ID and owner only: the details stay in the restricted case.
A handover line that fails, and one that passes
Fails: “4471: the backup agent again, looks benign, I’ll close it tomorrow.”
It names no priority, no clock and no owner. “Looks benign” is a conclusion with no evidence behind it, and “tomorrow” belongs to someone who will not be on shift.
Passes: “4471 · P3 (Medium impact / Medium likelihood, confidence Low) · Level 1 · owner after handover: incoming analyst. Leading: the scheduled backup job on files-02.corp.example. Live alternative: a renamed binary imitating the agent; the signer matches, but the destination is not yet checked against the pattern entry’s set. Next action: pull the proxy log for 02:10 to 02:20 UTC and compare destinations. Changes the verdict: any destination outside the set moves it to Level 2. Re-score due 2026-10-14T09:00Z.”
The incoming analyst can act on that line without asking anything, and can see what the outgoing analyst did not know yet. Case D shows a real one: a P3 handed to the evening shift on the written record, with both hypotheses still open.
Handoff anchoring: re-derive, do not inherit
The outgoing analyst’s story arrives with an authority it has not earned: it is the first framing the incoming analyst sees, it comes from a colleague, and it usually sounds finished. That is handoff anchoring Handoff Anchoring Inheriting the previous analyst's story as if it were a finding, at a shift change or an escalation. The counter is to re-derive the leading hypothesis from the evidence before accepting it. See Anchoring and Handoff anchoring. , anchoring Anchoring A cognitive trap: over-weighting the first piece of information (the alert name, the vendor severity, the first hypothesis) and adjusting too little as evidence arrives. It bites in Alert and carries everywhere. Counter: write down the leading alternative explanation before testing the first. At a shift change or an escalation it takes the form of handoff anchoring: the receiver inherits the sender's story as a finding. See Cognitive traps. delivered by hand, and the cognitive traps page names it as a state trap that bites at every shift change. Attackers know it too: activity started late in a shift or across a handoff lands where attention and context are thinnest.
The counter is to re-derive the hypothesis from the evidence rather than inherit it. For every P1, P2 and P3 case taken over:
- Read the raw alert fields and the newest evidence before the previous note. The note is a hypothesis about that evidence, not a substitute for it.
- Restate the leading hypothesis and at least one live alternative in your own words, from the ledger’s evidence, before running the next query. This is the last step of I-PASS, “synthesis by receiver”. If you cannot do it, the ledger is incomplete: ask now, while the outgoing analyst is still there.
- Re-rate confidence on the shared rubric. An inherited “high” is the previous author’s label; if you have not seen the corroboration yourself, round down until you have.
- Check what changed since the note was written: new alerts on the same entities, new sign-ins, a clock that moved.
The outgoing analyst’s half of the bargain is to hand over the ledger, not the story: what was tested, what was refuted and by which evidence, what is still open, and the one result that would change the verdict.
Running ASSURED as an MSSP or MDR
In the managed model, a managed security service provider (MSSP) Managed Security Service Provider (MSSP) An outsourced provider that monitors and triages security events for many customers. The provider owns the triage; the customer keeps accountability for the asset, the business context and the decisions only an owner can make. See Managed Detection and Response (MDR) and Running ASSURED as an MSSP or MDR. or a managed detection and response (MDR) Managed Detection and Response (MDR) An outsourced service that monitors an organization's telemetry, triages alerts and often takes first response actions on its behalf. The provider triages; accountability for the outcome stays with the customer, so the escalation path, pre-authorized actions and evidence-sharing terms belong in the contract. provider runs first-line triage for many customers. The provider owns the triage; the customer owns the asset, the business risk and accountability for the outcome. The phases do not change. What changes is where the facts come from: a provider analyst cannot run Subject and Scope from memory of an environment they have never worked in, so the customer has to supply those facts and keep them current.
What the customer must supply
| The customer supplies | What it feeds in the method |
|---|---|
| Asset criticality, with crown-jewel systems tagged | Impact on the Risk scale, item (a) of the eligibility gate, and the Level 2 trigger |
| Privileged identities, and automation holding deploy, signing, secrets or repository-write rights | Gate item (b); a privileged identity always routes to Level 2 |
| The regulated-data inventory, the regimes that apply, and who owns each | Gate item (c), regulatory scope, and the packet’s regulatory flags |
| A containment authorization matrix Containment Authorization Matrix In a managed-service arrangement, the per-customer list of which pre-authorized actions the provider may take, on which asset classes, with which preservation step, and who approves anything non-reversible. See What the customer must supply. : which pre-authorized actions, on which asset classes, with which preservation step, and who approves anything non-reversible | The pre-authorized immediate actions, per customer |
| Contacts: a call tree with no-answer timers and an out-of-band channel Out-of-Band Communication A channel for coordinating a response that does not depend on the systems the attacker may control: a separate identity provider, a phone bridge, a pager. ATT&CK mitigation M1060. See Talking to people during triage. | Paging and acknowledgment on the customer’s side |
| The change and maintenance calendar, and expected-change records for recurring privileged work | Verifying a benign explanation without a phone call |
| Data-sharing limits: what evidence may leave the tenant, at which TLP Traffic Light Protocol (TLP) FIRST's labels for how far shared information may travel. TLP 2.0 (2022) uses TLP:RED (named recipients only), TLP:AMBER (the recipient's organization and its clients, on a need-to-know basis; TLP:AMBER+STRICT limits it to the organization), TLP:GREEN (the recipient's community) and TLP:CLEAR (no limit). Respect the marking on what you receive, including in tickets and AI tools. marking | What the packet attaches and what it only references |
| A decision on who owns the pattern library Pattern LibraryASSURED term In ASSURED, the SOC's written catalog of known-benign alert patterns, each entry with named discriminators, an owner, a version and a review date, approved by a second person. It is governed like code: version history, invalidation triggers (a rule change, observed abuse), an optional machine-close flag, and a reversal threshold that suspends the entry automatically. A five-minute Level 0 close is earned by a current entry, not granted by the timer. See the fast path. Full entry: ASSURED terms. | One owner: either the provider maintains entries the customer approves, or the customer owns them and the provider applies them |
Unknown still fails the gate. A customer who has not supplied criticality or privilege data gets no Level 0 closes on the assets it covers, and the provider reports the gap as a contract issue, not a workaround. Load the supplied facts as enrichment on the customer’s alerts so analysts verify them rather than research them, and review them with the customer every quarter and whenever the customer reorganizes, acquires or migrates.
The customer escalation is the handoff packet
For a provider, the escalation is the customer notification, and the notification is the handoff packet: the same metadata header and nine sections, with three adjustments. The case summary ends with the decisions the customer must make (“approve the credential reset for this account”), not only the recommended move. Evidence the data-sharing limits keep in the customer’s tenant is referenced by location and hash rather than attached. And the communication record names the customer contact who acknowledged the notification, the channel and the time.
- Map each contract clock to a band. The default clocks are the starting point: a P1 pages immediately with a no-acknowledgment fallback at 15 minutes, a P2 is acknowledged within 15 minutes and escalated within 4 hours. Where a contract’s notification clock is slower than the band it serves, the customer accepts that gap knowingly, in writing; the provider should not discover it during a P1.
- Non-response does not close a case. When the customer does not acknowledge, the provider works the call tree to its end, takes only the reversible actions the customer’s authorization matrix lists (preservation first), records every attempt in the communication record, and keeps the case open. A confirmed criterion is never closed for lack of an answer.
- The customer fills the receipt. Accepted by whom and when, whether the escalation was warranted, and what had to be reworked. Two numbers come from it, reported per customer each month: escalation acceptance (escalations the customer judged warranted, divided by escalations sent) and handoff rework (accepted packets with rework requested, divided by packets accepted), with the handback Handback A receiving owner returning an escalated case to the sending tier with a named reason: the evidence chain is missing, the criteria or the cell are not supported, or the problem is detection tuning. Recorded on the packet's receipt and counted by reason. See Case D. reasons counted beside them. The author of an escalation never grades it (see Measuring triage).
- Closes are verdicts too. Documented closes go to the customer in a periodic close report, recorded on both verdict axes with the pattern entry and version that justified each Level 0 close, so the customer can sample them.
Running ASSURED as the customer of an MDR
When a provider’s escalation lands in your queue, it is an alert, and its verdict is a claim to validate, not a decision to sign (provider escalations covers the intake). Re-verify; do not rubber-stamp Rubber-Stamping Signing an AI draft or a recommendation without the verification the signature claims, also called approval fatigue. Its signals are in the case tool's timestamps: approvals faster than the checks can run, near-zero edits, identical close notes, agreement rates that jump after a model change. See Automation Bias and Rubber-stamp signals. . The provider sees your telemetry, not your business, so the facts it is least likely to have right are exactly the ones Subject and Scope supply.
- Accept the provider’s facts when each cites a raw event you can open yourself.
- Re-verify Subject and Scope against your own inventories: who the user is, what the asset does, what data it reaches.
- Re-run any claim that would confirm an escalation criterion, and re-rate its confidence on your own rubric. A provider’s “confirmed” reaches High on your rubric only once you have seen the corroboration yourself.
- Fill the receipt honestly. A “warranted” stamped on every escalation teaches the provider nothing, and it erases your only quality signal.
The provider’s notification starts your acknowledgment clock; it does not satisfy your decision clock. It can also be the moment your organization becomes aware of something a regulator counts, so flag the timestamp to the regime’s owner as the regulatory scope page describes.
Map provider dispositions to the ASSURED values
Providers and consoles label outcomes in their own words. Map each label once, in the contract or the service description, onto the two ASSURED axes. Microsoft’s two consoles show how the mapping works; their labels below are as documented on Microsoft Learn in October 2026 (Sentinel, closing an incident; Defender XDR, incident classification).
| Provider or console label | Detection axis | Activity axis | Before you accept it |
|---|---|---|---|
| Sentinel “True Positive: suspicious activity”; Defender XDR “True positive” | true positive | malicious, or policy violation | Which one is your call, on your evidence. Malicious and confirmed means the escalation tripwire. |
| Sentinel “Benign Positive: suspicious but expected”; Defender XDR “Informational, expected activity” | true positive | authorized (benign true positive) | Who authorized it, and where that is recorded. Never record it as a false positive. |
| Sentinel “False Positive: incorrect alert logic” | false positive (logic) | benign-confirmed, once checked | A tuning request goes to the rule’s owner. |
| Sentinel “False Positive: incorrect data” | false positive (data) | benign-confirmed, once checked | Which source or parser was wrong. |
| Defender XDR “False positive” | false positive (logic) or false positive (data) | benign-confirmed, once checked | The label does not say which; ask. |
| Sentinel “Undetermined”, or a provider’s bare “benign” or “no action needed” | as the evidence supports | undetermined | A named re-score trigger, or a close the record can defend. |
A benign true positive Benign True Positive An alert that fired on exactly the activity its detection logic describes, where that activity turns out to be authorized or expected in the local context: a red-team exercise, an admin's sanctioned use of a dual-use tool, a scanner doing its job. In the verdict record it is a true positive on the detection axis and authorized on the activity axis. The detection worked; the context clears it. Distinct from a false positive, where the logic matched something it should not have, so never record it as one. The close does not tune the rule, which is healthy. It feeds context instead: a pattern-entry proposal, or a scoped, expiring exception keyed to the tool version, extension or plugin ID and destination set, with an owner and re-fire triggers. Platform labels differ: Microsoft Sentinel calls this verdict Benign Positive, and Defender XDR calls it Informational, expected activity. Full entry: ASSURED terms. is a correct detection of authorized activity. Recording it as a false positive False Positive A detection-axis verdict: the alert's logic matched something it should not have, because the behavior the rule claims did not occur. ASSURED records two kinds: false positive (logic), a logic flaw or an over-broad pattern, and false positive (data), a parsing error, a missing field or bad telemetry. The fix is detection-side: tune, refine, or repair the data feed. Distinct from a benign true positive, where the behavior really happened but was authorized; that is never a false positive. Platform labels differ: Microsoft Sentinel's False Positive and Defender XDR's False positive mean this, while their Benign Positive and Informational, expected activity mean a benign true positive. sends a working rule to be “fixed”, and that is the most common mapping error.
Sample the provider’s closes the way the fast path samples Level 0: a weekly random sample re-verified against raw telemetry, with at least one close per pattern the provider applies. If the provider closes by automation, ask whether each machine close meets the conditions for governed automation: a machine-close flag on the entry, discriminators evaluated by code, an enforced eligibility gate, human QA sampling, tracked reversal and miss rates, and a kill switch with a named owner. Accountability stays with you either way.
The one-person SOC
One analyst runs every phase, watches the queue and carries the pager. The method still applies; the tier model at 3 a.m. is this team’s every day. Some things compress. Some never do.
What compresses
- Subject and Scope run as one sweep, as Level 1 already runs them.
- Tiers collapse: “tier up” becomes “engage the escalation path”, whether that is an on-call engineer, an MSSP or an IR retainer.
- Documentation is one record written as you go; the handoff packet may be addressed to the IR retainer, or to you a week later.
- Peer review becomes scheduled: a monthly read of a sample of your closes by someone outside the SOC (the provider, the IR retainer, an IT lead).
- The second approver for a pattern entry comes from outside the SOC: the asset owner, an IT lead or a provider analyst. No second approver means no Level 0 for that pattern.
What never compresses
- Validating the alert: raw fields before the severity.
- The eligibility gate: unknown still fails it.
- The escalation tripwire and the preservation step: a confirmed criterion escalates now, and evidence is preserved before any containment.
- The record: the cell, the verdict on both axes and the reasoning, every time.
- The clocks: translated, never loosened. “Within 4 hours” still means hours.
- Capacity as a route: an analyst who cannot both watch the queue and work a confirmed case escalates on capacity, and that is not a failure (see the three routes).
The shift handover matters more here, not less. The next shift is the on-call phone, the MDR overnight, or you tomorrow morning, and the version of you who reads the note at 08:00 has forgotten as much as any colleague would. Write the end-of-day handover against the same template, and name who watches each forward window until you are back.
Nobody else reads the record
The specific risk of a team of one is that no second person ever reads a close note, so drift goes unnoticed. The rubric, the external sample and the receipt from whoever takes your escalations are the only feedback you will get. Schedule them; they will not happen on their own.
Key takeaway
The case record carries the case, not the person. At a shift change, P1 and P2 cases transfer warm, no clock restarts, ownership moves only at the receipt, and the incoming analyst re-derives the hypothesis from the evidence instead of inheriting it. A provider runs the same method on facts the customer must supply, and escalates through the handoff packet, judged by the customer’s receipt. A customer re-verifies the provider’s verdict, maps its labels onto both ASSURED axes and samples its closes. A one-person SOC compresses the roles, never the gate, the tripwire, the preservation step, the record or the clocks.
Technical details verified . Product names, defaults and retention change; check your own tenant.