Safeguard
Compliance•

SI-2 vs RA-5: flaw remediation and vulnerability scanning are two controls

NIST 800-53 splits finding vulnerabilities (RA-5) from fixing them (SI-2). Here is what each control asks for and how to keep evidence for both of them.

Safeguard Security Team
4 min read

In NIST SP 800-53, RA-5 is about finding vulnerabilities and SI-2 is about fixing them. RA-5 asks you to monitor and scan, analyze the results and remediate within a set time. SI-2 asks you to identify, report and correct flaws and install updates in a defined window. Auditors test them together.

What RA-5 asks

The Rev. 5 text of RA-5, Vulnerability Monitoring and Scanning, requires the organization to:

  • monitor and scan for vulnerabilities in the system and hosted applications, on a defined frequency and when new vulnerabilities are reported
  • use tools that support interoperability and automate parts of the process, using standards for naming platforms and flaws, formatting checklists and measuring impact
  • analyze scan reports and results
  • remediate legitimate vulnerabilities within a defined time, following a risk assessment

An enhancement, RA-5(2), asks that the list of vulnerabilities being scanned be updated on a defined basis. All of this sits in the low, moderate and high baselines.

What SI-2 asks

SI-2, Flaw Remediation, asks the organization to:

  • identify, report and correct system flaws
  • test updates for effectiveness and side effects before installation
  • install security-relevant updates within a defined period after release
  • fold flaw remediation into configuration management

SI-2(2), automated flaw remediation status, adds a requirement to determine with automated mechanisms whether components have applicable updates. It is in the moderate and high baselines.

Where teams get confused

The two controls share a gap: the time limits are organization-defined parameters. The control text does not say 30 days or 15 days. The program or agency fixes the numbers, so ask for them.

A second confusion is evidence. RA-5 evidence is scan configuration, scan results and analysis. SI-2 evidence is tickets, merged fixes, test results and install records. A clean scan proves little about SI-2, and a patch record proves little about RA-5.

An evidence set that covers both

  1. A scan policy that states scope, frequency and triggers.
  2. The scan output, kept with a date.
  3. A triage record showing who judged each finding and why.
  4. A link from each fix to the finding it closes.
  5. Test results from before the update was installed.
  6. A report of open findings against the deadline.

Handling findings you do not fix

Some findings are not exploitable in your code path, or have no fix. Record the decision, the reason and a review date. That is evidence of analysis, which RA-5 asks for, and it feeds a plan of action when a fix is genuinely pending.

Try it yourself

Open the vulnerability management demo and follow one finding from detection to closure. Look for the points where a record is created that you could later show an assessor.

Click through it at your own pace, or open it full screen.

Quick check

Which control sets the patch deadline?

SI-2 and RA-5 both refer to defined time periods, but the values are set by the organization or program, not by the base control text.

Does a clean scan satisfy SI-2?

No. SI-2 needs evidence that flaws were corrected and updates installed, not only that a scan came back clean.

Safeguard's SBOM and dependency scanning, reachability analysis and policies and gates help with the scan, triage and record side. Autonomous remediation with fix PRs is off by default. A free scan is at gold.safeguard.sh/scan.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.