NIST Risk Management Framework (SP 800-37) Guide: The Seven Steps from Prepare to Monitor

Most organisations that "use the NIST RMF" really run a one-off paperwork exercise to get an authorisation, then let the evidence go stale until the next one. NIST SP 800-37 Rev. 2 describes something different: a seven-step life cycle that ties system security and privacy decisions to an organisation-wide risk strategy and keeps them current through continuous monitoring. This guide explains the steps and their tasks, the roles and artefacts, how authorisation decisions work, where identities and non-human identities (NHIs) appear, and how to implement the framework without drowning in documents. It is written for security architects, GRC leads, system owners and authorising officials in US federal agencies, their contractors and private organisations that adopt the RMF voluntarily. The control catalogue itself (SP 800-53) and the detailed risk assessment method (SP 800-30) are covered in their own guides; this page is about the life cycle that connects them.

Key takeaways

• Seven steps, not six: Rev. 2 (December 2018) added Prepare in front of Categorize, Select, Implement, Assess, Authorize and Monitor, and most RMF failures trace back to skipping it.
• The RMF is a decision process: its output is a named senior official accepting a stated level of residual risk for a defined boundary, not a binder of controls.
• Common controls do the heavy lifting: identifying controls once at organisation level and letting systems inherit them is how large estates keep authorisation affordable.
• Continuous monitoring replaces the three-year cycle: SP 800-37 Rev. 2 supports ongoing authorisation driven by monitoring data, and SP 800-137 explains how to build that programme.
• Identities define the boundary in practice: service accounts, workload identities and API keys that cross the authorisation boundary are where inherited assumptions most often break.

What it is and who it applies to

NIST Special Publication 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, was published on 20 December 2018. It superseded Rev. 1 (2014) and describes the RMF as a disciplined, structured and flexible process for managing security and privacy risk, covering categorisation, control selection, implementation and assessment, system and common control authorisations, and continuous monitoring.

• Mandatory audience: US federal agencies operating information systems under FISMA, and through contracts the service providers that build or run systems for them. FedRAMP's cloud authorisation process is built on the same concepts. See the FedRAMP Guide.
• Voluntary audience: any organisation that wants a repeatable way to decide whether a system's residual risk is acceptable. The RMF is technology neutral and can be applied to cloud services, OT, AI systems and SaaS.
• Current status (checked 24 October 2026): Rev. 2 is the current final version. The CSRC publication page lists no errata and no successor, the CSRC risk management news page has no 800-37 revision item after 2018, and no draft of SP 800-37 appears in the CSRC list of drafts open for comment. NIST updates the supporting control catalogue separately: SP 800-53 Release 5.2.0 (27 August 2025) changed SP 800-53 and SP 800-53A but not the SP 800-53B baselines. Check the CSRC page before relying on this status.
• What it is not: it is not a control catalogue (that is SP 800-53), not an assessment methodology (SP 800-30 for risk, SP 800-53A for controls), and not an outcome taxonomy like the NIST Cybersecurity Framework. See the NIST SP 800-53 Guide and the NIST CSF 2.0 Guide.

Where the RMF sits in the NIST risk family

Structure and key requirements

Each step has numbered tasks with stated inputs, outputs and responsible roles. NIST publishes a Quick Start Guide for each step and a roles and responsibilities crosswalk on the CSRC RMF project pages, which are the quickest way to brief a new system owner.

Roles that must be named

• Authorising official (AO): a senior official with budget and mission authority who formally accepts residual risk. The AO cannot delegate the decision itself.
• Risk executive (function): an individual or group that links system-level decisions to organisation-wide risk, so one AO does not accept a risk another part of the organisation cannot tolerate.
• Senior agency official for privacy (SAOP) and the senior agency information security officer: own privacy and security programme requirements.
• System owner: responsible for the system's plans, implementation and POA&M.
• Common control provider: owns inherited controls (identity provider, logging platform, data centre) and their own authorisation.
• Control assessor: performs assessments with the independence the AO requires; for moderate and high systems this is normally a separate team or third party.

Authorisation decisions

The authorisation package contains an executive summary, the security and privacy plans, the assessment reports and the POA&M. The AO renders a risk determination, chooses risk responses and approves or denies. Rev. 2 recognises authorisation to operate (or to use, for a service the organisation consumes), common control authorisation, ongoing authorisation fed by continuous monitoring, and also describes type, facility and joint authorisations and an interim authorisation to test. A denial is a valid outcome and should halt operation or trigger a remediation path.

Identity and NHI requirements

The RMF itself is control-agnostic, but identity decisions surface in almost every task. The places where they matter most:

• P-10 and P-11, assets and boundary: inventory service accounts, workload identities, OAuth applications, CI/CD tokens and API keys alongside servers. An identity that can act inside the boundary from outside it is an interconnection, not a detail. See the Service Account Security Guide.
• P-5 and S-3, inherited identity controls: when IA and AC controls are inherited from a central identity provider, record exactly which parts are inherited (federation, MFA policy) and which remain system-specific (local accounts, application-level roles, non-federated service credentials).
• S-1 and S-2, control selection: make sure tailoring keeps AC-2 Account Management, IA-5 Authenticator Management and IA-9 Service Identification and Authentication applied to non-human accounts, not only to people.
• A-3, assessment: test that secrets are vaulted and rotated and that machine credentials are scoped, rather than accepting a policy document. See the Secrets Management Guide.
• M-1, change monitoring: new OAuth consents, new service principal credentials and new federation trusts are boundary changes that should trigger a security impact analysis.

The Microsoft Midnight Blizzard breach shows the cost of an incomplete P-10: a legacy non-production test tenant account without MFA, and a legacy test OAuth application with elevated access to the corporate environment, were enough to reach executive mailboxes. Neither would have been treated as low risk if they had been inside a documented boundary with an owner.

Implementation steps

1. Run Prepare at organisation level first. Name the AO population and risk executive function, write a risk management strategy with explicit risk tolerance statements (P-2), and approve an ISCM strategy (P-7) before the first system enters Categorize.
2. Publish the common control catalogue. List every control provided centrally (identity provider, SIEM, vulnerability scanning, physical security), its provider, its authorisation status and the evidence systems can cite (P-5). This single step cuts later assessment effort the most.
3. Pilot on two systems. Pick one moderate system with a cooperative owner and one cloud service. Define boundaries (P-11), register them (P-18) and categorise them (C-2), using SP 800-60 information types rather than gut feel.
4. Select from baselines, then tailor with reasons. Start from the SP 800-53B baseline, apply organisation-tailored baselines or overlays, and record why each control was scoped out or compensated. Store plans as structured data (OSCAL) where tooling allows, so they can be compared over time.
5. Assess with SP 800-53A procedures. Agree assessor independence and the assessment plan with the AO before testing starts (A-1, A-2); remediate quickly fixed findings before the report (A-5) and put the rest on the POA&M (A-6) with owners and dates.
6. Brief the AO on risk, not compliance. Present residual risk in business terms using the system risk assessment, with options: accept, mitigate with conditions, or deny. Record terms and conditions such as a reauthorisation trigger.
7. Move to ongoing authorisation. Once monitoring feeds (configuration, vulnerability, identity and log data) are reliable, agree with the AO which controls are assessed at what frequency and which events force a re-review (M-2, M-6).
8. Plan disposal. M-7 covers decommissioning: revoke the system's service accounts, certificates and API keys, and remove inherited trust relationships.

Rolling back: if a pilot shows the package is too heavy, the fix is usually to move controls into the common control catalogue or to automate evidence, not to drop tasks. Keep the original authorisation in force while a reauthorisation is in progress.

Decision guidance: scale and approach

Evidence and assessment

• Authorisation package: executive summary, system security and privacy plans (PL-2), security and privacy assessment reports (CA-2), POA&M (CA-5), and the signed authorisation decision (CA-6).
• Prepare evidence: risk management strategy (PM-9), risk framing (PM-28), authorisation process (PM-10), organisation risk assessment, system registration record and boundary diagram.
• Monitoring evidence: continuous monitoring reports (CA-7), security impact analyses for changes, and POA&M ageing.
• Assessment rigour: SP 800-53A procedures use examine, interview and test methods; the AO decides how much depth and coverage each control needs based on impact level.

Metrics that show the RMF is working

• Coverage: percentage of registered systems with a current authorisation decision, and number of systems operating without one.
• Inheritance rate: share of baseline controls satisfied fully or partly by common controls.
• POA&M health: number of overdue POA&M items and median age of high-risk items.
• Monitoring freshness: percentage of controls assessed within the frequency set in the ISCM strategy.
• Boundary accuracy: identities and assets discovered by monitoring that were not in the registered boundary.
• Time to authorise: median days from system registration to decision, tracked to show whether Prepare investment pays off.

Mapping to other frameworks

RMF Prepare task P-4 explicitly allows organisations to use CSF profiles, so an organisation that already maintains a CSF target profile can reuse it to tailor baselines. For contractors handling controlled unclassified information, see the NIST SP 800-171 and CMMC 2.0 Guide; for supplier risk feeding the RMF, the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.

Common pitfalls

• Skipping Prepare: without a stated risk tolerance, every AO decision is negotiated from scratch and similar systems get inconsistent outcomes.
• Boundaries drawn around servers, not trust: federation trusts, build pipelines and SaaS integrations sit outside the diagram while holding credentials that act inside it. The SolarWinds supply chain compromise combined a trusted update channel with stolen token-signing certificates and credentials added to application service principals, all paths a server-centric boundary would miss.
• Over-trusting inherited controls: the provider's authorisation covers the provider's controls only. In the Snowflake breach, Snowflake and Mandiant found no platform vulnerability; customer accounts without MFA, rotation or network allow lists were the gap, all customer-responsibility controls.
• Paper POA&Ms: items with no owner, no milestone and repeated extensions turn risk acceptance into silent permanent acceptance. See the Security Exceptions and Risk Acceptance Guide.
• Treating the ATO as the finish line: without M-1 and M-2, the package describes a system that no longer exists within a few months.
• Disposal forgotten: decommissioned systems leave behind service accounts, keys and trust relationships that nobody monitors.

Practitioner checklist

• Confirm the current status of SP 800-37 and the SP 800-53 release you assess against on CSRC before each authorisation cycle.
• Approve an organisation risk management strategy with explicit risk tolerance and an ISCM strategy before authorising systems.
• Publish a common control catalogue with providers, authorisation status and evidence references.
• Include service accounts, workload identities, OAuth apps and API keys in every system's asset inventory and boundary.
• Record tailoring and inheritance decisions with reasons, ideally in OSCAL.
• Agree assessor independence and the SP 800-53A assessment plan with the AO before testing.
• Give every POA&M item an owner, milestone and risk rating, and report overdue items to the AO.
• Define change thresholds that force a security impact analysis or reauthorisation.
• Move stable, well-monitored systems to ongoing authorisation.
• Revoke credentials and trusts as part of M-7 system disposal.

Standards and references

• NIST: SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
• NIST CSRC: About the RMF and Quick Start Guides
• NIST: SP 800-39, Managing Information Security Risk
• NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
• NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: FIPS 199, Standards for Security Categorization
• NIST CSRC: RMF Monitor Step and SP 800-137 resources

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · NIST CSF 2.0 Guide · FedRAMP Guide · Risk Register Template · GRC Maturity Model