# Containment handoffs: a worked overnight case | SourceX

Canonical: https://refer.sourcex.si/guides/incident-containment-handoffs-exception-examples
Last updated: 2026-10-19

The incident records that explain a containment exception are the ones that pair each action with its approval, the person who owned the incident at that moment, and a later check that the action worked. The hardest exception sits at a shift change, when an incident is handed over as contained before every step is done. Below is one Illustrative case, worked step by step, and then how to recognize similar histories at a client without opening a single case.

This worked case belongs to the [incident containment handoffs guide](/guides/workflow-incident-containment-handoffs), which covers what to inventory before a response provider changes. This page stays inside one incident and the decisions in it.

## The case file (Illustrative)

Nothing below describes a real company, attack or completed deal.

| Item | Illustrative value |
|---|---|
| Company | A 900-person regional distributor |
| Security setup | Small in-house team plus an outside monitoring provider whose contract is ending |
| Incident | Sign-ins to a finance user's mailbox from an unfamiliar location |
| People deciding | Provider analyst, night on-call IT lead, day lead, CISO |
| Duration | 21:40 one evening to 11:00 the next morning |
| Outcome | Closed after a verified second round of containment |

## Seven entries in the shift ledger

Each entry names the owner at the time, what they decided, and the record the decision left behind.

| Time | Owner | Decision or action | Record it leaves | System |
|---|---|---|---|---|
| 21:40 | Provider analyst | Opens a case for suspicious sign-ins | Case with alert references | Provider portal |
| 22:05 | Night on-call IT lead | Approves disabling the account and isolating the laptop | Approval message | Chat |
| 22:20 | Night on-call IT lead | Disables the account; isolates the laptop | Admin and endpoint action logs | Identity console, endpoint console |
| 06:00 | Night lead to day lead | Hands over with the note "contained, monitor"; case reassigned | Handover note, owner change | Case tool |
| 09:30 | Day lead | Review finds active sessions not revoked and a mailbox forwarding rule still in place | Review comment | Case tool |
| 09:50 | Day lead, with CISO approval | Revokes sessions, removes the forwarding rule | Approval, admin logs | Case tool, identity console |
| 11:00 | Day lead | Sign-in and mail logs show no further access; closes after review | Verification note, closure | Case tool |

Two of these entries depend on how the case tool stores history. In Microsoft Sentinel, the SecurityIncident table gives each incident an Owner field and a LastModifiedTime, and every update adds a new row, so the 06:00 reassignment and the 09:30 review both remain readable as separate entries. A tool that keeps only the current assignee would show the day lead as owner throughout, and the handoff itself would vanish.

## The exception at 06:00: contained, or two steps short?

The case turns on a single handover note. The night lead had blocked access at two points (the account and the laptop) but not at two others (live sessions and the forwarding rule). CISA's federal response playbooks list blocking unauthorized access and rotating credentials among containment actions, and treat confirming remediation as part of recovery before an incident is closed. Measured against that, "contained" was premature.

| Path at 09:30 | What the records would show | Result |
|---|---|---|
| Accept the night note and keep monitoring | An owner change, a monitoring status, no further actions | Mail keeps forwarding to an outside address for hours or days |
| Review the containment list against the case | A review comment naming the two gaps, a CISO approval, new admin logs, a verification note | Access fully cut and proven before closure |

The day lead's review is the decision that makes the history valuable: someone checked a colleague's claim against the evidence, escalated for approval and then proved the fix.

## Why the miss-and-repair sequence is better evidence than a clean report

A final incident report would say the account was compromised, contained and closed. It flattens the two-stage containment into one line. The shift ledger keeps what a reviewer, an auditor or an AI developer needs: the state at handover, the gap, who noticed, who approved the second round, and the check that ended it. That is a long, multi-actor task with a correction in the middle, the kind of sequence described in [long-horizon tasks for AI agents](/guides/long-horizon-tasks-ai-agents), and close kin to the cause-and-fix chains on the [root cause analysis records page](/data-types/root-cause-analysis-records).

The strength of a company's archive depends on habits: whether approvals given in chat quote the case number, whether owner changes are kept as history, and whether closures say what was verified. The [records across systems map](/guides/incident-containment-handoffs-records-across-systems) shows where each piece usually sits.

## Recognizing handoff-gap histories at a client

Ask the incident response director these questions and note only the answers.

1. When an incident changes owner at a shift change, is the handover written in the case, in chat, or spoken on a call?
2. Does the case tool keep each owner change, or only the current owner?
3. Are containment approvals tied to the case number, or given in direct messages?
4. Do closure notes say what was checked, such as sign-in logs or mail rules?
5. Roughly how many incidents a year needed a second round of containment?

Mostly yes answers suggest a decision-rich history. The [incident records introduction checklist](/resources/a-company-introduction-checklist-for-incident-and-on-call-records) covers wider incident and on-call records, and the same caught-and-repaired pattern shows up in freight, as the [logistics exceptions guide](/guides/how-to-identify-logistics-exceptions-and-their-documented-resolutions) shows.

## What qualifies, and what stays with SourceX's review

The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English.

Partners never collect cases, logs or exports; discovery stays at metadata level. Unknown until SourceX reviews it with the company: which records the company holds rights to (provider-held notes may not be among them), what must be removed or generalized, whether buyers want this record type and any offer. The [who-can-license decision tree](/questions/who-can-license-incident-containment-handoffs-records) helps find the signer, and the [referral brief template](/resources/incident-containment-handoffs-referral-brief-template) turns the answers into a one-page note. Partners sign the Channel Partner Agreement before submitting introductions.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If the incident response director confirms that owner changes, approvals and verification notes were kept across years of shifts, [register as a partner](/register), check the company on [who qualifies](/who-qualifies) and read the [program terms](/terms) before you introduce it.

## Sources

- https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
- https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/securityincident
- https://learn.microsoft.com/en-us/azure/sentinel/manage-soc-with-incident-metrics
- https://refer.sourcex.si/terms