The National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) is a seven-step process for integrating security, privacy, and supply chain risk management into the system development lifecycle of federal government information systems. Though the RMF is mandatory for federal organizations, it can also be useful for state, local, tribal, and territorial (SLTT) and nongovernmental organizations. However, some of the RMF’s roles and processes are specific to the federal government context. In this blog post, we will translate these aspects of the RMF into guidance for use by nonfederal organizations.

Through its work with federal government sponsors to develop and perform cybersecurity assessments, the SEI has established expertise in the frameworks and requirements used in the federal space, including the RMF.

NIST Special Publication (SP) 800-37, revision 1, introduced the initial version of the RMF in February 2010. In December 2018, NIST released revision 2 of the RMF, whose objectives included making risk management more efficient throughout the organization, integrating privacy risk management concepts, and considering the management of supply chain risks as part of the system development lifecycle.

The Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource, requires federal organizations to consider the security and privacy risks of their information systems. The RMF distills these requirements into actions that decision makers and practitioners can implement without needing to interpret the OMB requirements at the system level. The outputs of these processes also help assessors evaluate whether an organization is adequately completing the RMF's steps.

The NIST RMF has seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. Each step has multiple tasks, with responsible parties ranging from operational roles up to senior officials. Nonfederal organizations likely have similar roles and could also use the structured steps of the RMF to manage risk more comprehensively throughout the lifecycle of a system. With a little bit of translation, nonfederal organizations can tailor the RMF steps for their own operating environment.

While the RMF is structured for ease of use, some of its roles and processes are more common in federal operating environments. In the federal government context, most roles are clearly defined and job titles are prescribed and sector-specific, which may not be the case in nonfederal spaces. In this section, we describe potentially equivalent roles and possible ways to adapt these federal processes to nonfederal organizations in each of the RMF’s seven steps.

Other roles throughout the RMF should be familiar to nonfederal organizations, such as system administrators, security architects, control assessors, and business owners.

Preparation activities are foundational steps at the organization and system level. They help organizations develop systems consistently.

The organization-level preparation tasks are likely common to many organizations, particularly those with mature risk management programs. Senior leadership should

• develop a strategy for managing risk
• define the roles responsible for managing security and privacy risks
• direct organization-wide risk assessments, which will help identify common controls that can mitigate risks to acceptable levels
• assign responsibility for managing risks to a role such as chief risk officer
• develop strategies for both the risk management program and the continuous monitoring of control effectiveness

Someone in a role comparable to a system owner (SO), such as a program manager or director of information technology, must perform the system-level preparations on each information system. Before starting the development of a system, this person should determine how the system relates to the mission of the organization and how it fits into the organization’s risk profile. Tasks at the system level include

• identifying system attributes
• determining the system authorization boundary
• developing security and privacy requirements for the system
• directing system-level risk assessments to evaluate the privacy impact if information were to be compromised
• directing system-level supply chain risk assessments

The risk management program should use outputs from organization-wide and system-level risk assessments to identify common risks and drive the creation or selection of common, cross-organizational controls to mitigate them.

When initiating the development of an information system, essential steps include detailing the system attributes and categorizing the system according to the potential impact to the organization if the system suffers a loss of confidentiality, integrity, or availability.

Federal organizations are required to follow guidance from NIST SP 800-60 and FIPS 199 to perform the Categorize step. However, if a nonfederal organization has its own process already in place for categorizing information systems, using that process may ensure that all stakeholders understand the categorization. The organization should use the chosen categorization process consistently, for clarity’s sake.

In a federal organization, the authorizing official (AO) must approve the system categorization. In a nonfederal context, this official should be someone in a senior management role with official authority and capability to determine the security risks of a system and authorize its operation. In many organizations, this role will naturally fall within the domain of the CISO. However, smaller organizations or those without a CISO may find themselves assigning this role to the CIO or even the CEO.

Categorization drives the selection of security and privacy controls. Nonfederal organizations can choose to use federal control baselines, such as those detailed in NIST SP 800-53B, but they are not bound to them.

The process of selecting security controls requires the following activities:

• identifying a control baseline, if applicable
• tailoring a baseline to system-specific concerns or the unique operating circumstances of the organization
• developing an implementation plan
• developing a continuous monitoring plan
• obtaining approval of the implementation plan from the AO

The control selection process should have many stakeholders, particularly if the AO is not heavily involved in day-to-day security activities. However, as the final approver of the implementation plan, the AO should be kept informed of the process and made aware of potential risks.

SOs, along with common control providers (CCPs), implement controls as detailed in the implementation plan and update the plan as necessary. At this step, the SO may choose to designate an information system security officer (ISSO) who is responsible for the day-to-day management of the system security, including implementation and monitoring of system security controls.

The ISSO role should have visibility into the day-to-day security practices related to the system, as well as the organization at large. The ISSO must also have an open line of communication with the SO and the AO so they can make informed decisions about the status of the system. In many organizations, the ISSO could be a system security architect or an equivalent role. In organizations with small security teams, the ISSO may simply be an IT manager or someone else who has direct contact with the system.

The system may inherit previously implemented controls with help from the common control providers (CCPs), who are likely members of the IT or security staff. It may be necessary to implement additional system-specific controls, particularly for systems that have been categorized as having a greater impact if compromised. All control implementations should be clearly documented and follow the choices made in the Select step.

The effectiveness of controls must be verified, as part of the Assess step, before putting an information system into operation. A senior official designates an assessment team with sufficient technical ability and independence to properly assess the system. The tasks of the assessor(s) are to

• develop a plan to assess the information system
• execute the assessment
• provide a report of findings and recommended remediation actions

Following the assessment, the SO, possibly in collaboration with the ISSO and CCPs must

• remediate any deficiencies that can be immediately addressed
• document deficiencies that must be remediated over time in a plan of action and milestones (POA&M)
• document updated controls in the authorization package

An internal team or external contracted assessors may carry out the Assess step, depending on the size and capabilities of the organization. An internal team must be sufficiently independent from the assessed system—in other words, individuals not involved in the system’s administration.

Before an organization puts an information system into operation, the SO consolidates inputs from the previous steps into an authorization package that is reviewed by the AO. After the completion of a risk assessment and determination of risk responses, the AO provides an authorization decision. This formal decision is the AO's acceptance of the risk of putting the information system into operation. This step is the key reason that the AO or equivalent official must have sufficient authority to accept accountability for risk-related activities, as this decision could introduce considerable risk to the organization.

Putting the system into operation does not mark the end of risk to the organization. The final step in the RMF includes activities such as

• monitoring for changes to the operating environment
• assessing control effectiveness (see our previous blog post, “How to Protect Your High Value Assets”)
• responding to identified risks
• updating the authorization package
• continuously determining if operating the system is within the risk tolerance of the organization
• disposing of the system per relevant guidelines at the time of system retirement

The authorization package helps the AO decide if continued operation of the information system is still within organizational risk tolerances. While the AO or equivalent official is accountable for reviewing the updates to the authorization package and the overall risk profile of the system, a representative such as the IT director or security architect will generally carry out the activities related to the Monitor step.

Many organizations can integrate these tasks into their day-to-day security activities relatively seamlessly. Open channels of communication between the security team and upper-level management are crucial to make sure the AO can continue to make informed decisions based on the status of the system.

Though the RMF is designed with federal information systems in mind, its structured process for managing a system’s lifecycle can be translated to any sector. Identifying clear roles and responsibilities for authorizing information systems establishes accountability for security practices in an organization. Applying the basic concepts of the RMF within an organization’s operating circumstances is a good foundation for managing security throughout the lifecycle of information systems.