The NIST Risk Management Framework is one of those things that is simultaneously the only answer for federal information systems and almost impossible to learn out of order. This page is a deliberate front door to the rest of the RMF material on this site. If you have ever opened NIST SP 800-37 Rev 2 and felt the room get smaller, start here instead.
What RMF actually is, and why
RMF is a seven-step process, defined in NIST Special Publication 800-37 Revision 2, for taking a federal information system from the planning stage through authorization and into continuous monitoring. It is the operational implementation of FISMA — the Federal Information Security Modernization Act — and in practice it is the thing that determines whether your system is allowed to handle government data on government networks.
It exists because, before RMF, every agency was inventing its own certification-and-accreditation process. Different paperwork, different vocabulary, different control catalogs, no reciprocity. RMF imposed a common structure, a common control catalog (NIST SP 800-53), and a common pair of decision artifacts (the SSP and the ATO). That alone is a significant achievement, even if living inside the framework on a daily basis sometimes obscures it.
Two things to internalize before going further:
- RMF is risk management, not compliance. The framework is structured to surface risk to operations, assets, individuals, and the nation, and to push that risk in front of an Authorizing Official who has to sign for it. The control catalog is the mechanism, not the goal.
- RMF is a continuous process, not a project. Authorization is a snapshot; monitoring is forever. Treating an ATO as a finish line is the most common cultural failure in RMF programs.
The seven steps
The 800-37 Rev 2 process flow is:
1. Prepare. Establish context and priorities at both the organizational and system levels. This step was a Rev 2 addition specifically to make the rest of the process coherent. Skipped or rushed in roughly half of the programs that struggle later.
2. Categorize. Determine the impact level (low / moderate / high) for confidentiality, integrity, and availability using FIPS 199 and NIST SP 800-60. The result is the system’s “high-water mark,” which drives nearly every downstream decision.
3. Select. Choose the baseline controls from NIST SP 800-53 Rev 5 that apply at that impact level, then tailor them — adding, removing, or modifying — to fit the actual system. The output is the bones of the SSP.
4. Implement. Build the controls into the system. Document how each control is implemented. This is where engineering meets paperwork; both halves are required.
5. Assess. An independent assessor evaluates each control using the procedures in NIST SP 800-53A. Findings become the SAR; unresolved findings become POA&M items.
6. Authorize. The Authorizing Official reviews the package — SSP, SAR, POA&M — and issues, denies, or conditionally grants the ATO. This is a risk-acceptance decision, not a technical one.
7. Monitor. Ongoing assessment of selected controls, configuration management, vulnerability management, and reauthorization triggers. Most of an authorized system’s life is spent in this step.
The numbered order matters less than the flow: prepare and categorize set the stakes, select and implement build the controls, assess and authorize verify and accept the residual risk, monitor maintains the picture.
The control families at a glance
NIST SP 800-53 Rev 5 organizes controls into twenty families. They are the vertical slices of the catalog, and each one has its own dedicated page on this site.
| Family | What it governs |
|---|---|
| AC | Access control |
| AT | Awareness and training |
| AU | Audit and accountability |
| CA | Assessment, authorization, and monitoring |
| CM | Configuration management |
| CP | Contingency planning |
| IA | Identification and authentication |
| IR | Incident response |
| MA | Maintenance |
| MP | Media protection |
| PE | Physical and environmental protection |
| PL | Planning |
| PM | Program management |
| PS | Personnel security |
| PT | PII processing and transparency |
| RA | Risk assessment |
| SA | System and services acquisition |
| SC | System and communications protection |
| SI | System and information integrity |
| SR | Supply chain risk management |
The two-letter codes are not arbitrary — they reflect the natural-language 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 their first month.
What nobody tells you on day one
A few things that get learned the hard way:
- The SSP is the only document anyone reads carefully. The SAR gets skimmed. The POA&M gets argued over. The SSP is the one that gets cited, audited, and quoted back at you years later. Invest in it accordingly.
- “Inheritance” is a real lever, and it is usually under-used. A system hosted on an authorized cloud or platform inherits a substantial fraction of its controls. Documenting inheritance correctly can collapse hundreds of pages of SSP work. Documenting it incorrectly creates a gap nobody notices until assessment.
- POA&Ms have a half-life. The longer an item sits open, the less anyone remembers what it was actually about. Close items aggressively or close them honestly — letting them age silently is the worst option.
- Continuous monitoring is where authorizations actually fail. Almost no system fails its initial ATO; many fail their reauthorization because monitoring evidence has rotted in the intervening three years.
- Tailoring is a responsibility, not a privilege. A baseline applied without thought is worse than no baseline. The Select step expects you to remove and modify controls that do not apply, and to justify it.
A reading order through this site
If you are entirely new to RMF, I would suggest moving through the site roughly in this order:
- This page (you are here).
- The CA family page — it is the connective tissue of the framework.
- PL and PM — planning and program management establish the surrounding context.
- RA and CA together — risk assessment is what assessment-and-authorization is for.
- AC, IA, AU, SC, SI — the technical core that most assessors spend most of their time in.
- The remaining families in roughly the order you encounter them on a real project.
If you are not new — if you are an ISSO, ISSE, or assessor coming here to look up a specific control — go straight to the family page for the control’s 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 where that assumption is suspended.