The RMF Process Explained

For federal agencies and the defense contractors who support them, deploying a new IT system, software application, or cloud service is not merely a technical challenge; it is a rigorous regulatory exercise. Before any system can process government data or connect to a federal network, it must receive an Authority to Operate (ATO).

The pathway to an ATO is governed by the Risk Management Framework (RMF), established by the National Institute of Standards and Technology (NIST) in Special Publication 800-37. RMF is the mandatory process used by the Department of Defense (DoD), the Intelligence Community (IC), and federal civilian agencies to integrate security and risk management into the system development life cycle.

For many contractors, RMF is viewed as a bureaucratic nightmare—a mountain of paperwork that delays deployments and frustrates engineers. However, when understood and executed efficiently, RMF is a structured, defensible methodology for ensuring mission assurance. The contractors who master RMF gain a significant competitive advantage: they can deliver secure systems faster, win more contracts, and build deep, trusted relationships with their government customers.

This guide demystifies the RMF process. It breaks down the seven steps of the framework, explains the key roles and responsibilities, details the critical artifacts produced at each step, and provides practical guidance for defense contractors tasked with executing RMF on behalf of their federal customers.

Before diving into the steps, it is essential to understand the key personnel involved in the RMF process. In federal contracting, these roles are often split between government personnel and contractor support staff.

Authorizing Official (AO): A senior government official with the authority to formally assume responsibility for operating an information system at an acceptable level of risk. The AO is the person who ultimately signs the ATO. They are accountable for the decision and must be a senior enough official to accept the risk on behalf of the agency.

System Owner (SO): The government official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system. The SO works closely with the ISSM to ensure the system meets its security requirements.

Information System Security Manager (ISSM): The individual responsible for the information assurance program of a system. They ensure the RMF process is followed, maintain the SSP, manage the POA&M, and serve as the primary liaison between the technical team and the AO. Contractors frequently staff ISSM roles to support the government.

Information System Security Officer (ISSO): The ISSO supports the ISSM in the day-to-day security operations of the system. On large programs, there may be multiple ISSOs supporting a single ISSM.

Security Control Assessor (SCA): An independent government official or designated third party responsible for conducting a comprehensive assessment of the security controls to determine the extent to which they are implemented correctly, operating as intended, and producing the desired outcome.

Information System Security Engineer (ISSE): The technical expert (often a contractor) responsible for designing and implementing the security controls within the system architecture. The ISSE translates the compliance requirements into actual technical configurations.

NIST SP 800-37 Revision 2 outlines a seven-step process. Successful RMF execution requires treating these steps not as sequential silos, but as an iterative lifecycle integrated directly into system development.

Step 0: Prepare

Added in Revision 2 of the framework, the Prepare step is designed to reduce the complexity of the subsequent steps by ensuring the organization is ready to execute RMF efficiently.

Key Activities: Identify and assign key roles (ISSM, SO, AO). Establish a risk management strategy at the organizational level. Identify and document common controls—security controls provided by the enterprise (e.g., a centralized firewall, a shared identity management system) that the new system can inherit rather than build from scratch. Define the authorization boundary.

Contractor Focus: For contractors, this step is about gathering the existing agency policies, understanding the enterprise architecture, and identifying which enterprise services the new system can leverage. Aggressively identifying inheritable controls at this stage is the single most powerful way to reduce the overall RMF workload.

Step 1: Categorize

Before you can secure a system, you must understand the impact if it were compromised.

Key Activities: The system is categorized based on the potential impact of a loss of Confidentiality, Integrity, and Availability (the CIA triad). Using Federal Information Processing Standards (FIPS) 199, the impact is rated as Low, Moderate, or High for each dimension. The overall system categorization is the highest of the three individual ratings (the "high water mark" principle).

The Output: The Security Categorization document, which dictates the baseline set of security controls that must be applied in the next step. A system categorized as Moderate/Moderate/Moderate will use the NIST 800-53B Moderate baseline.

Step 2: Select

Once the system is categorized, you must select the appropriate security controls to mitigate the identified risk.

Key Activities: Based on the FIPS 199 categorization, the team selects a baseline set of controls from the NIST SP 800-53 catalog. The team then "tailors" the baseline—scoping out controls that do not apply, documenting inherited controls, adding organization-specific controls, and assigning values to the organization-defined parameters within each control.

Contractor Focus: This is where the ISSE and ISSM earn their keep. Blindly accepting the baseline without tailoring results in massive over-engineering. Expert tailoring ensures the system is secure without being paralyzed by unnecessary compliance burdens. The tailoring decisions must be documented and justified in the Security Plan.

Step 3: Implement

This is the engineering phase. The selected controls are built into the system.

Key Activities: The ISSEs and developers configure the firewalls, set up Active Directory, enforce password policies, deploy endpoint detection and response (EDR), configure audit logging, and write the necessary operational procedures and policies.

The Output: The System Security Plan (SSP) is the critical artifact here. The SSP must document exactly how every single selected control is implemented in the specific environment. Vague policy statements in an SSP ("the system enforces strong passwords") will lead to failure in the Assessment phase. The SSP must describe the specific technical configuration ("password complexity is enforced via Active Directory Group Policy Object 'Default Domain Policy,' requiring a minimum of 15 characters, with complexity enabled").

Step 4: Assess

The implementation must be verified by an independent party. You cannot grade your own homework.

Key Activities: The Security Control Assessor (SCA) develops a Security Assessment Plan (SAP) that details the scope, methodology, and schedule for the assessment. The SCA then evaluates the system using three methods: examining documentation (the SSP, policies, procedures), interviewing key personnel (the ISSM, system administrators, users), and testing the technical controls (running vulnerability scans, attempting to exploit misconfigurations, verifying firewall rules).

The Output: The Security Assessment Report (SAR). The SAR details every vulnerability and non-compliant control found during the assessment, along with the SCA's recommendations for remediation.

Step 5: Authorize

This is the decision point. The Authorizing Official (AO) reviews the evidence and makes a risk-based decision.

Key Activities: The ISSM compiles the Authorization Package, which includes the SSP, the SAR, and the Plan of Action and Milestones (POA&M). The POA&M documents how and when the vulnerabilities identified in the SAR will be remediated. The AO reviews the package and makes a formal risk determination.

The Output: The AO issues an Authorization Decision Document. This will be one of three outcomes: an Authority to Operate (ATO), an ATO with Conditions (a temporary authorization requiring rapid remediation of specific flaws within a defined timeframe), or a Denial of Authorization to Operate (DATO).

Step 6: Monitor

An ATO is not a permanent state; it is a snapshot in time. The Monitor step ensures the system remains secure as the threat landscape and the system itself evolve.

Key Activities: Continuous monitoring of the security controls, including automated vulnerability scanning, reviewing audit logs, assessing the security impact of any proposed changes to the system (Configuration Management), updating the SSP and POA&M regularly, and conducting periodic control assessments.

Contractor Focus: Continuous monitoring is often delivered as a managed service by contractors. The ISSM must generate regular ConMon reports for the AO demonstrating the current security posture. If monitoring fails or the risk posture degrades significantly, the AO can revoke the ATO.

The Authorization Package is the culmination of the entire RMF process. Understanding its components is essential for any contractor executing RMF.

| Document | Purpose | Primary Author | | :--- | :--- | :--- | | System Security Plan (SSP) | Describes the system, its boundary, and how every control is implemented | ISSM/ISSE | | Security Assessment Report (SAR) | Documents the findings of the independent security assessment | SCA | | Plan of Action & Milestones (POA&M) | Tracks all known vulnerabilities and remediation plans | ISSM | | Authorization Decision Document | The AO's formal risk acceptance decision | AO |

Contractors frequently stumble in RMF execution, leading to delayed deployments and cost overruns.

Treating RMF as a "Paperwork Exercise" at the End: The most catastrophic mistake is building the system first and trying to "bolt on" RMF compliance at the end. If you build an application that does not support multi-factor authentication, discovering that flaw during the Assess phase requires a massive, expensive redesign. RMF must be integrated into the system engineering process from Day 1.

Copy/Paste SSPs: Assessors are trained to spot "copy and paste" compliance. If your SSP recites NIST policy rather than detailing the specific technical configuration of your environment, the assessor will fail the control. Specificity is the single most important quality of a credible SSP.

Failing to Inherit Controls: A new application deployed in an existing, ATO'd cloud environment should not be assessed on physical security or perimeter firewalls. The team must aggressively map and inherit these common controls to reduce the assessment scope and the overall workload.

Unrealistic POA&Ms: When vulnerabilities are found, the team must create a POA&M. A common mistake is assigning unrealistic remediation dates or listing the same vulnerability as "in progress" for months without actual progress. When milestones are repeatedly missed, the AO loses confidence in the team's operational discipline and may revoke the ATO.

Surprising the Assessor: Engaging the SCA only at the formal assessment phase is a recipe for failure. Smart contractors engage the SCA early, share the draft SSP, and discuss the tailoring decisions before the formal assessment begins. This eliminates late-stage surprises and builds the collaborative relationship needed for a successful authorization.

The Risk Management Framework is the foundational language of federal cybersecurity. It provides a structured, risk-based approach to securing the nation's most critical information systems.

For defense contractors, mastering RMF is a core competency and a genuine competitive differentiator. By integrating RMF into the engineering lifecycle, tailoring controls aggressively and intelligently, writing highly specific System Security Plans, engaging assessors early, and maintaining rigorous continuous monitoring, contractors can transform RMF from a bureaucratic hurdle into a mission enabler—delivering rapid, secure capabilities to their federal customers.

[1] NIST Special Publication 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations. https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final [2] Department of Defense Instruction (DoDI) 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT).

While NIST SP 800-37 provides the framework, the DoD has its own specific implementation requirements that defense contractors must understand.

Enterprise Mission Assurance Support Service (eMASS): eMASS is the DoD's primary GRC tool for managing the RMF process. It is a web-based application that serves as the authoritative repository for all RMF artifacts—SSPs, SAPs, SARs, POA&Ms, and ATOs. Defense contractors performing RMF work for DoD customers must be proficient in eMASS. They use it to document control implementations, track assessment findings, manage POA&M items, and submit authorization packages to the AO.

eMASS is not just a document repository; it is a workflow management tool. The system tracks the status of each RMF step, routes packages to the appropriate reviewers, and maintains a complete audit trail of all actions taken on the authorization package. Proficiency in eMASS is a required skill for ISSMs and ISSEs working on DoD programs.

DISA Security Technical Implementation Guides (STIGs): STIGs are mandatory configuration baselines published by the Defense Information Systems Agency (DISA) for hundreds of technologies—operating systems (Windows, Linux, macOS), databases (Oracle, SQL Server), web servers (Apache, IIS), network devices (Cisco, Palo Alto), and cloud platforms (AWS, Azure). Every component in a DoD information system must be configured in accordance with the applicable STIG.

STIG compliance is assessed using the DISA STIG Viewer tool and automated scanning tools like ACAS. Each STIG contains hundreds of individual checks (called "Vulnerability IDs" or "V-IDs"), each assigned a severity category (CAT I, CAT II, CAT III). CAT I findings are the most severe and represent configurations that could immediately result in a system compromise. They must be remediated before the ATO can be granted.

The STIG Waiver Process: In some cases, a required STIG setting cannot be applied due to a technical constraint (e.g., a legacy application that breaks if a specific security setting is enabled). In these cases, the ISSM must submit a formal STIG deviation request to DCSA or the AO. The deviation request must document the specific STIG finding, the technical reason it cannot be applied, and the compensating control that mitigates the risk. Unapproved STIG deviations are a serious finding during assessments.

The culmination of the RMF process is the Authorization Package—the collection of documents submitted to the Authorizing Official for the final risk acceptance decision. A complete DoD Authorization Package typically includes:

| Document | Purpose | | :--- | :--- | | System Security Plan (SSP) | Comprehensive description of the system and its security controls | | Security Assessment Plan (SAP) | The assessor's plan for testing the security controls | | Security Assessment Report (SAR) | The assessor's findings and recommendations | | Plan of Action and Milestones (POA&M) | Documented plan for remediating identified weaknesses | | Risk Assessment Report (RAR) | Analysis of the overall risk posture of the system | | Hardware/Software List | Inventory of all components within the authorization boundary | | Network Diagram | Visual representation of the system architecture and data flows | | Ports, Protocols, and Services (PPS) List | Documentation of all network communications |

The quality and completeness of the Authorization Package directly determines the speed of the authorization decision. A well-organized, comprehensive package with clear evidence for every control allows the AO to make a confident risk acceptance decision quickly. A disorganized, incomplete package results in rounds of questions, requests for additional evidence, and months of delay.

The Risk Management Framework is the foundational language of federal cybersecurity. It provides a structured, risk-based approach to securing the nation's most critical information systems.

For defense contractors, mastering RMF is a core competency and a genuine competitive differentiator. By integrating RMF into the engineering lifecycle, tailoring controls aggressively and intelligently, writing highly specific System Security Plans, engaging assessors early, maintaining rigorous continuous monitoring, and delivering complete, well-organized Authorization Packages, contractors can transform RMF from a bureaucratic hurdle into a mission enabler—delivering rapid, secure capabilities to their federal customers.

[1] NIST Special Publication 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations. https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final [2] Department of Defense Instruction (DoDI) 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT). [3] Defense Information Systems Agency (DISA). STIG Library. https://public.cyber.mil/stigs/