NIST SP 800‑37 Rev. 2 Risk Management Framework

Document Background

The Risk Management Framework (RMF) was introduced to replace the earlier Certification and Accreditation (C&A) process that had governed federal system authorization since the early 2000s. The first edition of SP 800‑37 (2004) and its revision in 2010 (Rev. 1) established a six‑step process: Categorize, Select, Implement, Assess, Authorize, and Monitor. This process formalized how agencies evaluate risk, apply controls from SP 800‑53, and decide whether a system’s residual risk is acceptable (Joint Task Force, 2018).

Revision 2, published in December 2018, added a seventh step at the beginning: Prepare. The addition was driven by a recurring problem in practice: organizations were jumping straight into categorization without establishing the organizational context, roles, and resources needed for the process to succeed. The Prepare step ensures that organizations lay the groundwork at both the organizational and system levels before beginning the more technical steps (Joint Task Force, 2018).

Although the RMF was designed for federal agencies operating under FISMA, its structured approach to risk management has been adopted by defense contractors (through CMMC and DFARS), state governments, healthcare organizations, and any private‑sector entity that does business with the federal government. Understanding the RMF is essential for anyone working in government cybersecurity or compliance.

The Seven Steps

The RMF is a disciplined, structured process that integrates security, privacy, and risk management into the system development life cycle. The seven steps are designed to be executed in order, though the process is iterative: findings in later steps often require revisiting earlier ones. Each step has defined tasks, expected inputs, expected outputs, and responsible roles (Joint Task Force, 2018).

1. Prepare

   New in Rev. 2. Establish the context and priorities for managing security and privacy risk at both the organizational level and the system level. Key tasks include assigning RMF roles (such as the Authorizing Official, System Owner, and Security Officer), conducting an organization‑wide risk assessment, identifying common controls that can be inherited across systems, and developing a monitoring strategy. The Prepare step ensures that the organization has the resources, governance structure, and risk context in place before diving into system‑specific work (Joint Task Force, 2018).

2. Categorize

   Determine the impact level of the information system by categorizing the types of information it processes, stores, and transmits. This step uses FIPS 199, which defines three impact levels (low, moderate, high) for each of the three security objectives: confidentiality, integrity, and availability. The overall system categorization is the high‑water mark across all information types. The result drives which control baseline (from SP 800‑53B) applies (Joint Task Force, 2018).

3. Select

   Choose the appropriate set of controls from SP 800‑53 based on the system’s categorization. Start with the corresponding baseline (low, moderate, or high), then tailor it by adding controls to address specific threats, removing controls that are not applicable, and applying scoping guidance. The result is a tailored control set documented in the system security plan (Joint Task Force, 2018).

4. Implement

   Put the selected controls into practice. This means configuring systems, writing policies and procedures, deploying technical safeguards, and training personnel. Each control implementation must be documented so that assessors can later verify that it meets the stated requirements. Implementation is where engineering meets compliance (Joint Task Force, 2018).

5. Assess

   Evaluate whether the implemented controls are working as intended. An independent assessor (or assessment team) tests, examines, and interviews to determine if each control is implemented correctly, operating as intended, and producing the desired outcome. Findings are documented in a Security Assessment Report (SAR), which identifies any weaknesses or deficiencies (Joint Task Force, 2018).

6. Authorize

   A senior official, the Authorizing Official (AO), reviews the security assessment results, the system security plan, and the plan of action and milestones (POA&M) for any unresolved findings. The AO then makes a risk‑based decision: is the residual risk acceptable? If yes, the AO issues an Authorization to Operate (ATO). If not, the system is denied authorization and cannot operate until deficiencies are remediated (Joint Task Force, 2018).

7. Monitor

   Continuously track changes to the system and its environment that could affect security or privacy risk. This includes ongoing assessment of a subset of controls, vulnerability scanning, configuration management, incident response, and regular reporting to the AO. The Monitor step transforms the RMF from a point‑in‑time certification into a continuous process. If risk changes significantly, reauthorization may be required (Joint Task Force, 2018).

The ATO Process

The Authorization to Operate (ATO) is the formal declaration by an Authorizing Official that a system is approved to process data at a specified risk level. It is the culmination of the first six RMF steps, and it carries real consequences: operating a system without a valid ATO is a compliance violation that can result in system shutdown, audit findings, and career consequences for the responsible officials (Joint Task Force, 2018).

Key Roles in the ATO Process

Authorizing Official (AO): A senior official with the authority to accept risk on behalf of the organization. The AO is personally accountable for the authorization decision. In federal agencies, this is typically a senior executive or flag officer.

System Owner: The individual responsible for the overall operation and maintenance of the system. The System Owner coordinates with the security team, ensures controls are implemented, and presents the authorization package to the AO.

Information System Security Officer (ISSO): The person responsible for the day‑to‑day security posture of the system. The ISSO implements controls, monitors the system, and serves as the primary point of contact for security matters.

Security Control Assessor (SCA): The independent party who evaluates whether controls are implemented correctly and operating as intended. Independence is critical: the assessor should not be the same person who implemented the controls.

The Authorization Package

The AO makes the authorization decision based on the authorization package, which consists of three core documents (Joint Task Force, 2018):

System Security Plan (SSP): Documents the system boundaries, the selected controls, and how each control is implemented. This is the primary reference document for the system’s security posture.

Security Assessment Report (SAR): Documents the results of the control assessment, including which controls passed, which failed, and the severity of any findings.

Plan of Action and Milestones (POA&M): Documents any known weaknesses, the planned corrective actions, and the timeline for remediation. Not every finding must be resolved before authorization; the AO may accept the risk of known deficiencies if mitigating factors are sufficient.

Rev. 1 vs. Rev. 2 at a Glance

Citing This Document (APA 7)

Like SP 800‑53, SP 800‑37 Rev. 2 is authored by the Joint Task Force. In APA 7, use the group author name and the NIST publication number as the report identifier. Because the Joint Task Force does not have a widely recognized abbreviation, spell it out in every citation.

When referencing a specific RMF step, cite the chapter and step name rather than page numbers. APA 7 does not require page numbers for paraphrased material from long technical documents, and the step names are more useful for locating content within the publication.