Module 1: Introduction to the Risk Management Framework
Module 2: Understanding the RMF Process
Module 3: Implementing the RMF in Practice
Summary

Securing information and systems requires careful planning, deep familiarity with security controls, and a solid grasp of risk management principles. Whether you are new to risk management or an experienced practitioner now tasked with applying formal risk management processes to a system, understanding the basic concepts behind the NIST Risk Management Framework (RMF) is essential. This document provides the foundations of the RMF and explains how to use it to secure systems and reduce organizational risk. It covers the purpose and scope of the RMF and FISMA, the RMF process and its supporting publications, the benefits and trade-offs of using the RMF, and the legal and regulatory requirements that surround it. A running case study — a fictional government contractor called Globomantics — is used throughout to ground the concepts in a realistic implementation scenario. Readers should already be familiar with general IT and cybersecurity fundamentals.

Module 1: Introduction to the Risk Management Framework

This module introduces the RMF: what it is, why it exists, and what it does for an organization. It also covers the benefits and challenges of adopting the RMF, the legal and regulatory backdrop that makes it mandatory for many organizations, and introduces the Globomantics case study that is used for the remainder of the course.

What Is the Risk Management Framework?

In any effort to manage risk and secure systems, an organization needs a starting point — a place to say, “Where do I begin, what do I do next, and how do I do it?” The Risk Management Framework answers that need.

The RMF is an overarching framework and methodology used to frame risk, assess it, mitigate it, and reduce it across an organization, protecting both systems and information in the process.

The RMF was originally developed by the National Institute of Standards and Technology (NIST), the U.S. Department of Commerce agency tasked with implementing a law passed in 2002 known as FISMA, the Federal Information Security Management Act (later modernized in 2014). The framework encompasses far more than just a catalog of security controls — most importantly, it defines an overall methodology for assessing risk, framing it, managing it, mitigating it, and continuously monitoring it.

All United States government organizations are required to implement some form of the Risk Management Framework.

At its core, the RMF gives organizations three primary capabilities:

Capability	Description
Risk Management	Establishes a formalized risk management program where none previously existed.
Risk Assessment	Provides guidance for periodically assessing risk against a standard, ensuring risk stays within the organization’s tolerance/appetite.
Risk Response	Assists organizations in developing a strategy for responding to risk — mitigating it, reducing it, accepting it, or transferring it.

The RMF process itself consists of seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. Although it is often illustrated as a circular process, it is more accurately described as an iterative process that recurs continuously throughout a system’s lifecycle rather than a strictly sequential, one-time journey.

flowchart LR
    A["1. Prepare"] --> B["2. Categorize"]
    B --> C["3. Select"]
    C --> D["4. Implement"]
    D --> E["5. Assess"]
    E --> F["6. Authorize"]
    F --> G["7. Monitor"]
    G -.iterative feedback.-> A
    G -.iterative feedback.-> C
    G -.iterative feedback.-> E

The RMF is supported by a family of NIST publications. A few of the most important ones referenced throughout this course include:

Publication	Title	Relevance
SP 800-39	Managing Information Security Risk	Foundational concepts, key terms, organizational risk view
SP 800-37 (Rev. 2)	Risk Management Framework for Information Systems and Organizations	The core RMF publication, used throughout the entire lifecycle
SP 800-30	Guide for Conducting Risk Assessments	Explains how to perform risk assessments
SP 800-53 (Rev. 5)	Security and Privacy Controls for Information Systems and Organizations	The security control catalog
SP 800-53A (Rev. 5)	Assessing Security and Privacy Controls in Information Systems and Organizations	Methodology for assessing SP 800-53 controls
SP 800-53B	Control Baselines for Information Systems and Organizations	Control baselines for systems with specific characteristics

These publications are explored in more depth as each corresponding RMF step is discussed later in this document.

Benefits and Advantages of the RMF

Understanding why an organization would adopt the RMF requires looking at both what problems it solves and what trade-offs come with it.

Benefits	Challenges
Provides an overall structure for securing assets and reducing risk — no need to invent a risk methodology from scratch.	Long lead time to implement for new systems (existing systems are usually already partway through the process or in continuous monitoring).
A well-vetted methodology that has been in use for years, replacing the older DITSCAP and DIACAP compliance models.	Requires trained, qualified people — cybersecurity, risk management, and IT personnel who understand the process, which can be difficult to find.
Because it is widely used, there is a large community and abundance of resources — anyone working in the federal space likely has colleagues experienced with RMF.	Requires a great deal of resources — money, time, people, labor hours, and infrastructure — because RMF is an ongoing process, not a one-time deliverable.
Helps ensure compliance with regulations such as FISMA, which legally requires federal systems to be secure and compliant.	Risk never fully goes away — even after a system completes the full lifecycle, it enters continuous monitoring indefinitely.

All of these challenges can be overcome, primarily by investing in trained, qualified personnel and committing to RMF as a continuous discipline rather than a one-time project.

Legal and Regulatory Requirements

Disclaimer: Nothing in this document constitutes legal advice. Anyone with concerns or questions about meeting governance or legal requirements for FISMA compliance should consult a qualified legal professional in their jurisdiction.

Since the RMF was created by the U.S. government and is mandated for U.S. government agencies, it carries specific legal and regulatory weight:

FISMA (2002) — The original Federal Information Security Management Act. It began the requirement for federal agencies to perform risk management activities on their information systems and required the development of a Risk Management Framework, which NIST was tasked with creating.
FISMA (2014 update) — Renamed the Federal Information Security Modernization Act. It requires federal agencies to develop programs that provide security for the information systems supporting agency operations, including a formal requirement for security authorization and accreditation of those IT systems.

Key regulatory facts:

RMF is mandatory for U.S. government systems and certain government contractor systems that are owned, managed, or paid for by the U.S. government.
Annual compliance reporting is required for systems that fall under FISMA and use the RMF.
RMF is also freely available for anyone to use — state and local governments, hospitals, universities, and private industry can all adopt it voluntarily.
Because RMF can be a complex, resource-intensive methodology, it is generally recommended for larger organizations and infrastructures. A small business may not derive enough value from the RMF relative to its cost and complexity.

Case Study: Globomantics and Risk Management

To ground these concepts, this course follows a fictional company called Globomantics as it works through implementing the RMF.

Globomantics is a technology company that produces computer networks for the U.S. government as a contractor. When the government issues a contract proposal, Globomantics bids on it; if the bid is accepted, Globomantics designs and builds the network to meet the government’s requirements.

In this scenario, Globomantics has recently won a contract to build and manage a large network for the government that processes personnel data. Because the government owns the resulting system, Globomantics must develop and maintain it in full accordance with the Risk Management Framework — even though Globomantics is only the contractor building and maintaining it, the system must still meet RMF and FISMA requirements since it belongs to a federal agency.

Throughout this document, the Globomantics scenario illustrates the practical challenges of implementing each of the seven RMF steps.

Recap: Foundations of the RMF

This module introduced the RMF — its purpose, scope, and origin — and covered its benefits, advantages, and the trade-offs that come with adopting it. It also introduced the legal backdrop: FISMA requires government organizations to comply, and the RMF is the mechanism NIST created to help them do so. Finally, it introduced Globomantics, a government contractor that must implement the RMF because it has won a contract to build a network for the government. The next module goes deeper into the actual RMF process and its seven steps.

Module 2: Understanding the RMF Process

This module provides a broader overview of the seven steps that make up the RMF process, along with the primary NIST publications associated with each step. Each step is covered again in even greater depth in Module 3.

Overview of the Seven-Step Process

The RMF is a process model consisting of seven clearly defined steps, each with specific associated activities. While it is often described sequentially, it is in fact an iterative model: for new systems, an organization typically proceeds through the steps largely in order, but for existing systems, steps may be revisited repeatedly and some activities may overlap or run concurrently. The RMF also depends on several other NIST-based processes — such as the risk assessment process — that are woven throughout its steps.

The seven steps are:

Prepare
Categorize
Select
Implement
Assess
Authorize
Monitor

All seven steps relate, in one way or another, to security controls and to risk.

Step 1: Prepare

Preparation is the first step and arguably the most important, because so many of its activities recur throughout the entire RMF lifecycle regardless of which step is currently active. The Prepare step helps the whole organization — whether experienced with RMF or not — establish its risk management strategy and supporting processes, whether for a brand-new system or an existing one.

Prepare includes both organizational-level tasks and system-level tasks. The key publications for this step are:

Publication	Focus
SP 800-39 — Managing Information Security Risk	Background of the RMF and risk; foundational concepts, key terms, and the organizational risk view.
SP 800-37 (Rev. 2) — Risk Management Framework for Information Systems and Organizations	The core RMF publication, used throughout every step of the lifecycle; focuses on lifecycle processes for managing information risk.

Step 2: Categorize

Categorization is where an organization determines a system’s information types and evaluates how the organization would be impacted if that information were lost, considering the loss of confidentiality, integrity, or availability of the information.

An information type is a category of information — privacy information, medical information, proprietary information, financial information, and so on. Systems commonly process multiple information types simultaneously.

Two primary publications govern categorization:

Publication	Description
FIPS Publication 199 — Standards for Security Categorization of Federal Information and Information Systems	A short (13-page), foundational publication with definitions and categorization examples. Essential background reading, even if not used daily.
SP 800-60 — Guide for Mapping Types of Information and Information Systems to Security Categories	Provides guidance for mapping information types to security categories in terms of criticality and impact. Published in two volumes (explored in depth in Module 3).

Step 3: Select Controls

During the Select step, an organization chooses a baseline of security controls and tailors that baseline to its needs. Rather than using every control in the catalog, an organization applies the controls relevant to the categorization determined in Step 2.

Baselines come in three tiers — low, moderate, and high — corresponding to the three impact levels used in categorization (confidentiality, integrity, and availability). Baselines are fully tailorable: controls can be added or removed based on the system’s specific categorization and needs.

The primary publication for this step is:

Publication	Description
SP 800-53 (Rev. 5) — Security and Privacy Controls for Information Systems and Organizations	Laid out as a control library with detailed explanations of each control, including how to prioritize and implement them.

A security control is simply a measure put in place to protect an information type or system — a password policy, a firewall, a security device, or encryption are all examples.

Step 4: Implement Controls

The Implement step is where the controls selected in Step 3 are actually installed into the system and made functional. New controls are implemented where necessary, whether for a new or existing system, and existing controls may be upgraded, strengthened, or changed.

Publication	Description
SP 800-160 — Engineering Trustworthy Secure Systems	Focuses on the engineering aspects of control implementation — how to implement controls using security engineering principles.

Step 5: Assess Controls

The Assess step follows implementation. Here, controls are assessed for:

Effectiveness — How well does the control actually protect the asset?
Risk — How much risk results from the absence of a control, or from a control that is implemented but not functioning effectively?
Compliance — Are the controls compliant with applicable regulatory governance (NIST, HIPAA, PCI, etc.)?

Publication	Description
SP 800-53A (Rev. 5) — Assessing Security and Privacy Controls in Information Systems and Organizations	Companion volume to SP 800-53; provides the methodology for assessing controls in the catalog and the expected outcomes of that assessment.
SP 800-30 — Guide for Conducting Risk Assessments	Looks at a broader view of the system and risk, framing and assessing risk at three tiers: organizational, mission/business process, and system.

Step 6: Authorize Systems

Authorization takes place once controls have been implemented and assessed. Control effectiveness and system risk are reported to the Authorizing Official (AO) — the individual formally responsible for authorizing the system for operation.

A system cannot simply be turned on under the RMF. Risk must be formally accepted, documentation must be complete, and an authorization decision must be rendered. The AO examines the assessed risk and the organization’s responses to that risk, then decides whether the system may be put into operation. This role carries legal responsibility and accountability for the system, and it is frequently held by a senior official — typically a government official. Authorization is supported by a formal submission package (detailed in Module 3).

Step 7: Monitor Controls

Monitoring is the final and ongoing step, taking place after the system has been assessed and authorized — this is often called continuous monitoring. The organization continually monitors:

Control effectiveness and risk
System and environment changes
Ongoing assessments (vulnerability assessments, control assessments, risk assessments)
Risk responses to newly identified risks
System documentation changes (e.g., policy changes affecting the system)
Security and privacy reporting obligations to higher governing authorities (which may support compliance with FISMA, HIPAA, PCI, etc.)
Ongoing authorization — at any time, the AO may revoke a system’s authority to operate if risk is discovered to be too high or improperly mitigated
System disposal — when a system is retired or replaced, its disposal is also managed under continuous monitoring

Publication	Description
SP 800-137 — Information Security Continuous Monitoring for Federal Information Systems and Organizations	Focuses on maintaining ongoing awareness of security posture, vulnerabilities, risks, threats, and organizational risk-management decisions.

flowchart LR
    Monitor["Continuous Monitoring"] --> Env["System & Environment Changes"]
    Monitor --> Assessments["Ongoing Assessments"]
    Monitor --> Response["Risk Response"]
    Monitor --> DocUpdate["Documentation Updates"]
    Monitor --> Reporting["Security & Privacy Reporting"]
    Monitor --> ATO["Ongoing Authorization"]
    Monitor --> Disposal["System Disposal"]
    ATO -->|Risk too high| Revoke["AO Revokes Authorization"]

Case Study: Globomantics’ RMF Process Walkthrough

Returning to Globomantics: as a government contractor, the company must follow every step of the RMF for the system it has developed before that system can be formally accepted or tested. Many of the seven steps happen concurrently rather than strictly one after another.

For this walkthrough, assume Globomantics has never previously been through an RMF process for this system — it is starting completely fresh:

Prepare — Globomantics must prepare the organization itself: develop a risk management strategy and policy, and hire qualified personnel who understand risk.
Categorize — The company categorizes the system and its information types, evaluating how the loss of that information would affect confidentiality, integrity, and availability from the customer’s perspective.
Select — Using the categorization results, Globomantics selects a baseline of security controls appropriate to the system.
Implement — The company implements the selected controls — potentially the straight SP 800-53 baseline, or a tailored version based on the system’s unique requirements.
Assess — Control effectiveness and risk are assessed as controls are implemented.
Authorize — Globomantics submits a package containing full system information — including controls and risk — to a government Authorizing Official, who decides whether risk is acceptable enough to put the system into operation.
Monitor — Because Globomantics helps build and maintain the system, it remains engaged throughout the system’s lifecycle to monitor control effectiveness and risk, reporting findings to the appropriate government officials, including the AO.

flowchart TD
    G["Globomantics Wins Government Contract"] --> P["Prepare: Strategy, policy, qualified staff"]
    P --> Cat["Categorize: Determine information types & impact"]
    Cat --> Sel["Select: Choose control baseline"]
    Sel --> Imp["Implement: Install & configure controls"]
    Imp --> As["Assess: Evaluate effectiveness, risk, compliance"]
    As --> Auth["Authorize: Submit package to Authorizing Official"]
    Auth --> Mon["Monitor: Ongoing control & risk monitoring"]

Recap: The Seven-Step Process

This module covered a high-level overview of the RMF’s seven steps, again reinforcing that it is not strictly sequential but instead an iterative model in which steps may be revisited throughout a system’s lifecycle:

Prepare — the organization takes several actions to get ready for RMF, including developing risk strategy, risk policy, and hiring the right people.
Categorize — the organization looks at the information types processed on the system and determines the impact to confidentiality, integrity, and availability if that information were damaged or lost.
Select — categorization feeds directly into control selection, ensuring information is protected in accordance with the system’s categorization.
Implement — the selected controls are fully installed and made functional.
Assess — the organization evaluates whether controls are effective and what risk is associated with them.
Authorize — a documentation package is submitted, and the Authorizing Official decides whether the system should be put into operation.
Monitor — once the system is operational, continuous monitoring tracks risk, environment changes, documentation, and authorization status for the life of the system, remediating risks and potentially disposing of the system when it becomes obsolete.

The next module goes into much greater depth on the specific activities involved in each of these seven steps.

Module 3: Implementing the RMF in Practice

This module goes into significantly more depth on each RMF step, describing concrete organizational activities required to fulfill each step’s requirements, and revisits the Globomantics case study with a fully worked example.

Preparing the Organization and the System

Preparation tasks fall into two categories: organizational-level tasks that should generally be performed on an ongoing basis to establish an effective risk management program, and tasks performed specifically when introducing the RMF lifecycle to a new system or bringing an existing system into the RMF process. SP 800-37 lists specific tasks and expected outcomes for every RMF step, including Prepare.

Organizational-level preparation tasks:

Hire and train qualified personnel familiar with risk management.
Select and assign RMF roles and responsibilities (e.g., system administrators, data owners, system owners).
Develop applicable governance documents — a risk management strategy and policy, and risk assessment/analysis procedures.
Define how risk will be reported to all stakeholders.
Establish a continuous monitoring approach (vulnerability assessments, penetration tests, etc.) and how discovered risks will be addressed.
Determine control baselines and identify common controls that exist across the organization (controls that are not system-specific, such as physical and environmental security controls).

System-level preparation tasks:

Identify the mission and business functions the system supports.
Identify all stakeholders for the system (data owners, system owners, customers, end users).
Inventory all assets for the system (servers, workstations, switches, routers, infrastructure).
Determine the scope of the authorization boundary — what falls inside the system’s perimeter and how it interfaces with other systems.
Identify the information types the system will process (this feeds directly into Categorization).
Determine the lifecycle of the information — how it enters the system, how it is transformed while on the system, and how it exits (transmission, removable media, etc.).
Conduct a system-level risk assessment, even before the system exists, by examining organizational risk along with relevant threats and vulnerabilities.
Identify security and privacy requirements.
Determine how the system will be integrated into the existing infrastructure.

flowchart TD
    subgraph Org["Organizational-Level Prepare Tasks"]
        O1["Hire & train qualified personnel"]
        O2["Assign RMF roles & responsibilities"]
        O3["Develop risk strategy & policy"]
        O4["Define risk reporting to stakeholders"]
        O5["Establish continuous monitoring approach"]
        O6["Determine control baselines & common controls"]
    end
    subgraph Sys["System-Level Prepare Tasks"]
        S1["Identify mission & business functions"]
        S2["Identify stakeholders"]
        S3["Inventory system assets"]
        S4["Determine authorization boundary"]
        S5["Identify information types"]
        S6["Map information lifecycle"]
        S7["Conduct system-level risk assessment"]
        S8["Identify security & privacy requirements"]
        S9["Plan infrastructure integration"]
    end
    Org --> Sys
    Sys --> Cat["Feeds into Step 2: Categorize"]

Categorizing the System and Its Information

Categorization is the process of determining the information type(s) processed by a system and assessing the impact — in terms of low, moderate, or high — on organizational operations, organizational assets, or individuals if that information’s confidentiality, integrity, or availability were lost.

The categorization worksheet is straightforward: for each information type, assign an impact value (low/moderate/high/not applicable) to confidentiality, integrity, and availability. The overall system categorization is then set to the highest value among all of those impact ratings — this is known as the high-water mark.

Worked example — Inventory Data:

Information Type	Confidentiality	Integrity	Availability
Inventory Data	Moderate	Moderate	High

Because the highest impact value present is High, the overall system categorization (SC) for this information type is High — even though two of the three values were only Moderate.

flowchart TD
    Info["Information Type: Inventory Data"] --> C["Confidentiality Impact: Moderate"]
    Info --> I["Integrity Impact: Moderate"]
    Info --> Av["Availability Impact: High"]
    C --> HWM["High-Water Mark Rule (take highest value)"]
    I --> HWM
    Av --> HWM
    HWM --> Cat["System Categorization = HIGH"]

Supporting publications:

Publication	Description
FIPS 199 (Feb 2004)	The foundational, more educational publication — definitions, terms, and good examples of categorization.
SP 800-60, Volume 1	Describes the categorization process — Sections 3 and 4 define a four-step process for categorization.
SP 800-60, Volume 2	Contains the appendices — extensive lists of predefined information types.

In practice, FIPS 199 serves mostly as educational background, while SP 800-60 Volumes 1 and 2 are the publications used most often for day-to-day categorization work.

Selecting and Implementing Security Controls

Selection and implementation are closely related steps and are discussed together here.

Selecting controls starts by returning to the categorization determination (low/moderate/high) and choosing the matching baseline of controls from SP 800-53B. A high system categorization means the organization uses the high baseline; moderate categorization uses the moderate baseline, and so on. Critically, organizations are not restricted to only the controls in the standard baseline — baselines are fully tailorable.

Key activities when selecting controls:

Baseline selection based on categorization (low/moderate/high).
Tailoring controls — removing a control that doesn’t apply, or strengthening/relaxing a control relative to the baseline default.
Allocating controls to the system.
Documenting controls, including technical implementation details (e.g., a specific firewall configuration).
Monitoring control effectiveness and system risk — this activity actually begins here and continues through the rest of the lifecycle.

Selection criteria to weigh when deciding whether to apply a given control:

Criterion	Consideration
System characteristics	What kind of system is it? What does it process? What is its operating environment?
Information characteristics	What kind of information is processed (e.g., PII or PHI require stronger protection)?
Environmental characteristics	What physical and environmental controls can also mitigate risk?
Organizational characteristics	What is the organizational structure surrounding the system?

Example baseline excerpt — Audit and Accountability (AU) control family (SP 800-53B):

Control ID	Control Name	Low Baseline	Moderate Baseline	High Baseline
AU-1	Policy and Procedures	✔	✔	✔
AU-2	Event Logging	✔	✔	✔
AU-3	Content of Audit Records	✔	✔	✔
AU-6	Audit Record Review, Analysis, and Reporting	—	✔	✔
AU-9	Protection of Audit Information	—	✔	✔
AU-11	Audit Record Retention	—	✔	✔
AU-12	Audit Record Generation	✔	✔	✔

Not every control in the catalog applies to every baseline — some controls apply universally, some only start appearing at the moderate baseline, and some are reserved for the high baseline.

flowchart LR
    Cat["System Categorization (Low / Moderate / High)"] --> Base["Select Matching Baseline from SP 800-53B"]
    Base --> Tailor["Tailor Controls: add / remove / strengthen"]
    Tailor --> Common["Inventory Applicable Common Controls"]
    Common --> Doc["Document Allocated Controls"]

Implementing controls is where controls are actually installed and made functional. New controls are implemented for new or existing systems; existing controls may be upgraded, strengthened, or changed as needed.

Considerations during implementation:

Cost — if a control costs more than the system or the information it protects is worth, it may not be justified.
Effectiveness — is the control actually doing its job, or merely “compliant” on paper?
Assessed risk — a properly implemented control should reduce risk; if it doesn’t, either the control or its implementation needs review.
Vulnerability match — controls should map to the specific vulnerability they are meant to mitigate (e.g., encryption mitigates unauthorized access to data).

Both new and existing controls are generally installed, tested, and documented during this step. Organizations also inventory common controls across the enterprise (physical/environmental controls, policies and procedures, perimeter devices) and apply them to the relevant system baselines.

Example control — AU-11, Audit Record Retention (SP 800-53 Rev. 5):

Retain audit records for a defined time period consistent with the records retention policy to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements.

Assessing Controls and Risk

Once controls are implemented, they must be assessed. The Assess step evaluates three things:

Effectiveness — how well the control performs its protective function.
Risk — the risk associated with the control being absent, ineffective, or the wrong control entirely.
Compliance — whether the control adheres to regulatory requirements (e.g., encryption may need to use a specific algorithm or strength to be compliant, not merely “present”).

Supporting publications:

Publication	Role
SP 800-30	Used to assess overall risk; integrates with the RMF and the SP 800-53 control set.
SP 800-53A	Used to assess individual SP 800-53 controls.

How assessments are performed:

Interview key personnel — system administrators, data owners, system owners, engineers, and architects who are intimately familiar with how the system actually works.
Observe the system in operation — e.g., physically verifying that a locked screen actually requires a password to unlock.
Review documentation — diagrams, architectures, system security plans, and related artifacts (many of which reappear in the authorization package).
Perform technical testing — vulnerability scans, penetration tests, and similar hands-on technical verification.

flowchart TD
    Assess["Assess Step"] --> Interview["Interview Key Personnel"]
    Assess --> Observe["Observe System in Operation"]
    Assess --> Review["Review Documentation"]
    Assess --> Test["Perform Technical Testing"]
    Interview --> Outcome["Effectiveness / Risk / Compliance Determination"]
    Observe --> Outcome
    Review --> Outcome
    Test --> Outcome

Authorizing the System

Authorization is the process of presenting all system documentation and assessment results to the Authorizing Official (AO), who makes the operational decision. The AO is typically the legally designated individual held responsible and accountable for the system’s operation.

The AO can respond to an authorization package in several ways:

Authorize the system to operate with no conditions.
Authorize with conditions, such as requiring the reduction of specific risk items or upgrading certain controls.
Deny authorization until risk is reduced to an acceptable level.

flowchart TD
    Package["Authorization Package Submitted"] --> AO["Authorizing Official Reviews Package"]
    AO --> Approve["Authorize to Operate — No Conditions"]
    AO --> Conditional["Authorize with Conditions"]
    AO --> Deny["Deny Authorization"]

Typical authorization package artifacts (common in U.S. government and Department of Defense contexts — exact requirements vary by organization):

Category	Example Artifacts
Core system documentation	System Security Plan, Program Protection Plan, CONOPS
Monitoring & continuity	Continuous Monitoring Strategy/Plan, Continuity of Operations Plan (COOP), Disaster Recovery Plan
Architecture & boundary	Network diagrams and topologies, network architecture, accreditation boundary diagrams
Operational procedures	User Account Management Plan/Procedures, site-specific Standard Operating Procedures, Incident Response Plan
Configuration management	Configuration Management Plan, Configuration Control Board charter and minutes
Guides & design documentation	System Administrator/User Guides, System Security Design Documentation
Training & agreements	Security-awareness training plans and sample training records, user agreements
Assessments & risk	Cybersecurity self-assessment report/checklist, current risk assessment, Plan of Action and Milestones (POA&M)
Roles & authorization history	Appointment letters for key roles (data owner, system owner, ISSO), current Authorization letter (for reauthorization)
Inventory & technical detail	Hardware and software inventory list, security control configuration information (e.g., firewall/IDS configuration)
Risk acceptance & exceptions	Accepted risk letters, waivers or security control exceptions to policy, interconnection agreements with other entities
Supporting material	Any other artifact that helps support authorization, at the AO’s discretion

This can be a long list, and it illustrates why RMF is sometimes a time-consuming, documentation-heavy process.

Monitoring Controls and Risk Continuously

Risk is not static — it changes constantly, driven by several factors:

Changes to the business environment and system operating environment.
Changes to the system itself (updates, upgrades, newly discovered vulnerabilities).
Internal and external factors outside the organization’s control (economic conditions, political conditions, world events, even weather).
New threats and vulnerabilities discovered over time.

Because of this constant change, organizations must continually monitor risk according to the risk management strategy and policy developed during the Prepare step. Monitoring activities include:

Monitoring the system and its operating environment (e.g., vulnerability scans, physical environment checks).
Continually reassessing controls and risk.
Responding to risk — running the organization’s risk mitigation process when new risks are discovered.
Updating risk documents as risk changes or is mitigated.
Reporting security and privacy status to other organizations (e.g., an annual FISMA report to the government, or a report to Health and Human Services for protected health information).
Maintaining the authorization to operate — avoiding any action that could cause the ATO to be denied or terminated.

Case Study: Globomantics’ Full RMF Implementation

Bringing the deeper detail from this module back to Globomantics, here is a complete pass through the process for the government system it maintains:

Prepare — Globomantics has hired the right people, appointed the correct information security roles, and developed a risk management strategy, a risk management policy, and a categorization document.
Categorize — Because the system processes highly sensitive personnel data, Globomantics rates the impact as follows:

Category Impact
Confidentiality High
Integrity Moderate
Availability Moderate

Applying the high-water mark rule, the overall system categorization is High.
Select — Based on the High categorization, Globomantics selects the HIGH control baseline from SP 800-53B, tailoring it by adding or removing individual controls where appropriate for the system.
Implement — The selected controls are installed and configured on the system.
Assess — The system is assessed for control effectiveness, risk, and compliance with governance. If the assessment reveals ineffective controls, the wrong controls, or unacceptable risk levels, Globomantics must revisit earlier steps — potentially reselecting and reimplementing controls differently.
Authorize — Once risk levels are acceptable and controls are shown to be effective, the system is ready for authorization. The government customer’s Authorizing Official authorizes the system to connect to the government’s network, potentially with conditions tied to acceptable risk tolerance.
Monitor — As a condition of authorization, Globomantics submits a continuous monitoring plan: scheduled periodic assessments, periodic vulnerability scanning with a remediation plan in place, and ongoing monitoring of control implementation, the operating environment, and system risk. Any changes identified must be addressed against the risk management strategy developed during Prepare.

flowchart TD
    G["Globomantics System"] --> Cat["Categorize: C=High, I=Moderate, A=Moderate → SC = HIGH"]
    Cat --> Sel["Select: HIGH baseline (SP 800-53B), tailored"]
    Sel --> Imp["Implement selected/tailored controls"]
    Imp --> As["Assess effectiveness, risk, compliance"]
    As -->|Deficiencies found| Sel
    As -->|Acceptable| Auth["Authorize: AO reviews package"]
    Auth --> Mon["Monitor: Periodic assessments, vuln scans, remediation plan"]
    Mon -->|Risk change detected| As

Recap: Implementing RMF in Practice

This module went in depth on each of the seven RMF steps and the concrete activities involved:

Prepare — developing policies and procedures, hiring the right people, appointing roles, and performing a system risk assessment.
Categorize — discovering information types processed on the system and categorizing them by impact to confidentiality, integrity, and availability using the high-water mark rule.
Select — using the system categorization to choose and tailor a control baseline.
Implement — installing and configuring the selected controls.
Assess — evaluating control effectiveness and the risk that results from improperly implemented, ineffective, or missing controls.
Authorize — assembling the documentation package and obtaining a decision from the Authorizing Official, with or without conditions.
Monitor — continually tracking control effectiveness and risk for the life of the system, since risk is never static.

Summary

The NIST Risk Management Framework provides a structured, iterative methodology for framing, assessing, responding to, and monitoring risk across an organization’s information systems. It is mandatory for U.S. federal systems (and many government contractor systems) under FISMA, and it is freely available for voluntary adoption by any organization willing to invest the resources required to run it effectively.

The RMF’s seven steps — Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor — are not a one-time checklist but an ongoing lifecycle. Categorization (based on the impact to confidentiality, integrity, and availability, using the high-water mark rule) drives control baseline selection; selected controls are implemented, then assessed for effectiveness, risk, and compliance; assessment results feed into a formal authorization decision made by an Authorizing Official; and once authorized, the system enters continuous monitoring for the remainder of its operational life — because risk is never static.

Quick-Reference Table: The Seven RMF Steps

Step	Purpose	Primary Publication(s)
1. Prepare	Establish organizational and system-level readiness for risk management	SP 800-39, SP 800-37
2. Categorize	Determine information types and their impact to C/I/A	FIPS 199, SP 800-60 (Vol. 1 & 2)
3. Select	Choose and tailor a control baseline based on categorization	SP 800-53, SP 800-53B
4. Implement	Install and configure selected controls	SP 800-160
5. Assess	Evaluate control effectiveness, risk, and compliance	SP 800-30, SP 800-53A
6. Authorize	Obtain a formal operational decision from the Authorizing Official	SP 800-37
7. Monitor	Continuously track risk, control effectiveness, and environment changes	SP 800-137

RMF Implementation Checklist

Search Terms

nist · risk · management · framework · rmf · governance · compliance · networking · systems · security · controls · process · case · globomantics · study · system · seven-step

NIST Risk Management Framework (RMF)

Table of Contents