This page is the system map for the vulnerability exception renewal guide, which covers what to inventory before platforms merge. Here the question is mechanical: which tool holds each record, which ID links it, and who runs the tool.
Where each exception record lives
| System | Records it holds | Linking key it carries | Owner |
|---|---|---|---|
| Vulnerability scanner | Findings, scan history, sometimes exceptions or accept rules | Vulnerability ID (CVE or plugin ID), asset ID | Vulnerability management |
| Asset inventory or CMDB | Asset records, device groups, business owner | Asset ID, device group name | IT operations |
| GRC platform | Exception requests, approvals, renewals, review notes | Exception ID, plus the vulnerability and asset it covers | Risk owner, GRC lead |
| Change management | Tickets that create, alter or remove controls | Change ticket number, rule or configuration ID | IT infrastructure, network |
| Project tool | Remediation or replacement projects | Project ID, sometimes the exception ID | IT director or project office |
The vulnerability key is the most stable. The CVE Program's rules describe a CVE ID as what lets multiple parties discuss and share information with confidence that they are referencing the same vulnerability. Asset keys are less stable: they belong to whichever scanner or inventory issued them and change when tools are replaced or device groups are rebuilt.
The four joins and how they fail
| Join | From | To | Key | How it fails |
|---|---|---|---|---|
| 1 | Scanner finding | Exception | Vulnerability ID plus asset ID or device group | A new platform assigns new asset IDs; device groups are rebuilt |
| 2 | Exception | Its renewal | Exception ID, or scope plus dates | Some tools create a new record at each renewal rather than extending the old one |
| 3 | Exception | Control evidence | Change ticket number cited in the justification | Justifications describe the control in words, or not at all |
| 4 | Exception | Closure | Vulnerability ID, asset ID, closure date | Closed exceptions are left behind when only open ones migrate |
Join 2 depends on tool design. Microsoft documents that an exception in Defender Vulnerability Management applies for a set duration and scope and that its duration cannot be extended: continuing it means creating a new exception, so a two-year history is several records that share only scope and dates. Microsoft also lets exceptions apply globally or to specific device groups, which means join 1 may run through a group rather than a single asset. Tenable documents that accept rules can expire after a number of days or on a set date, and that on expiry the risk is no longer accepted while historical scan results stay unchanged. In both cases the renewal chain exists only if someone can line the records up.
Join 3 is the one that matters most for evidence. NIST's patch management guide says organizations should verify that added mitigating controls work. A renewal that cites the change ticket and attaches a test can be checked years later; one that says "segmented" cannot.
One exception joined across five systems (Illustrative)
Illustrative. A fictional 600-person regional logistics firm runs a customer portal that depends on a vulnerable open-source library. The portal vendor cannot ship a compatible upgrade for nine months. All IDs below are invented.
| Step | Record | System | Key that carries it forward |
|---|---|---|---|
| 1 | Finding: vulnerable library on the portal servers | Scanner | CVE ID; asset group PORTAL-PROD |
| 2 | Asset group confirmed, business owner named | Asset inventory | PORTAL-PROD, three asset IDs |
| 3 | Exception approved for 120 days; control is a web application firewall rule blocking the exploit path | GRC platform | EX-2291, citing the CVE ID and PORTAL-PROD |
| 4 | Firewall rule deployed and tested | Change management | CHG-51870 with rule ID, cited in EX-2291 |
| 5 | Renewal at day 120 with a retest of the rule | GRC platform | EX-2391, citing EX-2291 and CHG-51870 |
| 6 | Vendor upgrade scheduled | Project tool | PRJ-118, citing EX-2391 |
| 7 | Upgrade deployed; scanner shows finding resolved; exception closed | Scanner, GRC platform | CVE ID, PORTAL-PROD, EX-2391 closed |
Every join holds because each record names the key before it. Remove the ticket number from step 3, and the firewall rule can only be found by searching change tickets for "portal" in the right week. Remove "citing EX-2291" from step 5, and the renewal looks like a fresh exception. The worked example shows what happens when a control disappears and the chain is all that reveals it.
A join test the security team can run
A partner never needs to see an exception to learn how well the chains hold. Ask the security team to pick twenty exceptions that were closed or expired at least a year ago, at random, and report three counts:
- Chains that rebuild by ID alone, from finding to closure.
- Chains that need one match by date, scope or wording.
- Chains that break, usually at join 3.
Ask for the counts and the weakest join, never the records. SourceX publishes no benchmark for a good result. Security teams that have answered a cyber insurance renewal questionnaire often know already where the control evidence sits.
Who owns each system, and what the partner can confirm
Running a tool is not the same as owning its records or being able to license them. The risk owner approved each exception; the network team holds the change tickets; the CISO or head of IT risk usually knows how all five tools fit together. A licensing discussion is a company decision, covered in who can license these records.
At metadata level the partner can confirm which of the five systems exist, how many years each covers, roughly how many exceptions and renewals a year, whether exceptions cite change tickets, and the results of the join test. The company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license 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 it: whether customer contracts or regulators limit use of security records, how asset names and vulnerability details would be generalized, buyer interest and any offer. Partners sign the Channel Partner Agreement before submitting introductions. Investors screening several companies can use the portfolio data opportunity scanner; advisors to security firms may find how to sell a cybersecurity company and MCP for vendor due diligence useful context.
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's join test shows most exceptions still rebuild by ID from finding to closure, register as a partner, check the company on who qualifies and read the terms before you introduce the risk owner.