Vulnerability Detection & Response¶

This document establishes the organization's policy for detecting, evaluating, and responding to vulnerabilities in the system, and the procedures by which GRC-ITSM executes that policy. It covers detection and ingestion from all sources, automated and human evaluation, Issue tracking with remediation SLAs, the Vulnerability Deviation process that governs all human risk judgment, accepted vulnerabilities, escalation to incident, and vulnerability reporting. It implements the FedRAMP Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rule families from the FedRAMP Consolidated Rules for 2026.

Download the KB article (Markdown)

Framework applicability¶

FedRAMP 20x classes differ in cadence and validation depth, not in the procedure itself; the Organization-Defined Values table carries the Class C values, with per-class variances noted.

Policy¶

• P-1. Persistent detection. The organization systematically, persistently, and promptly discovers and identifies vulnerabilities in the system using appropriate techniques, including scanning, configuration checks, threat intelligence, assessment findings, and automated control testing (VDR-CSO-DET).
• P-2. Persistent response. All detected vulnerabilities are tracked, evaluated, monitored, mitigated, remediated, and reported through GRC-ITSM until final disposition (VDR-CSO-RES).
• P-3. Every finding is evaluated. Every detected vulnerability is evaluated for exploitability, internet reachability, and Potential Agency Impact (PAIN) (VER-EVA-ELX, VER-EVA-EIR, VER-EVA-EPA). Concluding that exploitation of a vulnerability cannot be automated requires evidence proving it (VER-EVA-AIA); absent that evidence, the evaluation carries no assumption in the organization's favor.
• P-4. One governed pathway for risk judgment. Any change to a vulnerability's machine-assigned rating or disposition (risk adjustment, false-positive determination, mitigation credit, acceptance) is made only through a documented, approved Vulnerability Deviation. There is no informal path.
• P-5. Failures are vulnerabilities. Problems or failures with the detection and response process itself are treated as vulnerabilities and enter this same pipeline (VDR-CSO-FAV).
• P-6. Acceptance is explicit. A vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation is categorized as an accepted vulnerability, evidenced by an approved Vulnerability Deviation carrying the rationale (VER-TFR-MAV).
• P-7. Full disclosure, responsibly. Vulnerability activity is reported to all necessary parties persistently, in human-readable formats at least monthly and machine-readable formats persistently, without irresponsible disclosure of exploitable detail (VER-RPT-PER, VER-TFR-MHR, VER-TFR-MRH (SHOULD), VER-RPT-NID).

Organization-defined values¶

Roles and responsibilities¶

• Anyone may report a vulnerability or submit a Vulnerability Deviation.
• Assigned agent (Issues). Each Issue is assigned an agent as the primary person responsible for tracking remediation or mitigation. Assignment is automatic via the Agent Assignment - Issue Tickets role. Assignment confers tracking ownership, not approval authority.
• Assigned agent (Deviations). Each Vulnerability Deviation is assigned a tracking owner via the Agent Assignment - Deviations role.
• Deviation Approvers CAB. The Approver - Deviations role grants membership to the Deviation Approvers CAB, who approve deviations. Approval is always by the CAB, never by the assigned agent.
• ISSO and System Owner. Accountability and escalation; the ISSO reviews this document at least annually and the System Owner approves it.

Detection and ingestion¶

Findings are ingested and normalized from all detection sources (vulnerability scanners and configuration checks, for example AWS Inspector, Qualys, Nessus, Microsoft Defender) into one record shape in GRC-ITSM. On ingest, the pipeline automatically:

1. queries the CISA KEV catalog and threat-intelligence feeds (for example GreyNoise) to determine exploitability;
2. correlates the finding against inventory data to determine internet reachability;
3. assigns a preliminary PAIN rating from these evaluations.

Findings deduplicate on asset and finding, and group under one umbrella per distinct CVE or weakness (VER-EVA-GRV), so the VDR/VER rules apply to the consolidated grouping.

Evaluation¶

Evaluation is two-tier:

• Automated preliminary evaluation at ingest produces the exploitability and internet-reachability determinations and the preliminary PAIN rating, within the evaluation deadline.
• Human judgment may override any machine-assigned determination, but only through the Vulnerability Deviation process below. An Issue's rating is therefore always either machine-assigned or CAB-approved.

Issue tracking and SLAs¶

• Issue (per asset). One Issue per (asset x finding), carrying the asset link, detection source and time, and evaluation results. The remediation SLA clock runs here.
• Categorization. Every Issue carries a category that differentiates the kind of finding and the affected layer: Continuous Monitoring covers Vulnerability (Code, Container, Database, Operating System, Web Application, KSI), Misconfiguration (Container, Database, Network Device, Operating System), and Flaw Remediation; Documentation and Security Assessment cover non-technical findings. The category distinguishes scanner vulnerabilities from configuration findings from failed KSI checks in triage and reporting, and drives the automatic attribution of controls, requirements, KSIs, FedRAMP rules, and CMMC practices to the ticket per (ticket type x category), scoped to the system's authorized baselines.
• Issue Parent (per CVE/weakness). The umbrella grouping all per-asset children of one distinct weakness; its status rolls up from its children.
• SLA assignment. Each Issue receives the Remediation SLA for the system's Certification Class, with priority set by the PAIN rating and the evaluation flags (for example PAIN5: LEV+IRV). The Class Remediation SLAs implement the VDR-TFR-PVR remediation ladder: the target is reduction to a lower PAIN rating within the timeframe, factoring internet reachability and likely exploitability.
• KEV findings carry the CISA catalog due date, which is enforced independently of the PAIN ladder and survives full mitigation (VDR-TFR-KEV).
• Closure. When a finding is remediated and no longer appears in scans, the child Issue closes automatically; the umbrella closes when its last child closes.

Vulnerability Deviations¶

All human risk judgment rides in the Vulnerability Deviation process: risk adjustment (PAIN re-evaluation), false-positive determination, mitigation credit, and acceptance.

Deviation types¶

Process¶

1. Submission. Anyone may submit a deviation. The deviation records the vulnerability information, deviation type, Requested Risk Rating on the PAIN scale (for example PAIN3: NLEV), adjusted CVSS score where applicable, rationale, evidence description with attachments (for example vendor advisory, network segmentation diagram, scan output), and an operational impact statement where applicable.
2. Review and approval. The deviation moves New -> In Review -> Approval -> Finalized. The Approval stage runs the approval process with the Deviation Approvers CAB. Finalized is terminal for approved and rejected deviations alike; the disposition lives in the approval outcome. Finalized deviations may be re-opened.
3. Effect of approval. The approved rating, flags, and status propagate automatically to every Issue the deviation covers, and each Issue's priority is remapped against its Remediation SLA at the adjusted rating: the remediation clock is re-baselined to the approved tier.
4. Effect of rejection. The covered Issues keep their original machine-assigned rating and SLA, unchanged.
5. No re-review. Deviations do not expire and are not periodically re-reviewed; a deviation remains in effect until re-opened.

Deviation decisions are internal governance: the FedRAMP Consolidated Rules contain no FedRAMP approval gate for provider vulnerability determinations. The compliance-critical outputs are the recorded determinations, rationale, evidence, approver, and timestamps, which feed the vulnerability reporting below.

Accepted vulnerabilities¶

A vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation is categorized as an accepted vulnerability (VER-TFR-MAV). Identification of candidates is a deliberate human activity: a user finds Issues approaching or past the boundary and creates a documented Vulnerability Deviation for them. Accepted vulnerabilities are reported with their acceptance rationale in the Accepted Vulnerability Info reporting until fully mitigated or remediated (VER-RPT-AVI).

Escalation to incident¶

Two boundaries send a vulnerability into incident handling, both enforced by the deployed escalation runbook and both implemented as binding internal policy:

• An internet-reachable, likely exploitable vulnerability with a PAIN rating above 3 is treated as a FedRAMP Reportable Incident until it is at least partially mitigated to PAIN 3 or below (VER-TFR-IRI, SHOULD at Class C).
• A likely exploitable vulnerability that is not internet-reachable and is rated PAIN 5 is treated as a FedRAMP Reportable Incident until it is at least partially mitigated to PAIN 4 or below (VER-TFR-NRI, MAY at Class C).

The runbook reads the current rating, so an approved Vulnerability Deviation that adjusts the rating adjusts the escalation. Incident handling then follows the Incident Response Policy and Procedures.

Remediation and verification¶

Remediation of production resources follows the Change Management Policy and Procedures; patch-window Change Requests parent the vulnerability Issues they remediate to preserve traceability. Issues close on scan evidence of remediation, not on change completion.

Reporting¶

All vulnerability reporting is served through the Trust Center in human-readable and machine-readable formats, following the FedRAMP schemas:

• Monthly activity report (VER-TFR-MHR) covering all detection and response activity since the previous report (VER-RPT-PER), with the required per-vulnerability detail (VER-RPT-VDT, Vulnerability Detail Report schema) and accepted-vulnerability information (VER-RPT-AVI, Accepted Vulnerability Info schema).
• Machine-readable historical activity updated persistently for automated retrieval (VER-TFR-MRH, SHOULD; Historical Vulnerability Evaluation and Reporting Activity schema).
• Reporting discloses sufficient information for risk-based decisions without irresponsibly disclosing exploitable detail (VER-RPT-NID).

Automated validation evidence¶

Operating this process produces machine validation evidence automatically: evaluation coverage checks verify every open vulnerability carries a completed evaluation, deviation approvals write dated validation runs, and remediation SLA outcomes accumulate as evidence against the applicable KSIs and FedRAMP rules. Failures of the pipeline itself surface as failed validation checks and open Issues on this same pipeline (P-5).

Authority, review, and revision¶

Issued under the authority of the System Owner and binding on all personnel with access to the system. Exceptions require written System Owner approval. The ISSO reviews this document at least annually and when frameworks, the system, or lessons learned warrant; the System Owner gives final approval.

FedRAMP coverage¶

VDR provider rules: Vulnerability Detection, Vulnerability Response, Failures Are Vulnerabilities, Automate Detection, Detect After Changes, Avoid KEVs, Sampling, Maintain Security, Design For Resilience (VDR-CSO); detection and verification cadences, remediation expectations, KEV remediation (VDR-TFR). VER provider rules: exploitability, internet-reachability, PAIN, automatability, grouping, false positives, evaluation factors (VER-EVA); persistent reporting, vulnerability details, accepted vulnerability info, responsible disclosure, high-level overviews, responsible public disclosure (VER-RPT); evaluation deadline, monthly report, historical activity, accepted-vulnerability boundary, incident boundaries (VER-TFR). Underlying NIST: RA-5, SI-2. CMMC: RA.L2-3.11.2, RA.L2-3.11.3, SI.L1-3.14.1.