# Vulnerability exception records: who says yes | SourceX

Canonical: https://refer.sourcex.si/questions/who-can-license-vulnerability-exception-renewal-records
Last updated: 2026-10-19

Introduce the CEO, who can authorize a discussion about company records, and name the risk owner or CISO as the person who knows where the exceptions live. The risk owner approved or delegated each renewal, which makes them the right first conversation, but accepting a security risk is a different power from agreeing to discuss licensing records about it. Counsel reviews what the records reveal.

This decision tree belongs to the [vulnerability exception renewal guide](/guides/workflow-vulnerability-exception-renewal), which covers what to inventory before risk platforms consolidate. Here the only question is whose yes a partner needs before submitting an introduction.

## Why the risk owner opens the door but rarely signs

The risk owner is where the conversation starts because they are the only person who can describe the whole chain without opening a tool: which exceptions exist, how many were renewed, where the compensating-control proof sits and which platform is being retired. NIST's patch guidance frames exceptions as risk responses (accept, mitigate, transfer or avoid), and the risk owner is the person who chose among them.

That authority is narrow. In NIST's vocabulary, an authorizing official formally assumes responsibility for operating a system at an acceptable level of risk. The power is about running systems, and it says nothing about commercial use of the paperwork those decisions created. Exception records are company records. A decision to explore licensing them is a commercial decision that binds the company, so it sits with the CEO.

A useful question in conversation: ask the risk owner, "Would you raise this with the CEO, whose approval a discussion about these records needs?" A yes moves the introduction forward.

## The yes-path, node by node

Work through the nodes in order. Each one either moves you forward or adds a reviewer. The graphic shows the same path.

| Node | Question to answer | If yes | If no or unclear |
|---|---|---|---|
| A. Starting contact | Is there a named risk owner, CISO or head of IT risk who approved the exceptions? | Talk to them first; go to B | Ask who chairs exception reviews; go to B once named |
| B. Whose systems | Do the exceptions cover only the company's own systems? | Go to C | The company manages clients' systems; go to D |
| C. Executive owner | Is the company's own CEO the one to authorize a discussion about these records? | Go to E | In a group, ask which entity's CEO speaks for the records; go to E |
| D. Client records | Do client contracts say who controls security records about client environments? | Counsel reads them; go to E | Leave it as unknown for counsel and SourceX's review; go to E |
| E. Counsel review | Has general counsel been told the discussion would involve security exception records? | Go to F | Suggest the CEO brings counsel in early; go to F |
| F. Authorized contact | Has one named person agreed to take the introduction? | Submit the introduction | Do not submit yet |

Most product and services companies that run their own infrastructure travel A, B, C, E, F. Managed security providers and hosting companies almost always detour through D, because their exception registers record decisions about systems their clients own. The [MSP data licensing page](/industries/refer-managed-service-providers-data-licensing) explains why client contracts sit at the center for service firms, and the [false-positive closure guide](/guides/workflow-false-positive-investigation-closure) covers a related managed-service workflow.

## Who holds which part of an exception's history

| Role | Part of the record they hold | Authority over a licensing discussion |
|---|---|---|
| Risk owner or CISO | Approvals, renewal decisions, the exception policy | Starting contact; recommends, does not decide |
| GRC or vulnerability management lead | Platform administration, exports, the consolidation project | None; technical access is not authority |
| Head of IT or infrastructure | Change tickets and test results proving a control existed | Informs; does not approve |
| General counsel | Confidentiality terms, client and regulator obligations | Advises; must review before records are discussed |
| CEO | Commercial priorities and company commitments | Authorizes the discussion, within contract limits |

Platforms label decisions with codes. Microsoft's exception tooling, for example, records justifications such as third-party control, alternate mitigation, risk accepted and planned remediation. Those codes tell a reviewer what kind of decision it was. They do not tell anyone who may license the record, which is why the table separates holding a record from authority over it.

## When counsel, clients or auditors join the path

**Security posture.** An exception register is a list of known weaknesses the company chose not to fix on schedule, plus the reasoning. Even described at a high level, it reveals posture. Counsel will want to decide what can be generalized, removed or withheld, and that decision belongs inside SourceX's review, not in a partner's email.

**Client environments.** For a managed provider, an exception on a client's server is a record about that client. The contract decides what the provider may do with it, and counsel reads the contract.

**Audit and insurance trails.** Exceptions often appear in audit evidence and cyber insurance answers. Teams that have just completed a [cyber insurance renewal questionnaire](/guides/cyber-insurance-renewal-questionnaire) know where that evidence lives, but an insurer or auditor having seen records does not change who owns them.

**Sale or acquisition.** If the company is being prepared for sale, the [guide to selling a cybersecurity company](/guides/how-to-sell-a-cybersecurity-company) is a reminder that diligence teams also read these records, and the executive running that process may want to sequence any licensing discussion around it.

## What the tree leaves open until SourceX's rights review

The tree tells a partner whom to introduce. It does not settle any of the following, and a partner should not try to:

- whether the company holds the rights to license each record class, especially records about client systems
- how asset names, vulnerability identifiers and control details would be removed or generalized
- whether there is buyer interest in exception renewal histories, and on what terms
- whether any offer follows

[Why data rights matter](/proof/why-data-rights-matter) explains in general terms why a clean answer on ownership decides whether a discussion goes anywhere.

The introduced 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. Partners keep discovery at metadata level, never ask for exception records, scan results or logins, and sign the Channel Partner Agreement before submitting introductions. Credit goes to the first valid introduction within the 90-day window, recorded when the company submits a verified application. The [referral brief template](/resources/vulnerability-exception-renewal-referral-brief-template) has a line for the executive the tree points to.

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

Once the tree has led you from the risk owner to the CEO, who has agreed to talk, [register as a partner](/register), confirm the company against [who qualifies](/who-qualifies) and read the [program terms](/terms) before you submit.

## Sources

- https://refer.sourcex.si/terms
- https://csrc.nist.gov/glossary/term/authorizing_official
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf
- https://learn.microsoft.com/en-us/defender-vulnerability-management/tvm-exception-overview