This map is part of the incident containment handoffs guide. The worked overnight-shift case shows why each join matters.
The case number at the center
A handoff history is a star, not a chain. The case is the hub, and each system that took part in the incident is a spoke. If a spoke carries the case number, the record joins cleanly. If it does not, someone has to match it by time and object, and that match can be wrong.
| System | Record it holds | Linking key to the case | Usual owner |
|---|---|---|---|
| Case tool or SIEM incident queue | Case, status changes, comments, closure | Case number (the hub) | SOC lead or incident response director |
| Case history or audit log | Each owner change with its time | Case number plus owner and modified time per row | SOC lead |
| Chat | Containment approvals, handover messages | Case number quoted in the message, or a channel named after the case | IT or collaboration admin |
| Identity console | Account disables, session revocations, rule changes | Account ID plus timestamp | Identity or IT operations lead |
| Endpoint console | Host isolation, scans, release | Hostname or device ID plus timestamp | IT operations lead |
| Provider portal | Provider analyst notes, provider case | Provider case ID, copied into a cross-reference field | Outgoing provider, under the services agreement |
Five links and how each fails
- Case to chat approval. Fails when approvals are given in direct messages that never mention the case. Slack exports, for example, hold one folder per conversation with messages keyed by user ID and timestamp, so an approval can be found by time, but only if the export includes that conversation. On Business+ plans, Owners and Admins can export public channels; private channels and direct messages need a separate export tool the company must apply for.
- Case to containment action. Fails when console logs are kept for a shorter period than cases, so older incidents lose the action record.
- Owner changes. Fails when the tool keeps only the current assignee. In Microsoft Sentinel's SecurityIncident table each update adds a record with the Owner field and a LastModifiedTime, and a new entry is written every time an incident is created or updated, so the sequence of owners can be read across rows.
- Provider case to internal case. Fails when the provider's ID is never copied into the internal record; the two cases then join only by date and subject.
- Verification. Fails when the closure says "resolved" without naming the check that justified it.
SlackCase tools differ. PagerDuty, for instance, shows a timeline per incident with timestamps for each status, actions taken and notifications sent, and its API can list an incident's log entries; the PagerDuty incident export page covers that system, and the ServiceNow incident data page covers ServiceNow.
PagerDuty
ServiceNowOne fully joined case (Illustrative)
Below is a joined record set for a single fictional incident, every identifier invented. It is the target a company's history can be measured against.
| Spoke | Record | Key carried | Joined to case IR-3107? |
|---|---|---|---|
| Provider portal | Provider case P-77120, opened 21:40 | P-77120 in the internal cross-reference field | Yes |
| Chat | Approval at 22:05 in channel ir-3107 | Channel name | Yes |
| Identity console | Account disabled 22:20; sessions revoked 09:50 | Account ID and times quoted in case comments | Yes |
| Endpoint console | Laptop isolated 22:20 | Hostname quoted in case comments | Yes |
| Case history | Owner rows: provider, night lead, day lead | IR-3107 per row | Yes |
| Chat | CISO approval at 09:50 in a direct message | Time only | By hand |
Five spokes carry a key. The sixth, an approval in a direct message, joins only because the case comment repeats its time. That is a common weak point, and a good question to ask.
Questions for the tool administrators
- Does the case tool keep owner and status history, and from which year?
- Are incident channels named after the case, and are they public or private?
- How long do the identity and endpoint consoles keep admin action logs?
- Is the provider's case ID copied into internal cases, and since when?
- Do closure notes name the verification performed?
The answers go into the brief as metadata. A neighboring SOC workflow is mapped in false-positive investigation closure, and the partner field guide for incident and on-call records covers spotting companies with these histories.
Qualification and the open questions
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.
The partner fills in the map with system names, years and owners only. What stays open until SourceX's review: whether provider-held records are the company's to license, which spokes can be included after de-identification, SourceX's current data needs and any offer. Managed service providers that run incidents for clients face extra questions about client records, as the MSP roll-up page notes. The referral brief template has fields for systems and the weakest link.
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 map shows a company whose case numbers still reach its chat, consoles and provider records across years, register as a partner, check the company on who qualifies and read the program terms before you introduce its security leader.