The NIST Risk Management Framework (SP 800-37) is the most widely-imitated system security lifecycle in the world: seven steps that take an information system from "we intend to build this" to "a named official accepts the residual risk of operating it — continuously." Even outside US government, its logic shapes how regulated industries authorise systems. Here is each step as it actually operates, with the outputs that matter and the places programs stumble.
Step 0 in spirit: Prepare
Added in RMF revision 2, Prepare is the step everyone skipped informally for years — and paid for. It establishes context at two levels. At the organisation level: risk management roles, risk tolerance, a common control inventory, and an organisation-wide risk assessment. At the system level: mission description, system boundaries, stakeholders, and the system's place in the enterprise architecture.
The boundary decision is Prepare's hidden landmine. Draw the system boundary too wide and authorisation becomes unmanageable; too narrow and risk hides in the seams between systems. Every later step inherits this choice.
Categorize
Determine the impact level of the system — typically low, moderate or high — based on the worst-case impact of a loss of confidentiality, integrity or availability of its information (the FIPS 199 logic: the system inherits the high-water mark of its information types). Output: a documented categorisation, approved by the authorising official or designee.
The stumble: categorising by gut feel for the system instead of by its information types. A "boring" internal app processing one regulated data type categorises higher than instinct suggests — and the categorisation drives everything downstream.
Select
Choose the control baseline matching the categorisation (from the SP 800-53 catalog), then tailor it: apply scoping considerations, add controls for system-specific risk, designate common controls inherited from the organisation, and document every deviation with rationale. Output: an approved security plan listing the tailored control set.
Tailoring is not trimming. Removing a control without documented rationale isn't tailoring — it's unmanaged risk acceptance, made invisible.
Implement
Build and configure the controls, and — equally important — document how each is implemented in the security plan. The stumble here is implementation drift: what was built diverges from what was planned, and nobody updates the plan, setting up the Assess step to evaluate fiction.
Assess
An assessor — with independence proportionate to system impact — tests whether controls are implemented correctly, operating as intended, and producing the desired outcome. Outputs: a security assessment report, and a plan of action and milestones (POA&M) for every weakness found.
The POA&M deserves more respect than it gets: it is the institution's honest list of known deficiencies with owners and dates. A thin POA&M on a complex system signals a shallow assessment, not a clean one.
Authorize
The step the entire framework exists to reach. The authorising official — a senior official with authority and accountability — reviews the authorisation package (security plan, assessment report, POA&M), weighs residual risk against organisational tolerance, and makes an explicit, written decision: authorise (often with conditions and an expiry), or deny. Risk acceptance happens here, by name, on paper.
This is also the step exams love, because it operationalises a governance principle: accountability for risk acceptance cannot be delegated to the assessor, the engineer or the vendor. One named official answers.
Monitor
Authorisation is a snapshot; Monitor keeps it honest. Continuous monitoring tracks control effectiveness, configuration changes, new vulnerabilities and changes to the threat environment; significant change triggers reassessment and, where needed, reauthorisation. Mature programs evolve toward ongoing authorisation — risk posture maintained continuously rather than re-certified in panic every three years.
The stumble: treating Monitor as a tooling problem. Dashboards without defined triggers — what change, what finding, what threshold forces a decision — are surveillance, not monitoring.
The shape of the whole
| Step | Core question | Key output |
|---|---|---|
| Prepare | Are we ready, and what exactly is the system? | Context, roles, boundary |
| Categorize | How bad could a loss be? | Impact level |
| Select | Which controls, for this system? | Tailored baseline in security plan |
| Implement | Are they built as planned? | Implemented controls, updated plan |
| Assess | Do they actually work? | Assessment report, POA&M |
| Authorize | Is residual risk acceptable — says who? | Signed authorisation decision |
| Monitor | Is that still true? | Continuous posture, triggers |
For CISSP and CRISC purposes, three reliable testing patterns: ordering questions (know the sequence cold), "where does risk acceptance occur" (Authorize, by the authorising official), and "what does a significant change trigger" (reassessment under Monitor, possibly reauthorisation). For practitioners, one takeaway outranks the rest: the RMF's genius is not the paperwork — it is forcing a named human to look at honest evidence and own the word yes.