NIST 800-53 RA-3 Risk Assessment: What to Show an Auditor

RA-3 Risk Assessment is the control that asks you to find and weigh the threats to your systems, then act on the result. NIST 800-53 binds US federal systems, and others through contracts. For everyone else it is a reference, and a documented risk assessment is among the first things a customer or auditor will ask to see.

What it means in practice

The statement in the record has several parts. Conduct a risk assessment that:

• Identifies threats to and vulnerabilities in the system.
• Determines the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification or destruction of the system and its information.
• Determines the likelihood and impact of adverse effects on individuals from the processing of personally identifiable information.

Then integrate the results and risk decisions from the organization and business process levels with system level assessments. Document the results in a place you define, review them on a schedule you define, share them with defined roles, and update the assessment on that schedule or when significant changes occur to the system, its environment or other conditions affecting its security or privacy state.

The guidance says assessments should consider risk from external parties, including contractors, service providers and outsourced entities. It adds that risk assessment is ongoing across the system life cycle, and can look at design, intended use, testing results and supply chain information.

The record lists four enhancements. RA-3.1 Supply Chain Risk Assessment is the one most relevant to software teams. RA-3.2 Use of All source Intelligence, RA-3.3 Dynamic Threat Awareness and RA-3.4 Predictive Cyber Analytics are more advanced.

Evidence to collect

• The assessment methodology: how you rate likelihood and impact, with definitions.
• The assessment itself: a list of risks with threat, vulnerability, likelihood, impact and owner.
• The date of the last review and the next one, plus reviewer sign off.
• Proof that you reassessed after a significant change, such as a new cloud provider or a major release.
• The privacy impact portion for systems that process personal data.
• A link to the treatment: tickets, accepted risks, decisions.

Common gaps

• The assessment was done once for an audit and never updated.
• It lists generic risks copied from a template that do not match your architecture.
• No link from risks to action. The register records worries, not decisions.
• Third party and open source dependency risk is missing entirely.
• Privacy harm to individuals is not considered, only harm to the company.

How to implement it

Pick a simple scale. Three levels for likelihood and three for impact is enough. Define each in a sentence.

List your systems and for each one write the real threats: credential theft, a vulnerable dependency, a misconfigured storage bucket, a supplier breach. Score them, assign an owner and decide: mitigate, accept, transfer or avoid. Record the decision and the date.

Set triggers for reassessment beyond the calendar. A new data type, a new integration or a major incident should each prompt a review.

For the supply chain element, start with what you ship. An inventory of your open source components and their known vulnerabilities is concrete evidence. The Gold directory at Safeguard lists packages with security information you can use as input, and the free in browser dependency scan at https://gold.safeguard.sh/scan shows what a manifest pulls in. Neither replaces your judgment about likelihood and impact.

Try it yourself

The risk register demo shows how risks, owners and treatments fit together in one place.

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

Quick check

Sources

• NIST SP 800-53 Rev 5, RA-3
• OSCAL catalog for SP 800-53 Rev 5