This system map is part of the false-positive investigation closure guide. The hub covers the inventory a company takes before changing platforms; this page shows where each record sits day to day and which identifier carries one case across systems.
Six systems, one closure
A single closed alert touches more systems than most security teams list when asked. Name all six before mapping keys.
- Detection platform. Raw detections, the rule that fired, timestamps, host and account fields. Microsoft Sentinel's alert schema, for instance, gives every alert an internal unique identifier, SystemAlertId, and stores alerts from all sources in one table.
- Case manager or incident queue. The case, its linked alerts, status history, analyst notes, the verdict and the closing comment. Ask whether the case history is stored as one record or as one record per change; the second keeps the sequence, the first keeps only the end state.
- Rule repository. Detection source, versions, change rationale and review comments, often in Git. On GitHub, for example, a reviewer can comment, approve or request changes before a rule change merges, and that review stays with the pull request.
- ITSM or ticketing. Change tickets, travel or access requests and other approvals the analyst cited as evidence.
- Identity provider. The account, its group memberships and sign-in records.
- Automation rules or SOAR. Rules or playbooks that tag, assign or close incidents without an analyst. In Microsoft Sentinel, automation rules can close known harmless incidents as they arrive, apply a classification and reason, and carry an expiration date.
GitHubThe linking keys
One row per join: where the key is written, what it connects and who owns each side.
| System | Record | Linking key | Owner |
|---|---|---|---|
| Case manager | Case, status history, notes, verdict | Case number (the anchor) | Security operations manager |
| Detection platform (SIEM) | Detections that opened or joined the case | Alert ID stored on the case | Security operations, administered by the platform admin |
| Rule repository | Detection version and its change history | Rule ID plus version written on the alert | Detection engineering lead |
| ITSM | Change or request ticket used as evidence | Ticket number in the case notes | IT service management |
| Identity provider | Account, groups, sign-in details | User principal name on the alert | Identity team |
| Automation rules | Rule that closed or tagged the case | Automation rule ID in the case activity | Detection engineering or the automation owner |
Two keys are often typed by hand rather than stored as fields: the ticket number in a free-text note and the rule version in a comment. Hand-typed keys are the first to go missing or be mistyped, so ask whether they are structured fields or prose.
One fully joined case (Illustrative)
Illustrative. A 270-person managed security provider runs its own case manager on top of a cloud detection platform for a client whose consultants travel constantly.
| Time | Event | System | Key that joins it |
|---|---|---|---|
| 09:02 | Impossible-travel detection: sign-ins from two countries 70 minutes apart | Detection platform | Alert ID, rule ID and version 9, user principal name |
| 09:05 | Case opened with the alert linked | Case manager | Case number, alert ID |
| 09:20 | Analyst finds an approved travel request and confirms the second sign-in came through the client's VPN exit | ITSM, identity provider | Ticket number, user principal name |
| 09:31 | Closed as Benign Positive, Suspicious But Expected, with the ticket cited | Case manager | Case number, ticket number |
| Day 3 | Detection engineer adds the VPN exit range to the rule's known locations | Rule repository | Rule ID, version 10 |
| Day 3 | Temporary automation rule closes repeat alerts for the traveler, expiring in 14 days | Automation rules | Automation rule ID |
| Day 17 | Automation rule expires; next alert would reach an analyst again | Automation rules | Automation rule ID, expiry date |
With all keys present, a reviewer can see the alert, the reasoning, the evidence ticket, the rule change and which later closures were automatic. Remove the ticket number and the verdict looks like a guess. Remove the automation rule ID and automated closures are indistinguishable from analyst judgments.
Where the joins break
- Status history flattened. If only the latest record per case is kept, the sequence of owners and status changes disappears.
- Reviews lost. If rule changes were made directly in the console rather than through reviewed pull requests, the reasoning behind a tuning decision lives only in someone's memory.
- Free-text keys. Ticket numbers typed into notes are inconsistent and sometimes absent.
- Rule renamed. A rule renamed during tuning breaks the link from old alerts to the repository unless the ID is stable.
- Automation untagged. Automated closures without a tag or rule ID inflate apparent analyst work.
The general reason joined records are worth more than single exports is set out in why cross-system data is worth more. If a client needs an example outside security, the logistics exceptions guide applies the same problem, action and result test.
Questions to ask, and what stays unknown
Ask the security operations manager or platform administrator, at metadata level only:
- Is the alert ID a structured field on every case, and since which year?
- Are rule versions recorded on alerts, and is the repository history complete?
- Are evidence tickets linked by field or typed into notes?
- Are automated closures tagged with the rule that made them?
- Who owns each system, and who can authorize a licensing discussion? The who-can-license decision tree covers that step.
Identity fields are personal data in most regimes; the PII versus personal data comparison explains why that matters before any reuse. 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. What stays unknown until SourceX reviews it: which joins actually hold across years, what client-derived content must be excluded, whether there is dataset demand, and any offer. For a single case walked decision by decision, see the worked hard case.
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 platform administrator confirms that cases carry alert IDs, rule versions and evidence tickets as structured fields, register as a partner, check the company against who qualifies, and read the program terms before you make the introduction.