Trackr.Live The landing site for Trackr Services
§ Trackr.Live

RMF: A Practitioner’s Roadmap

The NIST Risk Management Framework is simultaneously the only answer for federal information systems and almost impossible to learn in the right order. Open SP 800-37 Rev 2 cold and the document assumes you already know what an SSP is, what an AO signs, and why a control baseline exists. This page is the deliberate front door to the rest of the RMF material on this site. If the framework has ever made the room feel smaller, start here and route out from the table below.

The NIST RMF lifecycle as a clockwise ring of seven numbered steps in order: 0 Prepare (start), 1 Categorize, 2 Select, 3 Implement, 4 Assess, 5 Authorize, 6 Monitor, returning continuously to the start.

What RMF actually is

RMF is a seven-step process, defined in NIST SP 800-37 Revision 2, for taking a federal information system from planning through authorization and into continuous monitoring. It is the operational implementation of FISMA, the Federal Information Security Modernization Act, and in practice it decides whether your system is allowed to handle government data on government networks.

Before RMF, every agency invented its own certification-and-accreditation process. Different paperwork, different vocabulary, different control catalogs, zero reciprocity. The framework imposed a common structure, a common control catalog in SP 800-53, and a common pair of decision artifacts: the System Security Plan and the Authorization to Operate. That standardization is the whole point, even when living inside the framework day to day obscures it.

Two things worth internalizing before you go further. The first is that RMF is risk management rather than a compliance checklist. The structure exists to surface risk to operations, assets, individuals, and the nation, then push that risk in front of an Authorizing Official who has to sign for it. The control catalog is the mechanism, not the goal. The second is that authorization is a snapshot and monitoring is forever. Treating an ATO as a finish line is the most common cultural failure in RMF programs, and it is the reason reauthorizations fail more often than initial ones.

The seven steps

The 800-37 Rev 2 flow runs Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor.

1. Prepare. Establish context and priorities at the organization and system levels: roles, risk tolerance, the authorization boundary, common controls available for inheritance. Prepare was a Rev 2 addition, bolted on specifically because the older flow jumped straight to categorization and left everything downstream incoherent. Rushed here, you pay for it at Assess.

2. Categorize. Determine the impact level (low, moderate, high) for confidentiality, integrity, and availability using FIPS 199 and SP 800-60, which maps information types to provisional impact levels. The result is the system’s high-water mark, and it drives nearly every decision after it.

3. Select. Here is where the Rev 5 reorganization matters. The baselines no longer live inside the SP 800-53 catalog. In Rev 4 the Low/Moderate/High allocations sat in Appendix D of 800-53 itself; Rev 5 split them out into SP 800-53B. So the move is: FIPS 200 sets the minimum-security floor every federal system has to meet, 800-53B turns your impact level into a starting control set, and then you tailor that set (add, remove, modify) to fit the actual system, justifying each change in the SSP. The output is the skeleton of the plan.

4. Implement. Build the controls into the system and document how each one is implemented on this system, in specifics. Engineering and paperwork are both required, and a clean implementation with a vague narrative still fails.

5. Assess. An independent assessor evaluates the controls against the procedures in SP 800-53A. Their verdict becomes the Security Assessment Report; whatever didn’t pass becomes Plan of Action and Milestones items.

6. Authorize. The AO reviews the package (SSP, SAR, POA&M) and issues, denies, or conditionally grants the ATO. This is a risk-acceptance decision. A technically imperfect system can still be authorized if the AO accepts the residual risk; a technically clean one can be denied if the documentation can’t prove it.

7. Monitor. Ongoing assessment of selected controls, configuration management, vulnerability management, and the triggers that force reauthorization. Most of an authorized system’s life is spent here, and most of it is where authorizations quietly rot.

Don’t fixate on the numbering. What matters is the dependency chain underneath it: Prepare and Categorize fix the stakes, and everything downstream inherits the impact level Categorize produced. Get the high-water mark wrong and you tailor the wrong baseline, implement the wrong controls, and hand the assessor a system that was mis-scoped from step two.

The control families

SP 800-53 Rev 5 organizes controls into twenty families. Each is a vertical slice of the catalog, and each has its own page on this site. One change in Rev 5 catches people who learned the framework under Rev 4: security and privacy used to live in separate catalogs, with privacy controls parked in the old Appendix J. Rev 5 unified them into a single catalog. The dedicated privacy family is now PT (PII Processing and Transparency), with the rest of the privacy obligations distributed across PM, SI, RA, and AC rather than penned into an appendix of their own. If you are looking for an Appendix J privacy family, it isn’t there anymore, and that’s by design.

Family Name Page
AC Access Control access-control
AT Awareness and Training at-security-awareness-and-training-policy-and-procedures
AU Audit and Accountability au-audit-and-accountability
CA Assessment, Authorization, and Monitoring ca-security-assessment-and-authorization
CM Configuration Management cm-configuration-management
CP Contingency Planning cp-contingency-planning
IA Identification and Authentication ia-identification-and-authentication
IR Incident Response ir-incident-response
MA Maintenance ma-maintenance
MP Media Protection mp-media-protection
PE Physical and Environmental Protection pe-physical-and-environmental-protection
PL Planning pl-planning
PM Program Management pm-program-management
PS Personnel Security ps-personnel-security
PT PII Processing and Transparency pt-pii-processing-and-transparency
RA Risk Assessment ra-risk-assessment
SA System and Services Acquisition sa-system-and-services-acquisition
SC System and Communications Protection sc-system-and-communications-protection
SI System and Information Integrity si-system-and-information-integrity
SR Supply Chain Risk Management sr-supply-chain-risk-management

SR is the other family worth flagging for anyone coming from older material. Supply Chain Risk Management was promoted to a full family in Rev 5 in response to the SolarWinds class of problem; if your control catalog has no SR family, it predates Rev 5 and is stale.

The two-letter codes reflect the family name, and you will see them constantly in SSPs, SARs, and assessment evidence. Memorizing the code-to-family mapping is one of the highest-ROI things a new ISSO can do in a first month. Everything else on this site is filed under one of those twenty prefixes.

What nobody tells you on day one

The SSP is the only document anyone reads carefully. The SAR gets skimmed, the POA&M gets argued over, but the SSP is the one cited, audited, and quoted back at you years later. Invest accordingly, and never let a control narrative read like paraphrased catalog text.

Inheritance is a real lever and usually under-used. A system on an authorized cloud or platform inherits a substantial fraction of its controls, and documenting that correctly can collapse hundreds of pages of SSP work. Documenting it wrong creates a gap nobody notices until assessment, when the customer-responsibility matrix says one thing and the SSP says another.

POA&Ms have a half-life. The longer an item sits open, the less anyone remembers what it was about. Close them aggressively or close them honestly. Letting them age silently is the worst of the three options.

And tailoring is a responsibility, not a privilege. A baseline applied without thought is worse than no baseline at all. The Select step expects you to remove and modify controls that don’t apply and to defend each call. “We left the full baseline in to be safe” is not the flex people think it is.

A reading order through this site

New to RMF? Move through the site roughly like this. Start with CA, Assessment, Authorization, and Monitoring, because it is the connective tissue that ties the whole framework together. Then PL, Planning and PM, Program Management to establish the surrounding context, followed by RA, Risk Assessment, which is what assessment-and-authorization is ultimately for.

After that, the technical core: AC, Access Control, IA, Identification and Authentication, AU, Audit and Accountability, SC, System and Communications Protection, and SI, System and Information Integrity. That cluster is where most assessors spend most of their time, and where most findings land. Pick up the remaining families in roughly the order a real project throws them at you.

Already an ISSO, ISSE, or assessor here to look up a specific control? Go straight to the family page for its two-letter prefix. That is what they are for. The rest of the site assumes you already know what RMF is; this page is the one place that assumption is suspended.

Sources

Adjacent material on this site