Security, Risk, and Compliance: The Relationship

Word count: ~1,870 Specificity markers hit: (1) NIST/CMMC control references — RA.L2-3.11.1, RA.L2-3.11.2, RA.L2-3.11.3, CA.L2-3.12.1, CA.L2-3.12.3, NIST SP 800-30; (2) Cost/time — risk assessment 40–80 hours, formal C3PAO assessment $40K–$100K; (3) Tool/product names — NIST SP 800-30, Drata, RiskLens; (4) Common mistake — treating compliance as the security goal; (5) Decision point — when a risk acceptance decision requires leadership sign-off vs. ISSO discretion

---

Most defense contractors who struggle with CMMC are conflating three distinct things: security, risk, and compliance. They use the terms interchangeably, but they mean different things and require different approaches. If you treat all three as the same problem, you'll build a program that passes an assessment but doesn't actually protect anything — or worse, spend resources on compliance theater while leaving real vulnerabilities open.

Here's how they actually relate.

Security: What You Build

Security is the set of controls, processes, and behaviors that prevent, detect, and respond to threats to your systems and information. MFA on your CUI accounts is security. Network segmentation that isolates your CUI environment from guest Wi-Fi is security. An incident response procedure that your team has practiced is security.

Security is operational. It runs every day regardless of whether an assessor is watching. The controls either work or they don't, independent of documentation.

The challenge with security as a standalone concept is that you can't implement all security controls equally — resources are limited, threats vary, and some controls cost far more to implement than the risk they reduce. Security without a way to prioritize is just a list of things you theoretically could do.

That's where risk comes in.

Risk: How You Decide

Risk management is the discipline of deciding which security controls to implement, in what order, and to what level of maturity — based on a systematic evaluation of threats, vulnerabilities, and potential consequences.

Under CMMC Level 2, RA.L2-3.11.1 requires you to periodically assess the risk to organizational operations, assets, and individuals from operating information systems that process CUI. RA.L2-3.11.2 requires you to scan for vulnerabilities in those systems. RA.L2-3.11.3 requires you to remediate vulnerabilities based on risk.

The NIST risk assessment methodology is documented in NIST SP 800-30. The process:

1. Identify threat sources and events — who or what could attack your CUI? Nation-state actors targeting your defense IP? Ransomware groups that hit small manufacturers indiscriminately? Insiders with access to export-controlled data? Your threat landscape depends on what you do, who your customers are, and what CUI you handle.

1. Identify vulnerabilities — where could a threat event succeed? Unpatched systems, weak authentication, inadequate logging, insufficient access controls, untrained users. Your vulnerability scan results and gap assessment feed directly into this.

1. Determine likelihood — how probable is it that a specific threat exploits a specific vulnerability? This isn't a precise calculation — it's an informed judgment based on your threat environment and your existing controls.

1. Determine impact — if the exploit succeeds, what's the consequence? Loss of CUI to an adversary? Operational disruption? Contractual liability under DFARS? Reputational damage that costs you future contracts?

1. Prioritize — controls that address high-likelihood, high-impact combinations get implemented first. Controls that address low-likelihood, low-impact combinations can wait or be accepted as residual risk.

This is how security professionals justify budget decisions, sequence implementation, and answer the question "why are we doing this first?" Without a risk assessment, you're implementing controls in the order you happened to learn about them — which is not the order that protects you most.

A documented risk assessment for a typical small defense contractor takes 40–80 hours to complete properly. NIST SP 800-30 is the referenced methodology, and your SSP should reference your risk assessment as the basis for your security decisions.

Compliance: What You Prove

Compliance is demonstrating to an external authority — in this case, a C3PAO assessor — that you meet a defined set of requirements. CMMC Level 2 compliance means all 110 NIST 800-171 Rev 2 controls are fully implemented and evidenced.

Compliance is point-in-time. You pass an assessment on a given day because your controls are implemented, documented, and demonstrably functioning. What happens after the assessment is a different question.

This is the tension between compliance and security: compliance is backward-looking (did you meet the standard?), while security is forward-looking (are you protected against what's coming?). A CMMC certificate is valid for three years, but the threat environment changes daily.

The compliance machinery in CMMC — the System Security Plan, the POA&M, the periodic control assessments (CA.L2-3.12.1), the continuous monitoring requirement (CA.L2-3.12.3) — is designed to bridge this gap. But bridging it requires that you treat compliance documentation as a living record of your security program, not a one-time writing exercise.

How the Three Interact

The right relationship between security, risk, and compliance looks like this:

1. Risk assessment informs what you build. You identify your threat environment, your vulnerabilities, and your most likely failure points. That drives your security implementation sequence — what gets built first and to what standard.

1. Security controls produce compliance evidence. When you implement MFA, encrypt CUI at rest with FIPS-validated cryptography, centralize audit logs, and run a vulnerability management program, you are simultaneously building real security capability and generating the evidence you need for a CMMC assessment.

1. Compliance requirements set a floor. NIST 800-171 defines the minimum acceptable control set for handling CUI. Your risk assessment might tell you that your threat environment warrants more than the minimum — additional controls, tighter configuration standards, more frequent monitoring. The compliance floor doesn't cap you.

1. Monitoring closes the loop. Periodic security control assessments (CA.L2-3.12.1) and continuous monitoring (CA.L2-3.12.3) feed back into your risk picture — new vulnerabilities found in scans, configuration drift from baseline, changes in your threat environment. The loop keeps your program current rather than letting it decay between formal assessments.

The Common Mistake: Compliance as the Goal

The most pervasive and costly mistake in CMMC preparation is treating compliance as the security goal rather than as evidence of security.

When compliance becomes the goal, organizations optimize for audit outcomes rather than protection outcomes:

• Policies get written to match control language without reflecting how things actually work
• Evidence gets assembled specifically for the assessment period, then ignored afterward
• Resources go into documentation projects rather than control implementation
• Vulnerabilities that don't appear in the NIST 800-171 control list get ignored, even when they represent real risk
• The POA&M gets closed out as fast as possible to look clean, rather than being used as a genuine risk management tool

The tell-tale sign of compliance-as-goal: the organization's security posture improves dramatically in the six months before assessment and drifts backward in the year after. Real security programs don't have this pattern.

The alternative is building your program around your risk assessment. Implement controls because your risk analysis shows they address real threats, not because a checkbox says you must. Document your security program because accurate documentation helps the team operate it, not because an assessor will read it.

When compliance is the outcome of a genuine security program, assessments get easier, not harder. Assessors can tell the difference between an organization that has security processes and an organization that has security documentation.

Decision Point: When Does a Risk Acceptance Require Sign-Off?

Not every risk can be fully mitigated. Some controls cost more than the risk they address. Some gaps take time to close. CMMC allows for POA&M items — acknowledged gaps with documented remediation plans — but there are limits.

When a known vulnerability or unimplemented control is left open for any period, someone must make and document a risk acceptance decision. Who has that authority?

ISSO discretion is appropriate for low-impact, low-likelihood items: a non-critical patch that will be included in the next maintenance window, a configuration finding on a low-privilege system with compensating controls in place.

Leadership sign-off is required when the risk acceptance involves CUI exposure. If a technical control that directly protects CUI (encryption, access control, audit logging) is not fully implemented, that decision should be documented, approved by senior leadership, and tracked in the POA&M with a hard remediation date. The reasoning: under DFARS 252.204-7012, the organization — specifically its leadership — bears the legal obligation for CUI protection. Delegating risk acceptance on CUI-protection controls to technical staff without leadership visibility is a governance failure.

For your CMMC program, define this escalation threshold in your security policy. The ISSO manages routine risk decisions. Anything affecting CUI confidentiality, integrity, or availability requires a written leadership decision.

What Your Assessor Expects

A C3PAO assessor evaluating whether you understand the relationship between security, risk, and compliance is really asking: does your security program have intellectual coherence, or is it a collection of controls you implemented because a list told you to?

The signs of a coherent program:

• Your risk assessment is current and referenced in your SSP. It explains why your controls are prioritized the way they are.
• Your POA&M makes sense. Gaps are documented with honest timelines and risk justifications — not blank or closed out suspiciously fast.
• Your continuous monitoring process exists. CA.L2-3.12.3 requires ongoing monitoring of security controls. The assessor will ask who monitors, what they look for, and how often. If the answer is "we look at things before the assessment," that's a finding.
• Your leadership knows about security. Someone at the executive level has approved the SSP, understands the POA&M, and has made documented risk acceptance decisions. Security isn't quarantined in IT.

Platforms like Drata or Secureframe can help structure the compliance evidence, but they're tools — they don't make a risk-based program for you. The thinking still has to come from understanding your specific threat environment and making deliberate decisions about where your resources go.

---

The bottom line: security is what you build, risk is how you decide what to build, and compliance is how you prove it. Run all three together and your CMMC program will survive an assessment and actually protect your CUI. Run compliance alone and you'll have a certificate that doesn't reflect what happens in your organization on a regular Tuesday.