# Vulnerability exception history before a merge | SourceX

Canonical: https://refer.sourcex.si/guides/workflow-vulnerability-exception-renewal
Last updated: 2026-10-20

Before two risk platforms are merged, inventory every vulnerability exception's chain: the original risk acceptance, the compensating control it relied on, each renewal review, and the evidence that the control was tested. Record which tool holds each piece, the years covered, the owner, and when old-tool access ends. Then introduce the risk owner, usually the CISO or head of IT risk, who can bring in the executive with authority to license.

## What vulnerability exception renewal records

A vulnerability exception is a decision not to fix a known weakness on schedule. NIST's patch management guide lists the possible risk responses as accept, mitigate, transfer and avoid, notes that mitigation can include controls such as segmentation that isolate a vulnerable asset, and says organizations should verify that added controls work. An exception is usually some mix of acceptance and mitigation, granted for a limited time.

Renewal is where the history builds up. Each time the period ends, someone must decide whether the reason still holds, whether the compensating control is still in place, and whether to grant another period. Over a few years, one unpatchable system can collect a stack of approvals, each resting on evidence about a control that may itself have changed. That stack is the record worth keeping, and it is exactly what a consolidation tends to flatten into a single current status.

## Why renewals break in a consolidation

Tools store renewals in different ways, so the same history can look very different after a merge.

- **Each renewal can be a separate record.** Microsoft Defender Vulnerability Management documents that an exception applies for a set duration and scope with a documented rationale, and that durations cannot be extended. Continuing an exception after it lapses means creating a new one. A migration that loads only active exceptions drops every earlier link in the chain.
- **Expired acceptances may leave little trace.** Tenable documents that accept rules can expire after a number of days or on an exact date; on expiration the risk is no longer accepted, while historical scan results stay unchanged. The scan history survives, but the decision layer above it is easy to lose.
- **Justifications are coded, reasoning is not.** Microsoft lists justifications such as third-party control, alternate mitigation, risk accepted and planned remediation. A code says which kind of decision it was; the reasoning and the control evidence usually sit in a GRC platform, a ticket or an email.

So the question for a consolidation is not "will our exceptions move?" but "which parts of each exception's history will move, and which tool keeps the rest readable?"

## What to inventory, record class by record class

Inventory the shape of the history, not its content: which record classes exist, how far back each goes, who owns it, and the date the retiring tool stops being readable.

| Record class | Typical home | Coverage to note | Owner to name |
|---|---|---|---|
| Findings with asset and vulnerability IDs | Scanner | First scan year, any scanner change | Vulnerability management |
| Exception requests and approvals | Scanner, GRC platform or ticketing | Years, and whether expired exceptions are kept | Risk owner |
| Renewal reviews | GRC platform, email, meeting notes | Whether renewals are separate records | Risk owner |
| Compensating-control evidence | Change tickets, test results, screenshots | Whether tests are attached or only described | IT infrastructure |
| Closure records | Scanner, project tool | How exceptions ended: patched, replaced, decommissioned | Vulnerability management |
| Policy versions | Document management | Which exception policy applied when | GRC lead |

Then ask for the access deadline in writing: the date the old platform's license, hosting or read-only access ends. A consolidation go-live date is not the same thing, and the gap between them is often the only window to describe the history. Do not suggest keeping or exporting anything for a licensing conversation; retention is the company's own decision under its own obligations. Security teams preparing a [cyber insurance renewal questionnaire](/guides/cyber-insurance-renewal-questionnaire) often already know where this evidence lives.

## Questions for the risk owner

1. How many exceptions are open today, and roughly how many have been granted, renewed or closed per year?
2. In which tool is each renewal recorded, and does it point back to the original acceptance?
3. Is control evidence attached to each renewal, or kept somewhere else?
4. Which tool is being retired, and on what date does read-only access end?
5. Do customer contracts or regulators limit how security records may be used?

The [client opportunity brief generator](/tools/client-opportunity-brief-generator) can turn the answers into a one-page summary without including any finding.

## 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.

Unknown until SourceX reviews the opportunity: which records the company has rights to license, how security-sensitive details would be removed or generalized, whether buyers want this record type, and any offer. A partner does not need to see an exception, a scan or a ticket to make the introduction. Partners sign the Channel Partner Agreement before submitting introductions; the first valid introduction within the 90-day window is credited when the company submits a verified application.

Illustrative, for scale only: a qualifying completed handoff for which SourceX pays the company $40,000 would produce a default reward of $10,000 (25% of the Actual Supplier Payout, well under the $100,000 cap). 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. That is the published formula applied to a made-up number, not a forecast or a quote. Why exception records matter to AI developers is covered in [exception handling data for AI agents](/guides/exception-handling-ai-agents-data) and [why AI agents need work data](/proof/ai-agents-need-work-data); a related security workflow is [false-positive investigation closure](/guides/workflow-false-positive-investigation-closure).

## Go deeper on vulnerability exception renewal

- [Vulnerability exception renewal exception examples](/guides/vulnerability-exception-renewal-exception-examples): worked cases of exceptions that outlived their controls.
- [Vulnerability exception renewal records across systems](/guides/vulnerability-exception-renewal-records-across-systems): a map of the IDs that join scanner, GRC and ticketing records.
- [Who can license vulnerability exception renewal records](/questions/who-can-license-vulnerability-exception-renewal-records): a short answer on which executive to introduce.
- [Vulnerability exception renewal referral brief template](/resources/vulnerability-exception-renewal-referral-brief-template): a fill-in brief for the introduction itself.

## 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 client is consolidating risk platforms and its exception renewals still trace back to control evidence, [register as a partner](/register), confirm the company against [who qualifies](/who-qualifies), and keep the [program terms](/terms) beside the one-page handoff. Other sectors are on the [industries hub](/industries).

## Sources

- https://refer.sourcex.si/terms
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf
- https://learn.microsoft.com/en-us/defender-vulnerability-management/tvm-exception
- https://learn.microsoft.com/en-us/defender-vulnerability-management/tvm-exception-overview
- https://docs.tenable.com/vulnerability-management/MicroContent/Resources/MicroContent/TioMicroContent/accept-rules.htm