Rewrite: the-risk-management-process-a-concise-overview

Word count: ~1,580

Specificity markers hit:

1. ✅ NIST/CMMC control references (RA.L2-3.11.1, RA.L2-3.11.2, CA.L2-3.12.1, CA.L2-3.12.3, NIST SP 800-30, NIST SP 800-39)
2. ✅ Cost/time estimate (full RMP implementation: 6–12 months for most contractors; annual review cycle)
3. ✅ Tool/product names (SPRS, NIST SP 800-171A, POA&M)
4. ✅ Common mistake (treating risk management as a one-time assessment vs. ongoing process)
5. ✅ Decision point with guidance (when to integrate risk management with operations vs. keep it separate)

---

The Risk Management Process: A Concise Overview

Risk management in cybersecurity isn't a single activity — it's a cycle. You identify risks, analyze them, decide how to respond, implement those responses, and then monitor to see if they worked. Then you do it again, because the environment changed.

For defense contractors under CMMC, this cycle is mandatory. NIST SP 800-39, "Managing Information Security Risk," describes it at the organizational level. NIST SP 800-30 provides the analytical methodology. CMMC's RA and CA domains require you to execute it. Understanding the process structure makes each piece easier to implement and easier to explain to an assessor.

Here's the overview.

Step 1: Frame the Risk

Before you can manage risk, you have to establish the context — the framework within which you'll identify, analyze, and respond to risks. NIST SP 800-39 calls this "establishing the risk context."

For a defense contractor, framing the risk means answering:

What are we protecting? Your CUI environment — the systems, data, and processes involved in handling Controlled Unclassified Information. This is your System Security Plan scope. Without a defined boundary, your risk management process has no anchor.

Who's threatening it? Nation-state adversaries targeting defense supply chain data, criminal organizations, and insider threats are the primary threat actors in the DIB. Your threat model should be specific to this context, not generic IT risk.

What's our risk tolerance? Different organizations have different thresholds. A large prime contractor may have mature risk management with quantified thresholds. A small subcontractor might use a simple High/Medium/Low scale with defined remediation timelines for each. Either approach works; what matters is that the threshold is defined and applied consistently.

What regulatory requirements apply? CMMC Level 2 specifies 110 controls. DFARS 252.204-7012 requires breach reporting within 72 hours. 32 CFR 170 requires annual self-assessment and SPRS reporting. These aren't optional — they're the compliance floor, and your risk management process must account for them.

Risk framing is documented in your risk management policy and SSP. It sets the stage for everything that follows.

Step 2: Assess the Risk

Risk assessment is the analytical step where you identify what could go wrong, how likely it is, and how bad it would be. This is the step most organizations shortchange — either skipping it entirely (assessing compliance without actually analyzing risk) or doing it once and never updating it.

CMMC requires periodic risk assessment under RA.L2-3.11.1. The methodology most commonly used — and expected by CMMC assessors — is NIST SP 800-30 Rev 1.

A complete risk assessment produces:

• A threat inventory — who or what could cause harm, and how
• A vulnerability inventory — gaps in your controls that threats could exploit (feeds directly from your SP 800-171A assessment and vulnerability scan results under RA.L2-3.11.2)
• Risk ratings — likelihood × impact for each threat-vulnerability pair
• A risk register — the documented output that drives Step 3

The risk assessment isn't a compliance checkbox. It's the analytical foundation for every decision that follows. If you skip it or do it perfunctorily, your remediation priorities will be wrong and your assessor will notice.

How often: annually at minimum, and whenever your system boundary or threat environment changes significantly. The first full assessment takes significant effort. Annual updates, if your documentation is current, are much faster.

Step 3: Respond to the Risk

With a risk register in hand, you make decisions. Four options for each identified risk:

Mitigate — Implement a control that reduces the risk. This is the default for any required CMMC control that's currently Not Implemented. Your POA&M documents the plan.

Accept — Acknowledge the risk and decide not to implement additional controls. Formal risk acceptance requires documentation of the rationale, compensating controls (if any), and management sign-off. Under CMMC, you can't accept a required control gap without a POA&M — acceptance applies to residual risk after controls are implemented, not to required control gaps.

Transfer — Shift the financial consequence through insurance or contractual arrangements. Transfer is a financial hedge only; it doesn't protect your CUI or fulfill your compliance obligations.

Avoid — Eliminate the risk by stopping the activity that creates it. Most applicable when evaluating new projects or capabilities; harder to execute for ongoing contract performance.

Your risk responses drive your POA&M under CA.L2-3.12.4. The POA&M is where mitigation decisions become concrete: specific actions, owners, and timelines. For most contractors, the POA&M is the primary working document of the risk management process.

Prioritization matters here. Not everything can be remediated simultaneously. Use your risk register to sequence remediation: address the highest-rated risks first, then work down. Remediation timelines should reflect risk ratings — critical findings within 30 days, high within 60, moderate within 90. Document the connection between risk ratings and timelines in your vulnerability management policy.

Step 4: Monitor the Risk

Implementing controls isn't the end. Controls drift. New vulnerabilities emerge. The threat landscape shifts. Continuous monitoring under CA.L2-3.12.3 maintains your visibility into whether your risk posture is where you think it is.

Monitoring has two components:

Technical monitoring — Automated collection of security-relevant data: vulnerability scan results, audit logs, configuration compliance checks, threat detection alerts. For most CMMC-level environments, this means a vulnerability scanner running on schedule, centralized log collection, and endpoint protection that reports malicious activity. The monitoring outputs feed back into your risk assessment as new data.

Programmatic monitoring — Reviewing security controls for continued effectiveness. Are controls still implemented correctly, or have they drifted from their original configuration? Has something changed in your environment that affects a previously assessed risk? CA.L2-3.12.1 requires periodic security control assessments; the findings from those assessments update your risk register and POA&M.

Monitoring is the step that distinguishes a living risk management program from a point-in-time exercise. If your last risk assessment was 18 months ago and nothing has been updated since, your risk register doesn't reflect your current posture. When your assessor asks about recent changes and how they affected your risk picture, "we haven't revisited it" is not a complete answer.

Step 5: Report on the Risk

Risk information needs to reach decision-makers — not just stay in the IT team's documents. Reporting is the bridge between technical risk analysis and organizational accountability.

For CMMC purposes, reporting means:

Internal reporting — Management needs to understand the current risk posture: what's the SPRS score, what's in the POA&M, what are the highest-risk gaps, what resources are needed to close them. This doesn't need to be elaborate — a quarterly briefing with a current risk register excerpt and POA&M status update serves the purpose.

SPRS submission — Your annual self-assessment score submitted to the SPRS portal under 32 CFR 170. This is an external report to the DoD. It must be accurate; the risk of a materially inaccurate SPRS score under the False Claims Act is real and significant.

Incident reporting — Under DFARS 252.204-7012, a cyber incident involving CUI must be reported to the DoD DIBNET portal within 72 hours. Your risk management process should include a trigger for incident reporting — it doesn't happen automatically.

Reporting isn't just bureaucratic compliance. It creates the organizational record that demonstrates your risk management process is active. When an assessor asks "how does management stay informed about your security posture?", the answer should be a specific, regular process — not "they get briefed when something major happens."

The Common Mistake: Treating Risk Management as a One-Time Assessment

The most reliable indicator that a risk management program is ceremonial rather than real: it was stood up for the CMMC assessment and hasn't been touched since.

Signs of this pattern: - Risk assessment dated 18+ months ago with no update record - POA&M with no items closed in the past year despite claimed remediation - Vulnerability scan results that are months old - SPRS score that bears no relationship to the current control environment (either the score was inflated or controls have degraded)

Risk management is a cycle. The effort front-loads to the first assessment and first POA&M build, then transitions to a maintenance cadence: annual assessment review, quarterly vulnerability scans, monthly POA&M review, continuous monitoring. For a contractor with a healthy posture and current documentation, the ongoing maintenance is 5–10 hours per month of ISSO time. The first 6–12 months of standing up the process are heavier.

That ongoing maintenance is what an assessor wants to see evidence of. Not a perfect security posture — that doesn't exist — but an active, functioning process that's actually tracking and responding to risk.

What Your Assessor Expects

A CMMC assessor evaluating your risk management program is looking for:

• A defined, documented process — not just a risk assessment document, but a policy describing how risk is framed, assessed, responded to, and monitored
• A current risk register — with dated ratings, risk decisions, and connection to your POA&M
• An active POA&M — items being closed, timelines being met, management involvement in risk decisions
• Ongoing monitoring — current vulnerability scan results, log collection evidence, control assessment history
• SPRS record — current and consistent with your known posture

The five-step cycle — Frame, Assess, Respond, Monitor, Report — gives you the organizing structure. Fill it with specific, documented, dated activity and you have a risk management program. Treat it as a series of forms to fill out and you have the appearance of one.

---

For a deeper look at any step, see NIST SP 800-30: The Risk Assessment Methodology or Aligning Risk Management with CMMC.