RMFInsider

A Risk Assessment Report (RAR) for an RMF package is the document that takes the raw findings from the Security Assessment Report, adds threat and likelihood context, and tells the Authorizing Official what the residual risk to the mission actually is. The structure comes from NIST SP 800-30 Rev 1: identify threat sources and events, identify vulnerabilities and predisposing conditions, determine likelihood, determine impact, and combine them into a risk level, then present the results in a way that supports a decision. The SAR says “this control failed.” The RAR says “here is what that failure means for the system, how likely someone is to exploit it, how bad it would be, and what we are doing about it.”

I have read RARs that were forty pages of copied control text with a risk matrix stapled to the back, and I have watched AODRs flip straight past them to the POA&M because the report told them nothing they could use. A good RAR is shorter than that, specific to your system, and honest about the risks you would rather not write down. Here is how to build one.

Where the RAR sits in the package

The RAR is one of the core artifacts in an authorization package, alongside the SSP, the SAR, and the POA&M. Each answers a different question. The SSP describes the system and how controls are implemented. The SAR reports what the assessor found when testing those controls. The POA&M tracks the corrective actions. The RAR is the analytical bridge: it converts findings into risk, prioritizes them, and documents the risk response (mitigate, accept, transfer, avoid) so the AO’s decision is informed rather than instinctive.

In DoD, the RAR is typically drafted by the ISSO or ISSM, sometimes with SCA input, and it is required in eMASS as an artifact associated with RA-3. Use your Component’s template if one exists; the content below has to be in it regardless of formatting.

The 800-30 model in one paragraph

Risk is a function of the likelihood that a threat event occurs and results in adverse impact, and the magnitude of that impact. Likelihood has two parts: the likelihood that a threat source initiates the event (for adversarial threats, driven by capability, intent, and targeting) and the likelihood that the event, once initiated, results in impact (driven by vulnerability severity and the effectiveness of existing controls). Impact is measured against the harm to operations, assets, individuals, other organizations, and the Nation, and it is anchored to the system’s security categorization. You assess each of these qualitatively (very low to very high) or semi-quantitatively (0 to 10 or 0 to 100), combine them per the 800-30 Appendix I tables, and get a risk level per finding. Then you write about it in English.

Section-by-section outline

This is the outline I use. It maps to 800-30 Appendix K and it fits on the eMASS artifact tab without anyone asking where the risk matrix went.

1. Executive summary

One page, written last. State the system name, categorization, assessment dates, number of findings by severity, the overall residual risk level, the number of risks proposed for acceptance, and your recommendation. The AODR may read only this page. Write it so that would be sufficient.

2. Purpose, scope, and methodology

Define what was assessed (the authorization boundary as drawn in the SSP), the assessment period, the sources used (the SAR, ACAS scan results, STIG checklists, pen test reports if any, interviews), and the risk model and scales you applied. Name the 800-30 tables you used for likelihood and impact so the reader can reproduce your reasoning. Note any limitations honestly: components out of scope, scans that could not be credentialed, assumptions about the hosting environment.

3. System characterization

A short description of the system, its mission, data types, users, interconnections, and categorization (from the System Security Plan; do not rewrite it, summarize and reference it). The categorization matters here because impact levels in the RAR must be consistent with the CIA impact values you assigned in Step 1. A Moderate-confidentiality system cannot have a “very high” confidentiality impact rating on a finding without an explanation.

4. Threat sources and threat events

List the threat sources relevant to this system, not the generic 800-30 Appendix D list pasted in full. For a typical DoD enclave-hosted system: nation-state adversaries with access to the network segment, insiders (privileged and non-privileged), malicious code arriving through authorized channels, environmental threats to the hosting facility, and supply chain compromise of components on the software list. For each source, state capability, intent, and targeting for adversarial sources, or range of effects for non-adversarial ones. Then list the threat events that source could plausibly cause against this system (credential theft, privilege escalation, data exfiltration, denial of service, unauthorized configuration change).

5. Vulnerabilities and predisposing conditions

This is where the SAR findings come in. Each non-compliant control or CCI, each open CAT I or CAT II scan finding, and each open STIG finding is a vulnerability. Group them where it makes sense (fourteen instances of the same missing patch is one vulnerability with fourteen affected hosts). Add predisposing conditions: architectural facts that make exploitation easier or harder, such as flat network segmentation, legacy operating systems that cannot be patched, or, on the positive side, an air gap or strong enclave boundary controls. Predisposing conditions are how you explain why the same finding is a high risk on one system and a low risk on another.

6. Likelihood determination

For each vulnerability (or group), assess likelihood of initiation and likelihood of impact, and combine them. Show your reasoning in a sentence or two. “Likelihood of initiation: High. The system is reachable from the enclave user segment and the vulnerability is remotely exploitable with public exploit code. Likelihood of adverse impact given initiation: Moderate. Host-based intrusion prevention is active and would likely alert, but would not prevent initial execution.” That is a likelihood determination an AODR can argue with, which is the point. A bare “High” in a table is not.

7. Impact determination

Assess the impact to confidentiality, integrity, and availability if the threat event succeeds, anchored to the categorization and the mission. Be concrete about what the impact is: which data, which users, which mission function, for how long. “Loss of availability of the scheduling database would halt flight line maintenance scheduling for the wing until restored from backup, estimated at four hours per the contingency plan” is an impact statement. “High” is a label.

8. Risk determination and prioritization

Combine likelihood and impact per your stated scale into a risk level for each item, and present them ranked. A compact table-style list works (one line per risk: ID, description, likelihood, impact, risk level, related SAR finding, related POA&M ID). Then write a short narrative for every Very High and High risk, because those are the ones the AO is actually deciding about. Moderate and Low can be summarized.

9. Risk response and residual risk

For each risk, state the response: mitigate (with the POA&M item and its scheduled completion date), accept (with justification and the authority you are asking to accept it), transfer (rare in DoD, but inheritance and shared responsibility can shift it), or avoid (remove the function or component). Then state the residual risk after the planned response, and the residual risk today, before the response is complete. Those are different numbers and the AO needs both.

10. Recommendation and appendices

Recommend an authorization decision (ATO, ATO with conditions, denial) and, if conditions are proposed, list them with dates. Appendices hold the full risk register, the scoring tables you used, and references to the source artifacts by eMASS artifact name.

Tying every risk to a SAR finding and a POA&M item

The single discipline that separates a useful RAR from a decorative one is traceability. Every risk in the RAR should trace back to a specific SAR finding (or scan result or STIG ID) and forward to a specific POA&M item. If a risk has no SAR finding behind it, ask where it came from and document that (a design weakness you identified yourself is legitimate; write it as such). If a risk has no POA&M item ahead of it and is not being accepted, you have a gap in your corrective action plan and the assessor will find it. The guide to writing POA&M items covers the other side of that link.

Enforce it by building the risk register first as a spreadsheet (SAR finding ID, control or CCI, vulnerability, threat event, likelihood, impact, risk level, response, POA&M ID, residual risk), filled from the SAR line by line. The narrative then writes itself from the register.

Scoring: keep it consistent and keep it defensible

• Pick one scale (the 800-30 five-level qualitative scale is the safest choice in DoD) and use it everywhere in the document. Mixing CVSS numbers, CAT levels, and qualitative words in the same table confuses the reader and invites challenge.
• CAT I, II, III from STIGs and ACAS severity are inputs to vulnerability severity, not risk levels. A CAT I on an isolated management interface reachable only from a jump host can be a Moderate risk. Say why.
• Compensating controls lower likelihood of impact, not likelihood of initiation. Write them into the likelihood reasoning, not as a footnote.
• Never score an impact higher than the system categorization supports without explaining what makes this case different. Never score it lower to make the matrix look better; the AODR has seen that move.
• Document the aggregate. Ten Moderate risks on the same host can constitute a High. 800-30 calls this risk aggregation and the AO will expect you to have considered it.

Mistakes that get a RAR sent back

• Copying the SAR into the RAR. The AO has the SAR. The RAR is supposed to add analysis.
• Generic threat sections lifted from the 800-30 appendices with no connection to the system’s actual exposure.
• Risk levels with no reasoning. Every High needs at least two sentences explaining likelihood and impact.
• Residual risk that magically equals the planned-state risk. If the POA&M item is due in nine months, the residual risk today is the unmitigated risk.
• Risks proposed for acceptance with no named accepting authority, no expiration, and no compensating controls.
• No version control. The RAR should be updated when the SAR is updated, at annual review, and after any significant change, and each version should say what changed.

Length and tone

A RAR for a moderate-complexity system runs fifteen to thirty pages including the register. Write in plain declarative sentences. The audience is a senior official with fifteen minutes and a stack of other packages, and the best compliment a RAR can receive is that the AODR read the executive summary, spot-checked two High risks, found the reasoning sound, and signed.

The register at the heart of the RAR is the same data you track in the POA&M, viewed from the risk side rather than the remediation side, and keeping the two in sync by hand is where the errors creep in. If you want a single place to hold findings, risk ratings, milestones, and residual risk together so the RAR and the POA&M always agree, the POA&M Tracker is built around exactly that register.