Skip to main content
govconCyber — Federal Cybersecurity Law Reference

Learn

Risk Management

How federal contractors turn cybersecurity from a one-time checklist into a managed program — the NIST Risk Management Framework (RMF) and Cybersecurity Framework (CSF 2.0) explained in plain English, and how both connect to the obligations you already carry.

Overview

Every cybersecurity rule a federal contractor has to follow — FAR 52.204-21, NIST SP 800-171, CMMC, a FedRAMP authorization — is really an answer to one underlying question: *is the risk to this information acceptable?* Risk management is the discipline of answering that question on purpose, with evidence, instead of by accident.

The federal government does not treat security as a fixed list of boxes to tick. It treats it as a continuous process: identify what could go wrong, decide how much of that you are willing to live with, put controls in place that match that decision, and keep checking — indefinitely — that the controls still work. Two documents from the National Institute of Standards and Technology (NIST) define how that process runs, and almost everything else you meet in government contracting sits downstream of them. The Risk Management Framework (RMF) — NIST Special Publication 800-37 — is the *process* the government uses to authorize a system to operate and to keep watching it afterward. The Cybersecurity Framework (CSF) 2.0 is the *common language* for describing and governing cybersecurity risk across an organization, from the server room to the boardroom.

You do not have to be a security engineer to use either one. This page explains what each is for, how they differ, how they connect to the specific obligations elsewhere on this site, and how a contractor can stand up a defensible, risk-based compliance program.

Two NIST tools, two different jobs

People often blur "RMF" and "the NIST framework" together. They are different tools built for different purposes, and knowing which one someone means saves a lot of confusion.

The Risk Management Framework (SP 800-37 Rev. 2) is mandatory machinery for the federal government. It is the step-by-step process by which a federal system earns an Authorization to Operate (ATO) — a senior official's formal decision to accept the risk of running that system. RMF is detailed, document-heavy, and built around federal information systems. It is the engine underneath FISMA, FedRAMP, and the state-level GovRAMP program.

The Cybersecurity Framework (CSF 2.0) is voluntary and deliberately flexible. It does not tell you *which* controls to implement; it gives you a vocabulary — six Functions broken into Categories and Subcategories — for organizing whatever security program you already have, comparing where you are today against where you want to be, and communicating that picture to non-technical leaders. It scales from a two-person shop to a multinational.

A useful way to hold the difference: RMF is how a system gets authorized; CSF is how an organization talks about and governs its risk. Most contractors will feel RMF indirectly, through the standards derived from it, and use CSF directly, as an organizing structure. The two are designed to be used together, and NIST cross-references them throughout.

The Risk Management Framework: seven steps

The RMF organizes the life of a system into seven steps. The first, *Prepare*, was added in Revision 2 (December 2018) to get the groundwork done before the cycle begins. The remaining six run in order and then loop, because risk management never actually stops.

  • 1. Prepare. Get the organization and the system ready: assign roles, set a risk tolerance, identify what you most need to protect, and run an initial risk assessment. This is where leadership decides how much risk is acceptable — a decision that colors every step after it.
  • 2. Categorize. Classify the system by the impact a loss of confidentiality, integrity, or availability would cause — low, moderate, or high (FIPS 199, with help from SP 800-60). A payroll system and a public brochure site do not need the same protection, and categorization is how the framework right-sizes everything that follows.
  • 3. Select. Choose the security controls that fit the category. The control catalog is NIST SP 800-53 (Release 5.2.0, updated August 2025), which offers pre-built baselines for low, moderate, and high systems that you then tailor to the system's real conditions.
  • 4. Implement. Actually put the controls in place — configure systems, write policies, deploy technology — and document how each control is implemented in a System Security Plan (SSP). The SSP is the system's security story of record, and it is the document assessors and contracting officers ask for first.
  • 5. Assess. Have an independent reviewer test whether the controls are implemented correctly and working as intended (the methodology lives in SP 800-53A). Gaps that cannot be fixed immediately go onto a Plan of Action and Milestones (POA&M) with owners and deadlines.
  • 6. Authorize. A senior authorizing official reviews the SSP, the assessment results, and the POA&M, and makes a documented, risk-based decision to accept the residual risk and grant — or deny — the ATO. This is the heart of RMF: accountability for risk is assigned to a named human being, not diffused across an IT department.
  • 7. Monitor. Watch the controls and the threat environment continuously, report changes, and feed anything significant back into the earlier steps. Continuous monitoring (SP 800-137) is what keeps an authorization meaningful instead of a snapshot that decays the day after it is signed.

If those operational steps feel familiar, that is the point: NIST SP 800-171 — the standard for protecting Controlled Unclassified Information (CUI) in nonfederal systems — is essentially the RMF control set distilled for contractors, and the SSP / POA&M / continuous-monitoring rhythm carries straight over into CMMC.

The Cybersecurity Framework 2.0: six functions

Where RMF is a process, the CSF is a *taxonomy*. Its core organizes all of cybersecurity into six Functions. The first five describe the operational lifecycle of managing a threat; the sixth — added in version 2.0 (2024) — wraps around all of them and is about leadership and accountability.

  • Govern (new in 2.0). Establish and monitor the organization's cybersecurity risk-management strategy, expectations, and policy. Govern is where roles, accountability, risk tolerance, supply-chain risk, and oversight live. Its addition was NIST's acknowledgment that cybersecurity is an enterprise-risk and leadership problem, not just a technical one.
  • Identify. Understand what you have and what could go wrong — assets, data, suppliers, and the risks to them. You cannot protect what you have not inventoried.
  • Protect. Put safeguards in place — access control, training, data security, configuration management — to limit or contain the impact of an event.
  • Detect. Find attacks and anomalies quickly through monitoring and analysis. Time-to-detection is one of the largest drivers of how bad an incident becomes.
  • Respond. Take action once something is detected — contain it, communicate, and manage the incident.
  • Recover. Restore the affected capabilities and operations, and learn from what happened so the next cycle is stronger.

Two more pieces make the CSF usable in practice. Profiles let you describe your *current* state and your *target* state, so the gap between them becomes a prioritized roadmap. Tiers (1–Partial through 4–Adaptive) describe how rigorous and integrated your risk-management practices are — a maturity gauge, not a grade. CSF 2.0 also sharpened its emphasis on cybersecurity supply-chain risk management (C-SCRM), which matters enormously to contractors who pass requirements down to subcontractors through flow-down clauses.

How the frameworks and control catalogs fit together

These pieces are layers, not competitors. CSF gives you the high-level language and governance structure — *what outcomes do we care about, and who is accountable?* RMF gives you the repeatable process to achieve and authorize those outcomes for a given system — *how do we categorize, control, assess, authorize, and monitor?* SP 800-53 is the master catalog of controls RMF selects from. SP 800-171 is the contractor-facing subset of those controls, scoped to protecting CUI in nonfederal systems. CMMC is the Department of Defense's verification that a contractor has actually implemented 800-171 (and, at higher levels, 800-172). And FedRAMP (federal cloud) and GovRAMP (state and local cloud) apply RMF and 800-53 baselines to cloud service offerings.

So when a contract clause points you at 800-171 or CMMC, you are standing on the RMF foundation whether or not anyone says the words "Risk Management Framework." Understanding the framework underneath makes the specific requirements stop looking arbitrary. Compare the standards side by side on the Frameworks page.

What this means for a contractor

Most contractors are not running a federal ATO themselves — that responsibility sits with the agency that owns the system. But the contractor inherits the framework's logic in concrete, contract-enforced ways.

  • Your SSP is not optional. Under DFARS 252.204-7012, a contractor handling CUI must have a System Security Plan describing how it meets each 800-171 control, plus POA&Ms for any gaps. These are the same artifacts RMF produces at the Implement and Assess steps.
  • Your SPRS score is a risk statement. The self-assessment score you post to the Supplier Performance Risk System is, in effect, a quantified measure of residual risk against the 800-171 baseline. A low or missing score can cost you a DoD award.
  • CMMC turns self-attestation into verification. Higher-impact CUI work increasingly requires a third-party assessment — the RMF "Assess" step, performed by an outside assessor instead of by you.
  • Continuous monitoring is a contractual duty, not a courtesy. The Monitor step shows up as obligations to maintain controls, report cyber incidents within tight windows, and keep your plans current. See The Cyber Incident Reporting Landscape.
  • Supply-chain risk flows downhill. CSF 2.0's Govern and C-SCRM emphasis mirrors the flow-down clauses that push your obligations to subcontractors. Their weakness becomes your risk, and managing it is now an expected part of governance.

The practical takeaway: treating compliance as a one-time project that ends at award is the single most common — and most expensive — mistake. The frameworks are explicitly cyclical because the risk they manage never holds still.

Building a risk-based compliance program

You can assemble a defensible program by combining the CSF's governance lens with the RMF's operational cadence. The Department of Justice's guidance on evaluating corporate compliance programs asks three blunt questions that make a useful north star throughout: Is the program well designed? Is it applied in good faith? Does it actually work? A risk-based cybersecurity program should be able to answer "yes" to all three, with evidence.

  • Phase 0 — Risk analysis and governance. Before anything else, decide who is accountable and how much risk leadership is willing to accept (CSF *Govern*; RMF *Prepare*). Without this, every later decision is unanchored.
  • Phase 1 — Assess and scope. Inventory your systems, data, and CUI; determine which contracts and clauses apply; and run a self-assessment against the relevant baseline to find the gaps (CSF *Identify*; RMF *Categorize* and *Assess*). This is your current-state Profile.
  • Phase 2 — Draft. Write the policies, the System Security Plan, and the POA&M that describe your target state and the path to it (RMF *Select* and document).
  • Phase 3 — Implement. Deploy the controls and operationalize the policies across the whole organization, not just IT (CSF *Protect*; RMF *Implement*).
  • Phase 4 — Evaluate. Test whether the controls work, remediate findings, and update the SSP and POA&M; where required, bring in an independent assessor (CSF *Detect* and *Respond*; RMF *Assess* and *Authorize*).
  • Phase 5 — Continuously monitor. Keep watching the controls and the threat landscape, report and respond to incidents, and feed material changes back to leadership so risk tolerance and priorities stay current (CSF *Detect*, *Respond*, and *Recover*; RMF *Monitor*).

The loop then restarts. Senior management watches for anything that shifts the organization's risk tolerance; IT and compliance staff keep the controls healthy day to day.

Common pitfalls

  • Treating the SSP as paperwork. An SSP that does not match reality is worse than none — it can become evidence of a knowing misrepresentation under the False Claims Act.
  • Letting the POA&M go stale. Open items with no owner or no date signal a program that is designed but not applied in good faith.
  • Confusing a framework with a control set. CSF tells you *what outcomes* to manage; it does not list the controls. You still need 800-171 or 800-53 for the "how."
  • Stopping at award. Authorization and monitoring are continuous. A control environment that is never re-checked is a finding waiting to happen.
  • Ignoring the supply chain. Your subcontractors' weaknesses are your risk; flow-down clauses make that explicit.

Where to go next

References

Was this page helpful?