Cyber Risk Management Strategy for the DIB

Word count: ~1,900 Specificity markers hit: (1) NIST/CMMC control references, (2) cost/time estimates, (3) tool/product names, (4) common mistakes, (5) decision point with guidance — 5 of 5

---

# Cyber Risk Management Strategy for the DIB

Most defense contractors approach cybersecurity backward: they implement controls first, then try to figure out why those controls exist. That works for checkboxes. It doesn't work when something goes wrong, when an assessor asks how you prioritized your remediation, or when you're trying to explain your POA&M decisions to a contracting officer.

A cyber risk management strategy turns that sequence around. You identify your assets, understand what could go wrong, assess how bad it would be and how likely it is, and then implement controls in order of priority. For the Defense Industrial Base, this process has specific inputs (your CUI environment, your threat landscape, your contract obligations) and a specific output (a risk-informed security program that drives your CMMC controls).

Here's how to build it.

What CMMC Actually Requires in the Risk Assessment Domain

Before getting into strategy, let's be precise about the requirements. The Risk Assessment (RA) domain in CMMC Level 2 has three controls:

RA.L2-3.11.1 — Periodically assess the risk to organizational operations, assets, and individuals resulting from the operation of systems and the processing, storage, or transmission of CUI. This is the formal risk assessment. NIST SP 800-30 is the recognized methodology — it defines a risk assessment process that assessors understand and expect to see referenced.

RA.L2-3.11.2 — Scan for vulnerabilities in systems and applications periodically and when new vulnerabilities potentially affecting those systems and applications are identified. This is vulnerability scanning, not pen testing. Quarterly scans of your CUI environment are the common benchmark. Remediate based on severity: critical findings within 30 days, high within 60, medium within 90.

RA.L2-3.11.3 — Remediate vulnerabilities in accordance with risk assessments. The link between your risk assessment results and your remediation priorities. Your vulnerability scan findings need to connect to your risk assessment — high-severity vulnerabilities in your highest-criticality CUI systems get addressed first.

Three controls. But they anchor a much larger program, because how you assess risk determines how you prioritize every other control in your SSP.

Step 1: Asset Identification

You can't assess risk without knowing what you're protecting. Start with a complete asset inventory for your CUI environment:

Systems that process, store, or transmit CUI: File servers with CUI data, workstations used to access CUI, email systems transmitting CUI, cloud services processing CUI. Every system on this list is in your CMMC scope.

Security protection assets: Firewalls, SIEM systems, authentication servers, backup systems. These protect your CUI assets and are also in scope.

Data flows: Where does CUI enter your organization (email from contracting office, file transfers from prime, data created in performance of contract work)? Where does it live? Where does it go? Map every path.

Critical assets within that scope: Not all in-scope systems carry equal risk. Your CUI file server holds the most sensitive data. Your SIEM holds your audit logs — tamper with it and evidence disappears. Identifying which assets are most critical shapes your risk prioritization.

This step typically takes 20–40 hours for an organization with 10–100 people in the CUI scope. Use a spreadsheet or a GRC tool (Secureframe, Drata, or even a simple spreadsheet template from NIST's website) to build the inventory. The output becomes the asset table in your SSP.

Step 2: Threat Identification

The Defense Industrial Base faces a specific threat environment. Your risk assessment needs to reflect actual threats, not generic ones.

Nation-state actors: Chinese, Russian, and North Korean threat groups specifically target defense contractors for intellectual property, technical data, and operational information. The CISA and NSA advisories on Chinese threat actors targeting DIB (published regularly on cisa.gov) provide current, specific intelligence. These actors use spear phishing, supply chain compromise, and exploitation of internet-facing vulnerabilities as primary vectors.

Ransomware and financially motivated criminals: Defense contractors aren't immune from commodity ransomware. The $4.8 million average cost of a ransomware incident in the defense sector (per FBI IC3 reporting) understates the compliance and contract risk when CUI is affected. A ransomware incident affecting CUI systems triggers 72-hour DIBNET reporting under DFARS 252.204-7012, regardless of whether CUI was actually exfiltrated.

Insider threats: Unintentional disclosure is more common than malicious insiders, but both are real risks. AT.L2-3.2.3 requires insider threat awareness training because the vectors are real: employees forwarding CUI to personal email, saving CUI to unsanctioned cloud storage, sharing information with people who don't have authorized access.

Supply chain threats: Your organization's risk includes the security posture of your vendors and subcontractors. If a subcontractor or MSP with privileged access to your CUI environment is compromised, your environment may be compromised too.

Document the threat sources relevant to your organization in your risk assessment. Vague language ("external threat actors") doesn't help you prioritize. Specific threat scenarios ("spear phishing targeting engineers with CUI access") translate directly to specific controls (email filtering, phishing awareness training, MFA).

Step 3: Vulnerability Assessment

Threats become risks when they exploit vulnerabilities. Your vulnerability picture has two components:

Technical vulnerabilities: Unpatched software, misconfigured systems, missing encryption, overprivileged accounts, exposed management interfaces. This is what your vulnerability scanner finds. Tools: Tenable Nessus, Qualys, or Rapid7 InsightVM for network scanning; Microsoft Defender Vulnerability Management if you're in an M365 environment. A quarterly scan of your CUI environment satisfies RA.L2-3.11.2. Scan more frequently if you have internet-facing systems or active development.

Configuration and procedural vulnerabilities: Gaps in your controls that scanning won't reveal — no MFA enforced, no backup testing, no incident response plan, no CUI marking procedures. Your SSP gap analysis surfaces these. Tools like Secureframe and Drata help by continuously checking your configurations against your control requirements and flagging drift.

Combine both pictures into your vulnerability inventory. Rate each vulnerability by: - Severity (CVSS score for technical vulns; qualitative high/medium/low for procedural) - Affected asset criticality (the same severity vulnerability matters more on a CUI file server than on a printer) - Exploitability (is there active exploitation in the wild? has CISA added it to the Known Exploited Vulnerabilities catalog?)

Step 4: Risk Calculation and Prioritization

Risk = Likelihood × Impact. That's not just a formula — it's the basis for every prioritization decision in your security program.

Likelihood factors: - Threat capability (nation-state actors have high capability; unsophisticated criminals have lower) - Vulnerability exploitability (a vulnerability with a public exploit and active campaigns is more likely to be exploited than a theoretical weakness) - Your exposure (internet-facing systems face higher likelihood than air-gapped systems)

Impact factors: - Criticality of affected assets (CUI file server loss is higher impact than a CRMA compromise) - Scale of potential exposure (an account takeover on an admin account has higher impact than a standard user account) - Regulatory consequences (a CUI incident triggers DIBNET reporting, potential contract suspension, and CMMC remediation)

Build a risk matrix that rates each identified risk combination (threat × vulnerability × asset) as high, medium, or low. This matrix drives your POA&M prioritization — high risks that affect CUI get addressed first, and that's what you document in your SSP and POA&M to show the assessor your decision-making was risk-informed.

NIST SP 800-30 Rev 1 is the reference document for this process. Download it at nvlpubs.nist.gov — it's free, it's specific, and it's what your assessor expects to see referenced when they ask about your risk assessment methodology.

Step 5: Connecting Risk to Controls

The risk assessment output feeds directly into your CMMC control implementation priorities. High-risk findings drive which controls you implement first and how you justify your POA&M timeline.

Decision point: When you have limited resources and can't implement all 110 controls at once, the risk assessment tells you where to start. A mid-size defense contractor starting from minimal controls should prioritize in this order:

1. Access control and MFA (AC, IA domains) — the highest-impact controls for preventing unauthorized access
2. Encryption for CUI at rest and in transit (SC domain) — satisfies the core CUI protection obligation
3. Vulnerability management and patching (RA, SI domains) — directly required and actively assessed
4. Logging and monitoring (AU, SI domains) — both required and essential for detecting incidents
5. Incident response capability (IR domain) — 72-hour reporting is a hard deadline if you have an incident

Document why you prioritized this way in your risk assessment. When the assessor asks why some controls are in your POA&M, point to your risk matrix.

Step 6: Continuous Monitoring

Risk assessment isn't a once-a-year event. CA.L2-3.12.3 requires ongoing monitoring of security controls. What that looks like in practice:

Vulnerability scanning: Quarterly minimum, monthly if feasible, continuous if your tooling supports it. Track trending — are you getting better or worse over time?

Configuration drift monitoring: Your configurations should match your documented baselines. Any drift (someone changed a firewall rule, MFA got disabled on an account, a new system got added without going through change control) should generate an alert. Continuous monitoring tools do this automatically.

Log review: You're collecting logs per the AU domain requirements. Someone needs to actually look at them. Daily review of critical alerts from your SIEM. Weekly review of audit summaries. Monthly review of access control patterns.

Annual formal risk assessment: A full formal risk assessment per NIST SP 800-30 methodology, with updated threat intelligence, updated asset inventory, updated vulnerability picture. This refreshes your risk matrix, which refreshes your POA&M priorities.

The annual risk assessment typically takes 40–80 hours for a team with a mature program, or 80–120 hours for a first-year effort. Document it in a formal report and keep it with your SSP evidence package.

Common Mistakes

Treating the risk assessment as a check-the-box document. An assessor can tell in about five minutes whether your risk assessment actually informs your security program or whether it was written to satisfy a checkbox. If your risk assessment identified five high-priority risks and your POA&M addresses none of them, the disconnect is visible.

Ignoring the threat landscape specific to DIB. Generic corporate risk assessments don't reflect the nation-state threat environment that defense contractors operate in. Your risk assessment should reference current threat intelligence from CISA, NSA, and the DCSA (Defense Counterintelligence and Security Agency) — not just generic cybersecurity statistics.

Running vulnerability scans and doing nothing with the results. RA.L2-3.11.2 requires both scanning and remediation. A clean scanning program with no documented remediation is a finding. Assessors look for the connection between scan results and your remediation records.

Missing the connection between risk assessment and POA&M. Your POA&M is your risk management document. Every item on it should trace back to a control gap, and every control gap should trace back to a risk. If your POA&M items don't connect to your risk assessment, you have a documentation problem that will surface in the CA domain review.

What Your Assessor Expects

For the RA domain, your assessor will examine: - Your formal risk assessment document (methodology, threat sources, vulnerability findings, risk ratings) - Vulnerability scan results from the past 12 months - Evidence that high-severity vulnerabilities were remediated within your stated timeline - The connection between your risk assessment results and your POA&M prioritization

They'll interview your security officer or ISSO about the risk assessment process: When was it last updated? Who participated? What threat sources did you consider? What changed since the last assessment?

The assessor isn't looking for a perfect risk assessment methodology — they're looking for evidence that you're actually thinking about risk, not just documenting controls. A well-documented, honest risk assessment that acknowledges gaps and shows a credible remediation plan is better than a polished document that claims everything is fine.

---

Your risk assessment is the compass for your entire CMMC program. Build it before you start implementing controls — it will save you time, money, and assessment surprises.