# False-positive closure records before a SIEM move | SourceX

Canonical: https://refer.sourcex.si/guides/workflow-false-positive-investigation-closure
Last updated: 2026-10-20

Before a SIEM replatform, inventory the records behind each closed false positive: the detection rule version that fired, the analyst's evidence and notes in the case manager, the closure verdict, and any exclusion or suppression the closure produced. Note which system holds each, the years covered, who owns it, and the real date old-platform access ends. Then introduce the company's SOC director, who can bring in the executive and counsel with authority to license.

## Why a SIEM replatform puts closure history at risk

A false-positive closure is spread across systems that a replatform treats differently. The alert lives in the SIEM, the analyst's reasoning in the case manager, and the fix in the rule repository or change tickets. A migration plan usually moves detections and maybe recent incidents; it rarely moves the joins that tie one alert to its case and to the rule version that fired.

The swimlane above follows one illustrative closure. A patch script triggers rule version 13 in the SIEM because it looks like lateral movement. The analyst gathers evidence in the case manager, closes the case as benign, and detection engineering ships rule version 14 with an exclusion. Thirty days later a check confirms the exclusion did not hide real activity. If the new SIEM issues new alert IDs and the old ones are not carried into the case manager, the case still exists but no longer points to the alert or to the rule that fired.

Labels add a second break. Splunk Enterprise Security records dispositions such as "False Positive - Incorrect Analytic Logic", with Undetermined as the default, and an administrator can make a disposition required when an analyst selects an end status such as Resolved or Closed. Microsoft Sentinel closes incidents with a classification such as Benign Positive or False Positive and a reason such as Incorrect Alert Logic. The two vocabularies are not the same, so a closure history is only readable after the cutover if someone writes down how the old labels map to the new ones.

Volume hides a third issue. In Sentinel, every time an incident is created or updated a new log entry is added to the SecurityIncident table, so one incident can have many rows. A summary export that keeps only the last row keeps the verdict and drops the sequence of decisions that led to it.

## What should be inventoried before a SIEM replatform affects false-positive investigation closure history?

Inventory record classes, coverage dates, owners and the access deadline, not the records themselves. The partner's job is to help the company see what it has before the old platform is switched off, then step back.

- [ ] **Record classes**: alerts or notables, cases and case notes, dispositions, suppression and automation rules, rule versions and their change rationale, post-closure reviews.
- [ ] **Coverage**: first and last year for each class, and any gap (for example, cases from a previous ticketing tool).
- [ ] **Where each lives**: SIEM, case manager, SOAR tool, code repository, change tickets, shared drive.
- [ ] **Owner of each class**: the SOC, detection engineering, the client (for client telemetry), or a vendor under contract.
- [ ] **Real access deadline**: the date the old SIEM license, hosting or read-only access actually ends, not the go-live date of the new one.
- [ ] **Label mapping**: whether anyone has mapped old dispositions to the new platform's classifications.
- [ ] **Authority**: who can decide whether any of this is discussed with an outside party.

Do not suggest keeping, exporting or copying data for a licensing conversation. Whether to retain records is the company's decision, made with the required authority and its own retention obligations in mind. The general questions a company asks before retiring any application are in [application decommissioning](/questions/application-decommissioning).

## An inventory register the SOC director can fill in

Illustrative. This is the shape of a one-page register for a fictional 240-person managed security provider. Every value is metadata a SOC director can give from memory or a system admin page; no alert, case or log is shown.

| Record class | System | Years held | Owner | Survives cutover? | Access ends |
|---|---|---|---|---|---|
| Alerts and notables | Old SIEM | 2019 to 2026 | SOC | Last 90 days only | License end, Q2 |
| Cases and analyst notes | Case manager | 2018 to 2026 | SOC | Yes, but alert IDs not remapped | Not changing |
| Dispositions and reasons | Old SIEM | 2020 to 2026 | SOC | Unmapped labels | License end, Q2 |
| Rule versions and change notes | Code repository | 2021 to 2026 | Detection engineering | Yes | Not changing |
| Suppressions and automation rules | Old SIEM | 2022 to 2026 | Detection engineering | Rebuilt by hand | License end, Q2 |
| Client telemetry | Old SIEM | Varies by client | Each client | Per client contract | Per client contract |

Two rows carry the risk: alerts and dispositions disappear with the license, and cases survive without the alert ID that tied them back. That is the finding a partner can raise without seeing a single record.

## Does the company qualify, and what stays unknown?

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 record classes the company has rights to license, what de-identification client-derived notes would need, whether buyers want this record type, and any offer. The [data rights explainer](/proof/why-data-rights-matter) covers the rights review in general terms, and the [cybersecurity services fit page](/industries/refer-cybersecurity-services-firm-data-licensing) explains why client-linked details are usually excluded. A partner never needs to see a case, an alert or a log.

On the reward, an illustrative case only: if a qualifying completed handoff led SourceX to pay the provider $250,000, the default reward would be $62,500. That is arithmetic on the published formula, not a forecast or a quote. A reward becomes payable after SourceX has paid the referred company under its signed agreement and the payout conditions in the program terms are met, including finance approval and your tax and payment details.

## Go deeper on false-positive investigation closure

- [False-positive closure exception examples](/guides/false-positive-investigation-closure-exception-examples): worked cases showing which closure records explain how an unusual alert was handled.
- [Reconstructing false-positive closure across systems](/guides/false-positive-investigation-closure-records-across-systems): a system map of the IDs and timestamps that join the SIEM, case manager and rule repository.
- [Who can license false-positive closure records](/questions/who-can-license-false-positive-investigation-closure-records): a short answer on which role to introduce and who signs off.
- [False-positive closure referral brief template](/resources/false-positive-investigation-closure-referral-brief-template): a fill-in template for the one-page introduction.

## 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 a security client is about to retire its SIEM and its closure history still links end to end, [register as a partner](/register), check the company against [who qualifies](/who-qualifies), and read the [program terms](/terms) before you send the one-page brief. More sectors are on the [industries hub](/industries).

## Sources

- https://refer.sourcex.si/terms
- https://help.splunk.com/en/splunk-enterprise-security-8/administer/8.0/investigations/configure-dispositions-for-findings-in-splunk-enterprise-security
- https://help.splunk.com/en/splunk-enterprise-security-7/administer/7.2/incident-review-and-investigations/customize-notable-event-settings-in-splunk-enterprise-security
- https://learn.microsoft.com/en-us/azure/sentinel/automate-incident-handling-with-automation-rules
- https://learn.microsoft.com/en-us/azure/sentinel/manage-soc-with-incident-metrics