RA-3 Risk assessment
What the standard requires
a. Conduct a risk assessment, including: 1. Identifying threats to and vulnerabilities in the system; 2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and 3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information; b. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments; c. Document risk assessment results in [security and privacy plans | risk assessment report | [document] ]; d. Review risk assessment results [frequency]; e. Disseminate risk assessment results to [personnel or roles] ; and f. Update the risk assessment [frequency] or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system.
Quoted verbatim from NIST SP 800-53 Rev 5 (OSCAL catalog), which is in the public domain.
Maps to 3 controls in 3 other frameworks
Mappings are CMDash’s own, seeded with the product and shown on both frameworks they connect. In the product they mean evidence you attach here also counts against the controls listed above.
Integrations that carry evidence for this family
These connectors produce data relevant to FedRAMP Moderate’s Risk Assessment family, which is the granularity CMDash publishes — there is no pre-built per-control mapping, and claiming one would be inventing it. You decide which evidence answers which control.
In CMDash this control is a row with an owner, a status, uploaded evidence kept with its full history, and an export an assessor can read.