Four exceptions your risk register hides behind one label
The risk register review starts the same way. Someone asks about the count of open exceptions, and the answer sounds reassuring until the follow-up breaks it. How many are boxes we cannot patch this quarter, how many are false positives that never got closed, how many are compensating controls with test evidence, and how many are business deferrals rolling forward on autopilot. Nobody can answer, because the register carries them all under one label. "Accepted risk" is doing work it was never designed to do.
Four different states hide behind that single flag. A vulnerability nobody can patch without breaking a device is not the same shape of problem as one the business will patch next quarter, and neither is the same as a finding blocked by a WAF rule or a scanner ghost that never applied. Different states need different approvals, different evidence, and different expirations, and squashing them together is how a governance program stays fiction while still passing the audit.
The taxonomies already exist, and none of them draws the line here
FedRAMP's POA&M process ships three deviation request types: False Positive, Risk Adjustment, and Operational Requirement. It draws two lines the community should copy: an Operational Requirement will not be approved for a High-severity finding, and vendor dependency is not a deviation type at all; it is a separate POA&M tracking status with required monthly vendor check-ins (Ignyte writes up the DR mechanics). NIST SP 800-37 rev 2 gives the RMF version: risk acceptance as a decision, POA&M as the ledger, continuous monitoring as the review cadence. The doctrine is right and the taxonomy is abstract by design, which is why every scanner vendor ships its own dropdown on top.
Rapid7 InsightVM exposes five exception reasons (False positive, Compensating control, Acceptable use, Acceptable risk, Other), and Microsoft Defender Vulnerability Management ships a six-way justification taxonomy (Third-party control, Alternate mitigation, Risk accepted, Planned remediation (grace period), Not enough time, Other). Both are dropdown labels on a single lifecycle; neither treats the choice as a routing decision that changes who approves the exception, what evidence it carries, or how often it comes up for review.
PCI DSS Appendix B earns credit at the framework level: it recognises a legitimate and documented technical or business constraint, and its compensating-controls worksheet requires the assessor to describe the constraint, the alternate control, the equivalent rigor, and the risk analysis. The taxonomy does real work; it just does not travel outside PCI. ArmorCode says the quiet part out loud: no vendor-neutral taxonomy treats these categories as distinct workflow states with different lifecycles, evidence, expiry cadences, and escalation paths. That is the ground still open.
The four workflow states, each with its own lifecycle
Technical infeasibility
The exception for systems that cannot be patched without breaking the service, voiding vendor support, disrupting regulated operations, or requiring a major upgrade path. Usual carriers are OT, medical devices under FDA constraints, vendor appliances, and legacy enterprise software behind a paid upgrade. The record has to carry the vendor constraint in writing, a compensating control with an owner, a business approval from someone with authority to accept residual risk, a durable-fix roadmap with a target date, and a re-review cadence tied to that roadmap. It must never carry an infinite expiration or an approver who is also the technical owner. This is the longest-lived exception and the one most likely to rot without review discipline.
Business deferral
The fix is possible; the business is delaying it for a release freeze, a maintenance window, a customer commitment, or a change calendar the vulnerability did not consult. Deferral should be short-lived; when it keeps renewing it is usually technical debt wearing a process label. The record is thinner but stricter: the reason, the approved window with a firm expiration, the interim controls in place, and a senior owner from the business unit that requested the delay. The second slip escalates rather than auto-renews.
Compensating control
The vulnerability remains, but something else in the path materially reduces exploitability: a WAF signature, a segmentation rule, a disabled feature, a source-IP allowlist, an identity restriction, or an EDR detection shown to fire under attack. This is where PCI Appendix B logic belongs, and where most registers are least honest, because the record has to include what most do not: validation evidence. A control nobody tested is a claim. Purple-team results, a BAS run against the specific exploit primitive, or a documented rescan through the blocked path is the minimum. Expiration is the earlier of the next validation run and the next change that could unseat the control.
False positive or not applicable
The finding does not apply. The banner is misidentified, the package is not installed, the fix was backported, the asset was retired, or the dependency exists only inside a build artifact that never ships. This is not an accepted risk at all, and treating it like one is where the register becomes fiction fastest. The record is proof of non-applicability: an inventory check, a version query, or a vendor advisory that confirms the pattern does not match. Approval is technical, the outcome is finding closure, and every false positive sitting in the exception queue is a number that misleads the next report.
A Rosetta stone across the frameworks
The vocabulary changes across tools and standards. The states do not.
| State | FedRAMP DR | NIST RMF | PCI DSS | InsightVM | Defender VM |
|---|---|---|---|---|---|
| Technical infeasibility | Operational Requirement (Mod and below) | Risk acceptance | Documented technical constraint | Acceptable risk | Third-party control |
| Business deferral | POA&M milestone (not a DR) | POA&M milestone | Documented business constraint | Acceptable use | Planned remediation |
| Compensating control | Risk Adjustment | Compensating control | Appendix B worksheet | Compensating control | Alternate mitigation |
| False positive | False Positive | Finding closure | Removed from ROC | False positive | Not applicable |
Two rows deserve a footnote. FedRAMP will not approve an Operational Requirement for a High-severity finding, so that combination has to route back to Risk Adjustment or accelerated remediation. Defender's "Not enough time" justification maps to none of the four; it is an admission the exception is not yet real, and it belongs in a scheduling ticket.
The minimum record every exception has to carry
The fields are the taxonomy, in a form the queue can enforce:
- Type, from the four states above, set by the workflow rather than a free-text field.
- Scope, as a list of specific assets or an inventory query that resolves to the current set.
- Business owner and technical owner, distinct roles even under the same manager.
- Reason, one or two sentences portable to an audit finding without further translation.
- Compensating control and validation evidence, required when the state is compensating control.
- Expiration as a date, never a boolean or a token like "ongoing".
- Review cadence, aligned to the state (quarterly for technical infeasibility, at every window boundary for business deferral, at every validation cycle for compensating control).
- Approver, chosen from a matrix the state selects, not the person filing the exception.
If any of those are missing, the exception is not yet mature enough to reduce SLA pressure. Enforcing the fields at intake is how workflow states become governance instead of a spreadsheet.
No expiration means no exception
An exception is a promise about the future, and every promise has a date. If a scanner exception, a POA&M item, or a compensating control statement does not carry an expiration, it is not an exception; it is a decision to stop tracking a problem. A tool that lets an operator file one without an expiration gives them permission to lose the finding, and "when patched" does not count as an answer, because that is the reason the finding was open. The corollary is a doctrine the queue can enforce: every exception gets an expiration, every expiration gets a review, and every review is a decision to renew, escalate, or close. An exception that renews for the third time without a durable-fix milestone escalates automatically to the risk owner, because the pattern has stopped being an exception and started being a policy.
Exceptions are a decaying asset
The register does not stay accurate on its own. Vendor patches drop and turn compensating controls into obsolete infrastructure. Configuration drift erodes a WAF rule that used to block the exploit path. Scanner rules update and false positives flip categories. A block that was good enough in March is a scoring layer stuck at "compensating control" in October, doing no work. This is where the register meets the exposure debt ledger: every unexpired exception with a stale validation date is debt accruing interest, and every business deferral rolling into its third window is principal that was never paid down.
CVEasy AI keeps exceptions attached to the local exposure record, tied to the TRIS layer they modify and to the validation evidence they depend on, so the four states stay separable inside the CTEM (Continuous Threat Exposure Management) loop instead of dissolving into a single "accepted risk" tag. One queue, four lifecycles, one honest count.