RA-5: Vulnerability Monitoring and Scanning

Quick-reference card

What this control requires

RA-05 requires you to continuously monitor and scan your systems and applications for vulnerabilities, then remediate what you find based on organizational risk. This control sits at the core of every security program because unpatched vulnerabilities remain the most reliable entry point for attackers, and scanning is the primary mechanism for finding them before exploitation occurs.

In practice, the requirement goes well beyond running a periodic scan. You need tooling that can enumerate platforms, catalog software flaws, identify misconfigurations, and measure the impact of each finding using standardized formats. Your scanning tools must stay current with the latest vulnerability definitions, and your organization must define how quickly legitimate vulnerabilities get remediated based on a risk-informed assessment. The control also mandates that you share scan results and control assessment findings with designated personnel so that similar weaknesses across other systems don’t go unaddressed.

Where most organizations fall short isn’t the scanning itself. It’s the gap between identifying a vulnerability and acting on it. RA-05 closes that gap by requiring defined response times tied to risk, analysis of scan reports rather than just generating them, and tooling interoperability that automates parts of the vulnerability management process through standards like SCAP, CVE, OVAL, and CVSS.

Why it matters

Most organizations have a vulnerability scanner. Far fewer have a vulnerability management process that actually prevents breaches. The distinction matters because a scanner that generates alerts nobody acts on provides a false sense of security, and that false sense has led to some of the most damaging data breaches in history.

Equifax Data Breach

On March 7, 2017, Apache disclosed CVE-2017-5638, a critical remote code execution flaw in the Apache Struts 2 framework. A patch was available the same day. Equifax had Struts running on a public-facing web application that consumers used to dispute credit report errors. The patch was never applied.

Beginning in mid-May 2017, attackers exploited the unpatched vulnerability to establish a foothold. They spent roughly ten weeks moving laterally through the network, accessing 48 distinct database tables across 51 days before the breach was discovered on July 29, 2017. Equifax had received an internal security scan alert about the vulnerability in March, but a misconfiguration in the scanning tool meant the alert was never acted upon. The FTC, CFPB, and a coalition of state attorneys general reached a settlement of up to $700 million.

The Senate Judiciary Committee’s investigation found that Equifax had known about the vulnerability for months and that the breach was “entirely preventable.” 147.9 million Americans had names, Social Security numbers, dates of birth, addresses, and in some cases driver’s license numbers and credit card numbers exposed. CEO Richard Smith resigned in the aftermath.

The Equifax breach is the most widely cited illustration of RA-05 failure. The vulnerability was publicly known, the patch was available, the exploitation technique was not novel, and the organization’s own processes were supposed to catch it. Every element this control requires, from scanning frequency to remediation timelines to tool configuration, failed simultaneously.

What attackers exploit when vulnerability monitoring breaks down:

• Unpatched known vulnerabilities in internet-facing applications, particularly web frameworks with published CVEs
• Misconfigured scanning tools that generate alerts no one reviews or that miss assets entirely
• Infrastructure devices like switches, routers, and printers that fall outside the scope of standard application scans
• Custom-developed software that isn’t subject to static analysis, dynamic analysis, or binary code review
• Gaps between scan frequency and the speed at which new exploits are weaponized in the wild

How to implement

Implementing RA-05 effectively means building a closed-loop process where every vulnerability that enters your environment gets identified, prioritized, and resolved within a defined timeframe. The most common failure isn’t a lack of tools. It’s a lack of process discipline connecting scan output to remediation action.

For your organization

Start by establishing scanning frequency based on your system’s security categorization. High-impact systems need more frequent scanning, and you should trigger additional scans whenever new vulnerabilities are disclosed that could affect your environment. NIST expects you to go beyond scheduled scans and respond to emerging threat intelligence.

Deploy vulnerability monitoring tools that use standardized formats for enumerating platforms (CPE), cataloging flaws (CVE), and scoring impact (CVSS). SCAP-validated tools ensure interoperability and consistent measurement across your environment. Your tools must also be capable of updating their vulnerability definitions rapidly, so you aren’t scanning against stale data.

Scan coverage must extend beyond servers and workstations. Include network infrastructure like switches, routers, firewalls, and printers. For custom-developed applications, supplement network-based scanning with static analysis (SAST), dynamic analysis (DAST), or binary code analysis. These techniques catch vulnerabilities that network scanners can’t detect.

Establish documented response times for remediation based on risk. A critical remote code execution vulnerability on an internet-facing system demands a different timeline than a low-severity finding on an isolated internal host. Track remediation progress against these timelines and escalate when deadlines are missed.

Analyze every scan report rather than filing it. Assign responsibility for reviewing results, validating findings against false positives, and routing legitimate vulnerabilities to the appropriate remediation team. Share findings with personnel across other systems so that similar vulnerabilities get addressed organization-wide.

Continuous monitoring programs can augment periodic scanning by using instrumentation-based approaches that detect configuration drift and new exposures between scheduled scans. Red team exercises and vulnerability disclosure programs, including bug bounties, provide additional coverage that automated tools may miss.

For your vendors

Request evidence that your vendors operate a mature vulnerability management program, not just that they run scans. Ask for their documented scanning policy, including how frequently they scan, what asset categories are covered, and what tools they use.

Verify that vendors define risk-based remediation timelines. A vendor that scans weekly but takes 90 days to patch critical vulnerabilities isn’t meeting the intent of RA-05. Ask for metrics on mean time to remediate by severity level and whether they track remediation against defined SLAs.

Review whether vendors include infrastructure devices and custom applications in their scanning scope. Many vendors scan servers and endpoints but exclude network equipment, IoT devices, or internally developed software. These gaps create blind spots that attackers target.

Request sample scan reports or summaries that demonstrate analysis, not just raw output. You want evidence that someone reviews the results, validates findings, and tracks remediation to closure. A vulnerability management tool that generates reports nobody reads doesn’t satisfy RA-05.

Ask whether the vendor participates in vulnerability disclosure programs or has a mechanism for receiving reports from external researchers. This signals maturity beyond basic scanning. Confirm that their scanning tools use current vulnerability definitions and that updates happen automatically rather than manually on an ad hoc basis.

Evidence examples

Cross-framework mapping

Related controls

• CA-02 — Control Assessments: defines the broader assessment process that vulnerability scan results feed into
• CA-07 — Continuous Monitoring: establishes the ongoing monitoring program that vulnerability scanning supports as a key data source
• CA-08 — Penetration Testing: provides active exploitation testing that validates whether vulnerabilities identified by scanning are actually exploitable
• CM-02 — Baseline Configuration: defines the approved system configurations that vulnerability scans measure deviations against
• CM-04 — Impact Analyses: requires analysis of changes that could introduce new vulnerabilities before they’re deployed
• CM-06 — Configuration Settings: specifies the security configuration parameters that scanners check for compliance
• CM-08 — System Component Inventory: provides the authoritative list of assets that must be included in vulnerability scanning scope
• RA-02 — Security Categorization: determines the security impact level that drives scanning frequency and remediation priority
• RA-03 — Risk Assessment: provides the risk context used to prioritize vulnerability remediation decisions
• SA-11 — Developer Testing and Evaluation: covers the static and dynamic analysis techniques used to find vulnerabilities in custom-developed software

Frequently asked questions

What is NIST SP 800-53 RA-05

RA-05 requires organizations to monitor and scan their systems for vulnerabilities at a defined frequency, analyze the results, and remediate legitimate findings based on risk. The control spans the full vulnerability management lifecycle, from maintaining current vulnerability definitions in your scanning tools to sharing findings with designated personnel so that similar weaknesses get addressed across other systems. It applies to all NIST SP 800-53 baseline levels and covers infrastructure, applications, and custom-developed software.

What happens if RA-05 is not implemented

Failure to implement RA-05 leaves known, patchable vulnerabilities in production systems where attackers can exploit them. The Equifax breach demonstrated exactly this failure mode, where a scanning tool misconfiguration meant a critical Apache Struts vulnerability went unpatched for months despite a fix being available. Without defined remediation timelines tied to your risk assessment process, vulnerability scan reports accumulate without driving action, and your organization loses the ability to demonstrate due diligence to auditors and regulators.

How do you audit RA-05

Auditing RA-05 starts with verifying that vulnerability scanning occurs at the organization-defined frequency and that scan coverage includes all system components in the asset inventory. Review vulnerability scan reports to confirm that results are analyzed, not just generated, and that legitimate findings are tracked through remediation with documented response times. Examine scanning tool configuration to verify that vulnerability definitions update automatically and that the tools support standardized enumeration formats like CVE, CPE, and CVSS for consistent measurement.

How often should vulnerability scans be performed under NIST 800-53

NIST SP 800-53 doesn’t prescribe a universal scanning frequency. Instead, RA-05 requires you to scan at an organization-defined frequency driven by your system’s security categorization. Higher-impact systems warrant more frequent scanning, and additional scans should be triggered whenever new vulnerabilities potentially affecting your environment are disclosed. Many organizations scan weekly or monthly on a scheduled basis while maintaining the capability to run ad hoc scans in response to newly published CVEs or threat intelligence alerts.