<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: implementing-vulnerability-exception-process
description: >-
  Design and operate a vulnerability exception management process including
  risk acceptance workflows, compensating controls documentation, time-bound
  approvals, and exception aging dashboards.
domain: cybersecurity
subdomain: vulnerability-management
tags:
  - exception-management
  - risk-acceptance
  - compensating-controls
  - vulnerability-management
  - governance
  - sla-exception
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: []
---

# Implementing Vulnerability Exception Process

## Overview

Not every vulnerability can be patched immediately. Business constraints, legacy
systems, and third-party dependencies require a formal exception process. This skill
covers exception request workflows, risk acceptance criteria, compensating control
requirements, approval authority matrices, and exception lifecycle management with
automatic expiration and re-review.

Mode: `[MODE: BLUE]` — Governance and operational vulnerability management.

## Prerequisites

- Vulnerability management platform with exception tracking
- Ticketing system (Jira, ServiceNow) for approval workflows
- Python 3.10+ with `requests`
- Defined risk acceptance authority matrix

## Key Concepts

### Exception Types

| Type | Description | Max Duration | Approval Authority |
|------|-------------|-------------|-------------------|
| Risk Acceptance | Business accepts residual risk | 90 days | VP+ |
| Compensating Control | Alternate mitigation in place | 180 days | Director+ |
| False Positive | Scanner misidentification | Permanent | Security Analyst |
| Deferred Patch | Scheduled for next window | 30 days | Team Lead |
| End of Life | System pending decommission | 90 days | VP+ |

### Exception Request Requirements

```
Required fields for every exception:
├── CVE/vulnerability ID
├── Affected asset(s) and business criticality
├── Justification — why remediation cannot occur within SLA
├── Compensating controls — what mitigates the risk
├── Expiration date — when exception must be re-reviewed
├── Business owner — who accepts the residual risk
├── Risk assessment — residual risk with compensating controls
└── Monitoring — how exploitation attempts will be detected
```

### Compensating Controls Framework

```bash
# Example compensating controls by vulnerability type:
# RCE vulnerability → WAF rule + network segmentation + enhanced logging
# Privilege escalation → Restricted access + monitoring + scheduled patch
# Information disclosure → Data masking + access controls + DLP
# DoS vulnerability → Rate limiting + CDN + auto-scaling

# Document control effectiveness:
# Control: WAF rule blocking CVE-2024-6387 exploit pattern
# Coverage: 100% of internet-facing traffic
# Bypass risk: Medium — sophisticated attackers may evade signature
# Monitoring: WAF logs ingested to SIEM with alert on block events
# Expiration: Must patch before WAF rule exception expires
```

## Workflow

### Step 1: Submit Exception Request

```bash
node scripts/agent.js --action create-exception \
  --cve CVE-2024-6387 \
  --asset web-prod-01 \
  --type compensating-control \
  --justification "Third-party dependency update pending vendor release" \
  --output /tmp/exception_request.json
```

### Step 2: Review Pending Exceptions

```bash
node scripts/agent.js --action list-pending \
  --output /tmp/pending_exceptions.json
```

### Step 3: Audit Exception Aging

```bash
node scripts/agent.js --action audit \
  --input /tmp/exceptions_db.json \
  --output /tmp/exception_audit.json
```

### Step 4: Expire Overdue Exceptions

```bash
node scripts/agent.js --action expire \
  --input /tmp/exceptions_db.json \
  --output /tmp/expired_exceptions.json
```

## Verification

- [ ] Exception process documented and approved by CISO
- [ ] All exceptions have defined expiration dates
- [ ] Compensating controls documented and validated
- [ ] Business owner sign-off required for risk acceptance
- [ ] Exception dashboard shows aging and upcoming expirations
- [ ] Expired exceptions automatically revert to active remediation queue
- [ ] Quarterly exception review conducted by security leadership

## References

- [NIST SP 800-53 Rev 5 — RA-7: Risk Response](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
- [CIS Controls v8 — Control 7: Continuous Vulnerability Management](https://www.cisecurity.org/controls)
- [PCI DSS 4.0 — Requirement 6.3: Security Vulnerabilities Are Identified and Addressed](https://www.pcisecuritystandards.org/)
