AO coverage. Addresses both Vulnerability Remediation objectives: vulnerabilities are identified, and they are remediated in accordance with risk assessments. The second half is the point of this pattern — the remediation clock is derived from the risk register's asset criticality tiers and from real-world exploitation signal, not from the vendor's base score alone.

Identification and deduplication. Findings arrive from InsightVM host and web scans, the annual penetration test, vendor advisories, the internal report inbox, and cloud provider findings. All of them normalize into one Jira Service Management queue keyed on CVE plus asset, so a single CVE across 200 hosts is one work item with 200 instances and one owner rather than 200 tickets that get closed individually and re-created next week. Duplicate suppression is by finding fingerprint; suppressions expire after 90 days so a silenced finding resurfaces for a decision.

Risk-adjusted prioritization. Base severity sets a starting tier, then documented adjustments move it. Upward: presence in the CISA KEV catalog, EPSS above our threshold, the asset being internet-reachable, the asset processing CUI, or the asset being a security protection asset such as the identity provider, scanners, or log pipeline. Downward: a compensating control that has been verified rather than merely asserted — segmentation confirmed by an actual rule review, the vulnerable feature disabled and the configuration checked, or authentication required in front of the exposure. The adjustment reason is a required field, which means somebody has to write down why a 9.8 became a 30-day item, and that field is exactly what an assessor reads.

The clocks. Emergency at 72 hours for KEV-listed findings on internet-facing or CUI-processing assets, with an out-of-band change authorized by the ISSO. Then 7 days, 30 days, and 90 days for the remaining tiers, measured from finding detection rather than from ticket triage, because triage delay used to eat a third of the window silently. A monitor tier holds findings we are deliberately not fixing yet; it is a decision with an owner and an expiry, not a holding pen.

Remediation paths. Four are permitted and each has different paperwork: patch or upgrade through the normal change process; configuration change or feature removal; a compensating control with an expiry date and a defined re-evaluation; or documented risk acceptance, which requires approval from the risk register owner for the affected asset, not from the engineer who does not want to do the work. Acceptances are time-bounded, capped at twelve months, and re-argued at expiry.

Closure requires proof. A ticket cannot close on a status of patch deployed. Closure requires evidence that the finding is gone — the next authenticated scan no longer reports it, or for a configuration change, a captured configuration state. If a later scan still sees the finding, the ticket reopens automatically with its original due date preserved so the aging metric reflects reality. This single rule surfaced a recurring case where patches installed but the service was never restarted, which had been reported as remediated for months.

Capacity handled openly. The monthly maintenance window has finite capacity. When the queue exceeds it, the overflow is explicitly deferred with a named approver and a revised date, and anything deferred past its tier clock goes to the POA&M with milestones. The alternative — letting items age quietly — produces the same outcome with none of the visibility, and it is what we were doing before.

Metrics reviewed monthly. Aging by tier, on-time completion percentage by tier, mean time to remediate for KEV-listed findings specifically, count of open acceptances past expiry, and reopen rate after closure. The reopen rate is the honesty check on the whole program; ours sat near 12 percent in the first quarter after we started verifying closure and is now under 4 percent.

Accepted gaps. Three network appliances carry findings with no vendor fix available; they are tracked as compensating-control items with a quarterly vendor follow-up documented in the ticket, and replacement is in the capital plan. One internal application on an end-of-life framework has an open POA&M item with a funded replacement date rather than a patch. Low-severity findings on isolated lab hosts are batched into the annual re-image instead of being remediated individually, which the standard states explicitly rather than leaving them to age against a clock nobody intends to meet.

• Remediation standard with the tier clocks and the documented upward and downward risk-adjustment factors
• Sample ticket showing base severity, the applied adjustment, the required reason text, and the resulting due date
• Verified compensating control record backing a downward adjustment (rule review or configuration capture)
• Closed ticket with the follow-up scan result proving the finding is absent, and an example of an auto-reopened ticket
• Risk acceptance memo with the risk register owner's approval and an expiry date
• Monthly metrics report covering aging, on-time percentage, KEV mean time to remediate, and reopen rate
• POA&M entries for deferred items and for the end-of-life application, with milestones and funding