Every federal agency that failed an authorization review in the past three years has something in common. The finding is rarely about a missing firewall rule or an unpatched server. The finding is about a system that entered the Risk Management Framework (RMF) process at Step 2 because nobody wanted to spend time on Step 1. The Prepare step was added to NIST SP 800-37 Rev 2 precisely because NIST’s own research identified organizational unreadiness as the leading cause of delayed Authorizations to Operate (ATOs) and failed authorizations. Agencies skipped it anyway.
The pattern is consistent. A program office gets a new system approved. The Information System Security Officer (ISSO) pulls up 800-37, sees “Categorize” as the first substantive step, and starts drafting the system security plan. Months later, when the authorization package reaches the Authorizing Official (AO), the roles are unclear, the risk tolerance is undefined, the common controls are unidentified, and the boundary is contested. The 12-to-18-month ATO timeline stretches to 24. Sometimes 36. The Prepare step would have taken six weeks and prevented all of it.
The seven-step RMF is a sequential framework only in form. In practice, each step produces artifacts that every subsequent step depends on. Skip or compress any step and the dependency chain breaks. What follows is how each step actually works, what it produces, and where federal programs consistently break down.
Implement the NIST RMF by executing seven steps in order: Prepare (establish context and priorities), Categorize (assign Federal Information Processing Standards FIPS 199 impact levels using NIST SP 800-60), Select (choose controls from NIST SP 800-53B baselines), Implement (deploy and document controls), Assess (test using NIST SP 800-53A procedures), Authorize (AO accepts residual risk), and Monitor (continuous oversight per NIST SP 800-137). Each step produces specific artifacts the authorizing official requires before signing the ATO.
Step 1: Prepare. The Foundation Most Agencies Skip
The Prepare step was the most significant structural change in NIST SP 800-37 Rev 2. NIST added it after identifying a pattern: agencies entered the RMF process technically but not organizationally. Systems arrived at the Authorize step with contested boundaries, undefined roles, and no documented risk tolerance. The AO had to resolve organizational problems that should have been settled before a single control was selected.
Organization-Level Prepare Activities
Prepare operates at two levels. At the organization level, the goal is to establish the institutional infrastructure the RMF requires. This includes designating a Senior Agency Information Security Officer (SAISO), establishing a Risk Executive function, and documenting the organization’s risk tolerance in a formal risk management strategy.
The risk management strategy is not a policy document. It is a decision record: what risk the organization is willing to accept, at what impact level, and under what conditions. Without it, the AO has no baseline for authorization decisions. Every authorization package that reaches an underprepared AO requires the AO to construct the risk tolerance on the fly, which is inconsistent, slow, and legally precarious.
Organization-level Prepare also requires identifying and cataloguing common controls. These are controls implemented at the organizational level and inherited by multiple systems. An agency running 40 systems that each fully document their own access control infrastructure is wasting resources and creating inconsistency. Common controls get documented once, inherited consistently, and assessed against the inheriting system’s requirements.
System-Level Prepare Activities
At the system level, Prepare requires identifying the mission or business function the system supports, documenting the stakeholders, and establishing the system boundary before categorization begins. The boundary question deserves particular attention. A system boundary drawn too narrowly excludes interconnected components that share the same data. A boundary drawn too broadly creates an authorization package so large that meaningful assessment becomes impossible.
System-level Prepare also requires identifying the individuals who will fill RMF roles: the Authorizing Official (AO), the System Owner, the ISSO, the Common Control Provider, and the Security Control Assessor. Assigning these roles at the start of the process, not during the assessment phase, is the difference between a coordinated authorization effort and a scramble.
The audit fix. Before beginning categorization, produce three documents: a signed mission characterization memo that describes what the system does and why it exists, a boundary diagram with a written narrative explaining what is inside and outside the boundary, and a roles assignment letter signed by the AO. If any of these three documents does not exist before Step 2 starts, stop and produce them. Every hour spent here saves three hours in the assessment phase.
Step 2: Categorize. Setting the Control Baseline
Categorization determines the security baseline for the entire system. The output of this step, the impact level designation, drives control selection, assessment rigor, and authorization requirements for everything that follows. A miscategorized system either underprotects federal information or wastes resources on controls the mission does not require.
FIPS 199 and NIST SP 800-60
FIPS 199 establishes the three impact levels: Low, Moderate, and High. The categorization applies to three security objectives: confidentiality, integrity, and availability. A system’s overall impact level is the high-water mark of its three individual categorizations. A system that is Low confidentiality, Low integrity, and Moderate availability is a Moderate system overall.
NIST SP 800-60 provides the mapping tables that connect information types to impact levels. Volume I covers the methodology. Volume II maps over 50 federal information types to provisional confidentiality, integrity, and availability impact levels. These provisional levels are starting points. The system owner must review them against the actual mission context and adjust if the provisional designation does not reflect the real-world consequence of a breach.
The most common categorization error is treating the 800-60 tables as final determinations. They are not. A system processing law enforcement sensitive information might use the provisional “Administrative” category as a starting point, then adjust upward based on the sensitivity of specific data elements. The adjustment must be documented with a rationale that the AO can review and accept.
Documenting the Categorization Decision
The formal output of Step 2 is the system categorization documented in the System Security Plan (SSP) and validated by the AO. The documentation must include the information types processed, stored, or transmitted; the provisional impact levels from 800-60; any adjustments made and the rationale for each; and the overall system impact level with the AO’s approval signature.
AO approval at Step 2 is not a formality. The AO is accepting the categorization as the foundation for all subsequent authorization decisions. An AO who approves a Low categorization and later discovers the system processes Moderate-impact information has accepted an authorization package built on a flawed baseline. The authorization is not invalid, but the risk exposure is undocumented and unmanaged.
The audit fix. Pull the 800-60 Volume II appendix tables for each information type your system processes. For each type, document the provisional C, I, and A levels and note whether any mission-specific factors justify an adjustment. Get the AO to sign the categorization decision before selecting controls. An undocumented categorization adjustment discovered during assessment adds four to eight weeks to the authorization timeline.
The impact level designation is a risk management decision, not a technical one. The system owner understands the data. The AO understands the organizational risk tolerance. Neither one alone produces an accurate categorization. Both signatures are required because both perspectives are required.
Step 3: Select. Choosing the Right Controls
Control selection applies the categorization output to the NIST SP 800-53B baselines to identify the minimum required controls for the system. A Low system starts with the Low baseline. A Moderate system starts with the Moderate baseline. A High system starts with the High baseline. These baselines are floors, not ceilings.
Tailoring the Baseline
Tailoring is the process of adjusting the baseline controls to fit the system’s mission, operational environment, and inherited control landscape. Tailoring has two directions: adding controls to address risks not covered by the baseline, and scoping or removing controls that do not apply to the system’s configuration or mission.
Control removals require written justification. An agency removing a control because it does not apply, because a compensating control exists, or because the inherited common control covers it must document the rationale in the SSP. Undocumented control removals are a significant finding during assessment. Assessors cannot distinguish an intentional tailoring decision from a gap without documentation.
The control catalog itself is NIST SP 800-53 Rev 5. As of EO 14306, the operative version is Release 5.2.0. The catalog contains 20 control families covering access control, audit and accountability, configuration management, incident response, and 16 others. Each control includes a discussion section, related controls, control enhancements, and references. The discussion section is not decorative. It explains the intent of the control, which is essential for writing meaningful implementation descriptions in the SSP. Defense contractors working toward CMMC should note that NIST SP 800-171 derives its security requirements from the 800-53 catalog.
Documenting Control Allocation
The Select step produces the control allocation table: for each control in the tailored baseline, the documentation identifies whether the control is system-specific (implemented by this system), common (inherited from an organizational provider), or hybrid (partially inherited, partially system-specific). This allocation drives the assessment scope. An assessor evaluating a system with 15 inherited controls needs access to the common control documentation, not to duplicate the system-level assessment for controls the organization already assessed.
The audit fix. Build a control allocation spreadsheet before drafting the SSP narrative. Columns: control ID, control name, allocation type (system/common/hybrid), common control provider if applicable, and implementation status. Fill in allocation before writing a single implementation description. This spreadsheet becomes the assessment schedule in Step 5 and saves the assessor two to three days of scoping work.
Step 4: Implement. Building and Documenting Controls
Implementation is where security controls move from selection decisions on paper to technical and administrative configurations in production. The step has two outputs: working controls in the system environment and documented implementation descriptions in the SSP that accurately describe what was built.
The Documentation-Reality Gap
The most common finding in federal security assessments is not a missing control. It is a control that exists in the system but is described incorrectly, incompletely, or generically in the SSP. An access control policy that says “the system restricts access to authorized users” does not describe an implementation. It describes an intent. An assessor needs to know the mechanism: Active Directory groups, role-based access control policies, privileged access workstations, session timeout configurations, account review procedures, all mapped to the NIST SP 800-53 Rev 5 AC family.
SSP implementation descriptions should answer three questions for each control: what is the mechanism, how is it configured, and who is responsible for maintaining it. Generic descriptions produce two outcomes, both bad. The assessor cannot make an objective determination without testing, which extends the assessment timeline. Or the assessor makes a favorable determination based on incomplete evidence, which means the control finding surfaces during continuous monitoring instead of assessment, with less time to remediate before the next authorization decision.
Using NIST SP 800-53A for Implementation Guidance
NIST SP 800-53A provides assessment procedures for every control in the 800-53 catalog. The procedures specify what the assessor will examine, interview, and test. Writing implementation descriptions with 800-53A open on the same screen produces SSP content that maps directly to what assessors need. If the 800-53A procedure says the assessor will examine access control policies, examine account management procedures, and interview system administrators, the SSP description should address each of those examination points directly.
This is not teaching to the test. It is writing documentation that actually describes the implementation in enough detail for an independent party to verify it. A system owner who cannot describe the implementation at the level 800-53A requires either has not implemented the control or does not understand what was implemented. Both scenarios are problems that surface during assessment, not problems that disappear because the SSP was vague.
The audit fix. For each control in the High and Moderate impact families, open 800-53A and read the assessment objectives before writing the SSP description. Write the implementation description to address each assessment objective explicitly. This adds 30 minutes per control family to the SSP drafting process and reduces assessment time by two to four weeks. The trade is obvious.
Step 5: Assess. Independent Verification of Control Effectiveness
The assessment step produces the Security Assessment Report (SAR), the primary evidence document the AO uses to make the authorization decision. The SAR is not a compliance checklist. It is an independent determination of whether each control is satisfied, partially satisfied, or not satisfied, with evidence to support each finding.
Assessor Independence Requirements
The Federal Information Security Modernization Act (FISMA) and NIST SP 800-37 Rev 2 both require that the assessor be independent of the system development and implementation team. The independence requirement exists because self-assessment produces optimistic findings. A developer who implemented a control will not identify the same weaknesses an independent assessor will find. Federal systems use either an in-house independent assessment team, a Third-Party Assessment Organization (3PAO) for FedRAMP-scoped systems, or a contracted independent assessor.
Assessor independence does not mean the assessor starts from zero. Providing the assessor with the SSP, the system architecture diagram, the control allocation table, and prior assessment results is not a conflict. It is preparation. The assessor verifies the SSP against observed configurations and interviews. Starting the assessment without these artifacts wastes the first week of the assessment window.
Reading the SAR as an Authorization Input
The SAR will contain findings. Every substantive federal system assessment produces findings. The question is not whether findings exist but how they are characterized and what the plan of action is. Findings are classified by risk level, typically High, Moderate, or Low, based on the likelihood and impact of exploitation. High findings require a Plan of Action and Milestones (POA&M) with aggressive remediation timelines. Low findings may be accepted as residual risk with AO approval.
The POA&M is a living document, not an authorization artifact produced once and filed. It tracks open findings from the assessment, milestone dates for remediation, and responsible parties. An AO who grants authorization based on a POA&M with open High findings is accepting documented risk. That acceptance needs to be explicit and time-bounded. An open High finding on a POA&M with no closure date is not managed risk. It is deferred risk with no accountability structure.
The audit fix. Before the assessment begins, meet with the assessor and agree on finding severity criteria. Different assessors apply different thresholds for High versus Moderate ratings. Agreeing on criteria in advance does not compromise independence. It prevents findings rated inconsistently across assessment periods. Document the agreed criteria in the assessment plan. This one conversation prevents four weeks of post-assessment discussion.
Step 6: Authorize. The AO’s Risk Acceptance Decision
Authorization is a formal risk management decision, not a compliance certification. The AO reviews the authorization package, which consists of the SSP, the SAR, and the POA&M, and makes one of three determinations: Authorization to Operate (ATO), Denial of Authorization to Operate (DATO), or Interim Authorization to Operate (IATO) for systems with significant open findings that the mission cannot wait to remediate.
What the AO Is Actually Deciding
The authorization decision is not a yes or no on whether the security program is perfect. It is a determination that the residual risk, including open POA&M items, is acceptable to the organization given the mission value the system provides. An AO who refuses to authorize a system with a single Moderate finding on an audit log configuration is applying a security standard the ATO process was not designed to enforce. An AO who authorizes a system with 12 open High findings and no POA&M closure dates is not managing risk.
The authorization decision memo must document the AO’s risk acceptance rationale, not just the determination. “Authorized to operate with conditions” is not a risk acceptance rationale. “Authorized to operate for a 12-month period based on accepted residual risk in AC-7 and AU-9 with POA&M milestones due by [date]” is a risk acceptance rationale. The specificity matters because the ATO memo becomes the basis for the next authorization decision, typically a reauthorization at 3-year intervals or after significant change.
ATO Timelines and Continuous Authorization
A full RMF implementation for a new federal system typically takes 12 to 18 months from Prepare through Authorization. Systems with well-documented Prepare artifacts, accurate categorizations, and clean SSP descriptions move through the cycle in 12 months. Systems with underprepared Prepare artifacts, contested boundaries, and generic SSP content take 18 to 24 months and frequently longer.
Continuous Authorization to Operate (cATO) is the integration of RMF with DevSecOps practices to replace the point-in-time authorization with ongoing authorization based on real-time security monitoring. Under cATO, the monitoring and continuous reporting infrastructure triggers automatic authorization reviews when risk metrics exceed defined thresholds, rather than waiting for the 3-year reauthorization cycle. DoD and several civilian agencies are actively implementing cATO programs. The requirement for each of the seven RMF steps does not disappear under cATO. The timelines compress and the monitoring becomes continuous.
The audit fix. Before submitting the authorization package, conduct a pre-authorization review with the AO’s staff. This is not the formal authorization meeting. It is a 90-minute working session where the ISSO and the AO’s security team review the POA&M together and agree on which open findings the AO is likely to accept as residual risk and which will require remediation before authorization. Package surprises extend timelines. Pre-authorization reviews eliminate surprises.
| RMF Step | Primary NIST Publication | Key Output | Common Failure Mode |
|---|---|---|---|
| 1. Prepare | NIST SP 800-37 Rev 2, Chapter 2 | Risk management strategy, role assignments, common control inventory | Skipped entirely; roles assigned during assessment phase |
| 2. Categorize | FIPS 199; NIST SP 800-60 Vol. I & II | AO-approved system categorization with documented information types | 800-60 provisional levels treated as final without mission adjustment |
| 3. Select | NIST SP 800-53B; NIST SP 800-53 Rev 5 | Tailored control baseline with allocation table (system/common/hybrid) | Control removals undocumented; inherited controls not identified |
| 4. Implement | NIST SP 800-53 Rev 5; NIST SP 800-53A | Working controls and SSP implementation descriptions | Generic SSP descriptions that do not match actual configurations |
| 5. Assess | NIST SP 800-53A; NIST SP 800-37 Rev 2 | Security Assessment Report (SAR) with findings and POA&M | Assessor starts without SSP; finding severity criteria not pre-agreed |
| 6. Authorize | NIST SP 800-37 Rev 2, Tasks R-3, R-4 | ATO memo with documented risk acceptance rationale | Authorization memo lacks rationale; open High findings accepted without closure dates |
| 7. Monitor | NIST SP 800-137; NIST SP 800-37 Rev 2 | Continuous monitoring strategy, ongoing assessment results, updated POA&M | Monitoring treated as annual assessment repeat; no ongoing reporting |
Step 7: Monitor. Continuous Oversight After Authorization
The Monitor step is where most federal security programs expose their real maturity level. Authorization is a moment in time. The operating environment changes continuously: new vulnerabilities emerge, configurations drift, personnel turn over, mission requirements expand. The Monitor step exists to detect and respond to those changes before they invalidate the risk acceptance decision the AO made at authorization.
What Continuous Monitoring Actually Requires
FISMA requires ongoing assessment of controls, not just triennial reauthorization. The NIST SP 800-137 continuous monitoring framework operationalizes this requirement through a formal program with defined monitoring frequencies, reporting structures, and thresholds for triggering authorization reviews.
Controls are not monitored at the same frequency. High-impact controls in the access control and audit families require continuous or monthly automated monitoring. Configuration management controls for critical infrastructure require quarterly review. Policy-based controls that change infrequently may warrant annual review. The monitoring strategy documents these frequencies and the rationale behind them. An agency monitoring every control at the same frequency is either under-monitoring high-risk controls or burning resources on low-risk ones.
Triggering Events and Reauthorization
Significant changes to the system require a reauthorization decision, not just an SSP update. Significant changes include adding new information types at a higher impact level, interconnecting with a new system, changing the operating environment from on-premises to cloud, or experiencing a security incident that affects the AO’s original risk acceptance.
The determination of what constitutes a “significant change” is one of the most frequently contested points in federal security programs. Program offices want to minimize reauthorization triggers because reauthorization is resource-intensive. ISSOs want to trigger reauthorization for any change because it protects their professional exposure. The right answer is a written significant change threshold document, approved by the AO at authorization, that defines specific criteria. Remove the ambiguity at the start, not during an incident.
For agencies pursuing cATO, the Monitor step becomes the operational core of the security program rather than a post-authorization maintenance activity. Real-time dashboards feeding risk metrics to the AO, automated POA&M updates from continuous scanning results, and defined authorization thresholds that trigger immediate review replace the annual assessment cycle with ongoing risk-informed authorization. Organizations ready to make this shift should review our cATO implementation guide and OSCAL compliance standard overview for the tooling requirements.
The audit fix. Map every control in your tailored baseline to a monitoring frequency: continuous, monthly, quarterly, or annual. Document the tool or procedure that produces each control’s monitoring evidence. For controls assessed annually by manual interview, schedule them now on the ISSO’s calendar. An unscheduled annual control review is a missed annual control review. For cATO programs, identify which controls are candidates for automated monitoring and build the tooling roadmap before the ATO memo is signed.
The 12-to-18-month ATO timeline is not a feature of federal bureaucracy. It is what happens when the Prepare step gets skipped, the categorization gets treated as a paperwork exercise, and the SSP gets written in generalities. Fix those three things and the timeline compresses. Fix the monitoring program and the reauthorization cycle becomes a checkpoint, not a project. The seven steps are sequential for a reason: each one produces the foundation the next one requires. Organizations that understand this build authorization programs. Organizations that treat it as a checklist build authorization backlogs.
Frequently Asked Questions
What is the NIST RMF implementation guide and which publication defines it?
The NIST RMF implementation guide refers to the seven-step Risk Management Framework defined in NIST SP 800-37 Rev 2. The seven steps are Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. FISMA requires all federal information systems to follow this framework. The Prepare step was added in Rev 2 and is the most significant structural change from Rev 1.
Why is the Prepare step the most commonly skipped in federal implementations?
Prepare is skipped because it does not produce a visible deliverable that program offices recognize as progress. Categorizations, SSPs, and ATOs are concrete milestones. Risk management strategies, role assignments, and common control inventories feel like overhead. They are not. Every underprepared authorization package adds weeks of rework during assessment and frequently months during the authorization review.
How long does an ATO take under the NIST RMF?
A full RMF implementation from Prepare through Authorization typically takes 12 to 18 months for a federal system. Organizations with well-documented Prepare artifacts, accurate categorizations, and specific SSP descriptions consistently achieve 12-month timelines. Organizations skipping or compressing the early steps regularly exceed 18 months. Continuous Authorization to Operate (cATO) programs can compress this significantly by integrating RMF into DevSecOps pipelines.
What is the difference between NIST SP 800-53 and NIST SP 800-53B?
NIST SP 800-53 Rev 5 is the full control catalog: over 1,000 controls across 20 families. NIST SP 800-53B provides the three pre-assembled control baselines, Low, Moderate, and High, derived from that catalog. Step 3 of the RMF starts with the 800-53B baseline for the system’s impact level and tailors from there. Most systems do not start from the full 800-53 catalog.
What triggers a reauthorization under the NIST RMF?
Three conditions trigger reauthorization: the passage of three years (standard reauthorization interval), a significant change to the system or its operating environment, or a security incident that materially affects the AO’s original risk acceptance. Significant change criteria should be defined in writing at the time of initial authorization, not decided case-by-case when a change occurs.
How does cATO relate to the standard seven-step RMF?
Continuous Authorization to Operate (cATO) does not replace the seven steps. It operationalizes the Monitor step by integrating real-time security monitoring into DevSecOps pipelines and replacing the periodic point-in-time authorization with ongoing risk-informed authorization. All seven steps still apply. The authorization decision changes from a fixed-point approval to a continuous risk threshold model where the AO receives ongoing dashboards and triggers reauthorization review based on defined thresholds rather than calendar dates.
What is a Plan of Action and Milestones (POA&M) in the RMF context?
A POA&M is a formal document tracking security findings that were open at the time of authorization, with assigned owners, planned remediation actions, and milestone dates for closure. The AO reviews the POA&M as part of the authorization package and accepts residual risk on each open finding by authorizing the system. The POA&M remains active through the Monitor step and is updated as findings are remediated or new findings emerge from continuous monitoring.
What does FISMA require in relation to the NIST RMF?
FISMA requires all federal executive branch agencies to implement an information security program that includes risk categorization, security plan development, security control selection and implementation, periodic testing and evaluation, and a plan of action for remediation. NIST SP 800-37 Rev 2 provides the operational framework for meeting these statutory requirements. FISMA compliance and RMF compliance are not identical, but RMF completion is the primary mechanism for demonstrating FISMA compliance for individual systems.
Subscribe to The Authority Brief for next week’s analysis.
