This worked case belongs to the vulnerability exception renewal guide, which covers what to inventory before risk platforms consolidate. Here one exception is followed from start to finish.
The case: a licensing server nobody could patch (Illustrative)
Illustrative. A fictional 380-person engineering firm runs a license server for its design software. The software vendor still requires an older operating system, and a published vulnerability on that system cannot be patched without breaking the software. NIST's patch management guide names four responses: accept, mitigate, transfer or avoid. Dropping the software is not an option and no third party will carry the exposure, so the firm accepts the weakness and fences it off. The server is isolated on its own network segment behind a firewall allow-list, and the exception is approved for 180 days.
NIST's guide treats isolating an exposed asset as a valid response and says organizations should verify that added controls actually work. That sentence is the hinge of this case.
Step by step: who decided what, and which record caught it
| Month | What happened | Who decided | Record it left | Where it lives |
|---|---|---|---|---|
| 0 | Scanner reports the vulnerability on the server | No decision; automated | Finding with asset ID and vulnerability ID | Scanner |
| 0 | 180-day exception approved; control is segment plus allow-list | Risk owner (head of IT) | Exception request, justification, approver, expiry date | Risk register or scanner |
| 0 | Segmentation applied | Network lead | Firewall change ticket with rule ID | Change management |
| 6 | First renewal, after a reachability test passes | Risk owner | New exception record, test result attached | Risk register |
| 12 | Second renewal; justification copied forward, no new test | Risk owner | New exception record, no attachment | Risk register |
| 14 | Network refresh merges segments; allow-list rule removed | Network lead | Change ticket for the refresh, no reference to the exception | Change management |
| 18 | Third review: test finds the server reachable from user networks | Security analyst, escalated to the CISO | Review note, failed test, escalation | Risk register |
| 18 | Segmentation restored; replacement project approved | CISO and IT director | Emergency change ticket, project record | Change tickets, project tool |
| 19 | Retest passes; exception re-approved with a decommission date | Risk owner | Test evidence, new exception record | Risk register |
Three things make this chain readable years later. Each renewal is its own record, which is how some tools work: Microsoft documents that an exception in Defender Vulnerability Management has a set duration that cannot be extended, so continuing it means creating a new one. Each renewal either has a test attached or visibly does not. And the change tickets carry rule IDs that can be matched to the control the exception relied on.
The month-12 renewal, and why the sequence is evidence
The exception is the month-12 renewal. It was approved on a copied justification while the control was still in place, so on the day it was correct. Two months later the control disappeared in an unrelated network change, and the exception stood for four more months with nothing behind it. No single record shows the problem:
- The exception record at month 12 carries a tidy justification code and looks fine. Microsoft lists justification codes such as third-party control, risk accepted and planned remediation; a code says which kind of decision it was, not whether it still held.
- The change ticket at month 14 is a routine refresh with no mention of the server.
- The scanner kept reporting the same finding throughout, as it should, because the risk was accepted.
Only the sequence shows it: a renewal without a test, followed by a change that touched the control, followed by a review that caught the gap. That is the initial problem, the authorized action and the checked result, with a failure and recovery in the middle. It records how a company actually manages risk it cannot patch away, including the moment its process slipped and the moment it recovered.
Expiry behavior affects what survives. 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. A company that let exceptions lapse and re-created them may have scan history intact but gaps in the decision layer above it. The system map shows which keys join the scanner, risk register and change records.
Sequences like this are what make exception records useful for training and evaluating AI agents that do operational work: a judgment, the conditions attached to it, a change in the world, and the response. The exception handling explainer and why AI agents need work data give the wider case.
Recognizing similar cases at a client
A partner never sees the records, but a few questions show whether a company has histories like this one:
- Do you have assets you have accepted risk on for more than a year? Long-running exceptions on legacy systems, medical or industrial devices, or vendor-locked software are the usual source.
- Does each renewal carry a test result, or only a new expiry date? Either answer is informative; the point is whether it can be told.
- Do change tickets reference the exceptions they affect? If not, the month-14 type of event is invisible without a manual join.
- Has a review ever found a control that had stopped working? A yes means the company holds at least one full failure-and-recovery chain.
- How many years of exception history are readable, and in which tools? Expired and closed exceptions matter as much as open ones.
Procurement teams produce a similar approval-plus-outcome pattern, covered in the procurement approvals guide.
What the partner can confirm, and what stays unknown
At metadata level the partner can confirm the record classes, the tools, the years covered, rough volumes of exceptions and renewals, and who the risk owner is. Authority to license is a separate question; who can license these records covers it. 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, IP details and vulnerability identifiers would be removed or generalized, buyer interest and any offer. Partners sign the Channel Partner Agreement before submitting introductions. Advisors working with security firms may also find how to sell a cybersecurity company 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 answers suggest it holds renewal chains with tests, changes and at least one caught failure, register as a partner, check the company on who qualifies and read the terms before you introduce the risk owner.