Trackr.Live The landing site for Trackr Services
§ Trackr.Live

RA — Risk Assessment

Risk Assessment is the control family that decides how hard every other family has to work. RA-2 sets your system’s impact level, and that single categorization decision is what the SP 800-53B baseline reads to hand you a starting control set. Get it wrong and every downstream family is either over-built or dangerously thin. The rest of RA is the machinery that keeps the risk picture current after the system is live: the scans, the criticality analysis, the risk decisions someone has to sign, and the threat hunting Rev 5 bolted on. Small by control count, outsized by leverage.

Schematic of a risk funnel: a wide field of scattered threat and vulnerability tokens narrowing through an impact-rating gate into a single prioritized risk decision feeding a tracked remediation queue.

A quick boundary, because people smear this. RA is not the assessment of controls (that is CA, the Security Assessment and Authorization family, CA-2 in particular). RA is the assessment of risk to the system: threats, vulnerabilities, likelihood, impact. The two get confused constantly in SSP prose because both contain the word “assessment,” and an assessor reading carefully notices when an RA narrative is actually describing CA work. RA-3 is the risk assessment, RA-5 is the scanning that feeds it, and the family runs on the SP 800-30 methodology.

Where RA sits in the RMF

RA-2 is special. It isn’t just a catalog control, it is the Categorize step of the SP 800-37 process made concrete. FIPS 199 gives you the method: rate confidentiality, integrity, and availability each as Low, Moderate, or High, then take the high-water mark for your overall impact level. That impact level is the input to Select, where SP 800-53B turns it into a baseline. RA-2 happens before almost everything else in the lifecycle, and it is the one control whose output every other family inherits.

RA-3 threads through differently. An initial assessment informs Select and the SSP, then it stays alive through the Monitor step as the system, the threat environment, and the scan results change. RA-5 scanning is continuous-monitoring fuel, feeding CA-7 and the POA&M on a cadence; RA-7 risk response is the decision layer on top.

What’s actually in the family

In Rev 5 the RA family runs RA-1 through RA-10, but that range includes a withdrawn control and two narrow situational ones, so the live working set is smaller than the numbering suggests.

  • RA-1, Policy and Procedures. The inherited -1. Org-level policy plus the procedures that operationalize the rest of the family. Pulled first in any assessment because everything else assumes it exists.
  • RA-2, Security Categorization. FIPS 199 in control form. Documents the C/I/A impact ratings and the overall categorization, with the rationale. This is the control that drives baseline selection, so an assessor reads it against the actual data the system handles, not against what the SSP wishes the system handled.
  • RA-3, Risk Assessment. The assessment proper, built on the SP 800-30 risk model: threat sources, vulnerabilities, likelihood, and impact combined into risk. RA-3(1) is the supply-chain risk assessment, which ties straight into the SR family and matters more every year.
  • RA-4 is withdrawn. It was “Risk Assessment Update” in older catalogs and got folded into RA-3, which now carries the update obligation itself. If your SSP still cites RA-4 as a live control, that’s a Rev 4 artifact someone forgot to retire.
  • RA-5, Vulnerability Monitoring and Scanning. Operationally the heaviest control in the family by a wide margin: scan cadence, authenticated scanning, signature currency (RA-5(2)), privileged scanning access (RA-5(5)), false-positive triage, the feed into remediation. More below, because it’s where most RA programs quietly fail.
  • RA-6, Technical Surveillance Countermeasures Survey. The TSCM sweep, the physical bug-hunt. Rarely allocated outside SCIFs and specific national-security contexts.
  • RA-7, Risk Response. The decision record. For each identified risk, the documented choice to accept, avoid, mitigate, transfer, or share it, with who signed. Short control text, large governance weight.
  • RA-8, Privacy Impact Assessments. A privacy-baseline control. Where PII is in play the PIA is the artifact, tied to the PT (PII Processing and Transparency) family. Situational relative to the security baseline, central if you process PII.
  • RA-9, Criticality Analysis. Identifies the components whose failure or compromise would hurt the most, so protection effort concentrates where it matters. Ties to SR, SA-15, and CP.
  • RA-10, Threat Hunting. A genuine Rev 5 addition: proactive, hypothesis-driven searching for adversary presence your alerting missed, distinct from reactive SOC alert-chasing. Ties to SI-4 and IR-4.

Baselines: where these controls come from

The baselines no longer live in SP 800-53. Rev 4 kept Low/Moderate/High allocations in the catalog’s Appendix D; Rev 5 split them into SP 800-53B, the document you tailor against. FIPS 199 sets categorization, FIPS 200 sets the minimum-security floor, and 800-53B turns the impact level into a starting set. National-security systems run CNSSI 1253 instead. FedRAMP and DoD (via DoDI 8510.01) layer overlays on top, and those overlays routinely tighten RA-5 scan cadence past the bare catalog requirement.

For RA, the core controls (RA-1, RA-2, RA-3, RA-5, RA-7) generally appear from Low up. RA-9 and many of the RA-5 enhancements come in at Moderate or High, and RA-10 tends to show up in higher-assurance overlays rather than the bare Low baseline. RA-8 rides the privacy baseline, allocated by whether the system processes PII, not by impact level alone.

Deeper: why RA-2 is the highest-leverage control on the whole system.
Every other family’s baseline is downstream of the FIPS 199 categorization RA-2 records. Rate availability Moderate instead of Low and the 800-53B baseline pulls in contingency-planning, redundancy, and incident-response enhancements you would not otherwise carry. Rate it too high to be safe and you’ve committed the program to controls it now has to implement, assess, and defend in the POA&M forever, because walking a categorization back later is a fight nobody enjoys. The high-water-mark rule (overall impact is the max of C, I, and A) means a single Moderate rating on one of the three drags the whole system to Moderate, so the place arguments actually happen is the individual C/I/A ratings, not the overall number. Assessors check RA-2 against the data: claim confidentiality-Low while the system stores anything that looks like CUI or PII and that’s a finding that reaches back and reopens the entire baseline. Categorization is the load-bearing decision, not first-week paperwork you forget.

Control Typical first live at What an assessor actually checks
RA-2 Low C/I/A ratings match the actual data types the system handles; the high-water-mark math is shown; rationale is real, not boilerplate.
RA-3 Low A current risk assessment exists, uses an 800-30-style model, and reflects this system rather than a template with the name swapped.
RA-3(1) Low Supply-chain risk is actually assessed and ties to the SR family, not hand-waved.
RA-5 Low Scan reports are recent, match the stated cadence, and the scope covers the inventory; findings flow to the POA&M.
RA-5(2) Low Scanner signature/plugin feed is current; ask for the last update date.
RA-5(5) Moderate Authenticated scans really run privileged, with evidence (a credentialed-scan result looks nothing like an unauthenticated one).
RA-7 Low Risk decisions are documented with an accept/mitigate/transfer choice and an actual signature.
RA-9 Moderate Critical components are identified and the analysis informs protection and contingency choices.

Treat “first live at” as directional. Your overlay moves things, and FedRAMP or a DoD overlay will pull RA-5 enhancements forward and tighten cadence past the catalog default.

RA-5 is where the family goes brittle

Vulnerability scanning is the RA control everyone runs and the one most likely to be theater. Here’s the flag I’ll plant: most RA-5 programs that claim authenticated scanning are running credential-theater. The scan is configured, the schedule runs, the report is full of findings, and the credentials either never authenticated or authenticated against a fraction of the fleet. An unauthenticated scan sees the network-facing surface and guesses versions from banners; an authenticated scan logs into the host and reads the actual installed-package state. A report that’s mostly “potential” and “remote” severities with almost no host-local package findings is usually an unauthenticated scan wearing an authenticated label, and assessors who know the tooling read that off the report shape in about thirty seconds.

The fixes are unglamorous. Credentialed scanning needs an account with enough local privilege to read the package database (RA-5(5)), and it has to actually work on every host class. The Windows servers authenticate fine over the domain account; the three RHEL 8 boxes nobody onboarded into the scan-credential vault come back unauthenticated and nobody notices, because the report still has plenty of red on it. You cannot scan what you do not inventory, which is why RA-5 leans hard on CM-8 asset inventory. A scan scoped to a stale asset list silently misses whatever was stood up since, and that gap is invisible in the report by construction.

Then there’s RA-5(2), signature currency. A scanner whose plugin feed stopped updating eight months ago because the offline-update job failed silently runs clean and finds nothing new, which looks great and means nothing. Ask for the feed date. False-positive triage is its own grind: the scanner flags a CVE against a package the vendor backported a fix into without bumping the version string (a perennial RHEL problem, the changelog has the fix, the version number doesn’t show it), and someone has to mark it a false positive with a reason an assessor will accept. Findings that survive triage flow to SI-2 flaw remediation and land in the POA&M. RA-5 finds; SI-2 fixes; CA-7 watches the loop.

RA-7 and the risk decision nobody wants to own

RA-7 risk response is the most-faked control in the family, and the reason is structural. The “risk decision” is supposed to come first: assess the risk, then choose to accept, mitigate, transfer, or share it, then act. In practice it’s frequently reverse-engineered from what already happened. The vulnerability sat unpatched for a year, the assessment rolls around, and somebody writes a risk-acceptance memo dated to make the year of inaction look deliberate. The artifact exists. It has a signature. And it is fiction. An assessor who lines the acceptance date up against the discovery date in the scan history can usually tell the deliberate decisions from the retroactive ones. A real RA-7 program produces decisions dated near discovery and signed by someone with the authority to actually accept the risk.

RA-9 and RA-10: the high-assurance end

RA-9 criticality analysis is the quiet one: it asks which components, if they failed or were compromised, would do the most damage, so protection and contingency effort concentrates there. On a flat system it feels like paperwork; on anything with a clear crown-jewel component or a critical dependency chain, it’s the analysis that justifies where the money goes, which is why it feeds SR, SA-15, and CP.

RA-10 threat hunting is the Rev 5 addition, and the one most often claimed without being real. A genuine hunt is proactive and hypothesis-driven: you start from “if an adversary were resident, here’s what their activity would look like in our telemetry,” then go looking, whether or not an alert fired. Different muscle from SOC alert-chasing, which is reactive by definition and already covered under SI-4. Plenty of programs check the RA-10 box by pointing at their SOC queue, which is incident triage with the serial numbers filed off. A real hunt produces hypotheses, documented searches, and findings (including the valuable null result, “we looked for this technique and found no evidence”), and it ties into IR-4 when it turns up something live. No hypotheses and searches to show? You don’t have an RA-10 program, you have a SOC.

Artifacts and the genericness trap

RA work lands in the usual three places. The SSP carries the narratives, the SAR is the assessor’s verdict, the POA&M holds what RA-5 found and SI-2 hasn’t fixed yet. The risk assessment (RA-3) and the categorization (RA-2) are standalone artifacts the SSP references.

The fastest way to fail an RA assessment is the same way you fail any family: an SSP that restates the catalog text back at the assessor. They have read SP 800-53. A risk assessment that could be dropped into any other system’s package without changing a word means nothing, and an RA-2 rationale that reads like the FIPS 199 definitions copied verbatim tells the assessor nobody actually thought about this system’s data. Describe what this system handles, what this system’s scans found, what this program decided to accept and why.

Sources

Adjacent material on this site