A CMMC Level 2 assessment is, at its core, a beautiful piece of process engineering. The control families are stable. The assessment objectives are documented. The evidence requirements are explicit. The assessor wants artifact X, you produce artifact X, the artifact is either acceptable or it is not, and the loop closes cleanly. The whole thing is, in Robin Hogarth’s vocabulary, a kind learning environment: stable rules, immediate feedback, tight coupling between effort and outcome.
The threat actors looking at your environment do not care about your SSP.
This is the problem. CMMC L2 is a kind sub-environment bolted onto a wicked super-environment, and the temptation, organizationally and economically, is to let the kind side absorb all the energy because the kind side is the one that gives you feedback.
What “kind” means here
Hogarth’s distinction (Educating Intuition, 2001) between kind and wicked learning environments runs throughout David Epstein’s Range (2019), and it applies directly to security work. A kind environment has stable rules and direct feedback. A wicked environment has shifting rules, delayed feedback, and patterns that actively mislead.
By that test, the CMMC L2 assessment process is unambiguously kind:
- The 110 controls (drawn from NIST SP 800-171 Rev. 2) are stable. They are not changing weekly.
- The assessment objectives are documented in NIST SP 800-171A.
- The evidence requirements are explicit: examine, interview, test.
- The feedback loop is short: the C3PAO assessor either accepts the artifact or asks for a different one.
- The cycle is predictable: three-year reassessment, annual affirmation, defined remediation pathways.
If you are an organization that has any institutional muscle for kind-environment work (manufacturing process improvement, ISO 9001 quality systems, financial controls), CMMC L2 is recognizable. It rewards the same kind of effort.
The threat actors are not operating in that environment.
What “wicked” means in the threat landscape
The threat side has none of the properties that make CMMC L2 tractable.
The rules shift. A primitive that sat publicly undisclosed for nearly a decade (in-place crypto over user-controlled scatterlists, say) becomes a public local-privesc class the moment somebody notices it. The control catalog that addressed 2023’s threats does not address 2026’s.
The feedback is delayed and unreliable. IBM’s Cost of a Data Breach reports have put global mean-time-to-identify in the 190-to-210-day range, year after year. A quiet quarter might mean your controls worked, or it might mean you have not yet found the intrusion in progress. The reinforcement signal is mostly noise.
The adversaries adapt. The control you stood up to catch a specific TTP becomes the control the next campaign is designed around. Ransomware groups maintain internal documentation of which EDR products block which techniques. The pattern that worked yesterday is exactly the pattern that backfires today, because somebody else is now reading it as a tell.
These are the textbook properties of a wicked environment (Hogarth, 2001; Epstein, 2019), and they describe the side of the work the CMMC assessor cannot see.
| Property | CMMC L2 assessment (kind) | Threat landscape (wicked) |
|---|---|---|
| Rules | Stable: 110 controls from NIST SP 800-171 | Shifting: new primitive classes appear without warning |
| Feedback | Immediate: the assessor accepts or rejects the artifact | Delayed: mean time to identify runs around 200 days |
| Patterns | Reliable: meeting the control means what it says | Misleading: yesterday’s working control is today’s tell |
| Cycle | Predictable: three-year reassessment, annual affirmation | Open-ended: adversaries adapt continuously |
The bridging problem
The architectural job, in a CMMC L2 program, is bridging the two without letting the kind side absorb the wicked side. The failure mode is compliance theater: the program optimizes for the auditable thing because the auditable thing gives clean feedback. Effort directed at compliance produces a visible result; effort directed at the wicked threat surface mostly does not, until it does, by which point it is too late.
This is not a moral failure. It is the predictable outcome of a feedback-driven organism (a security team, a security program) operating across two environments with very different feedback properties. Of course the kind environment wins the calendar. Of course the wicked environment loses the budget fight. The structure of the problem makes those outcomes the default. Erik Dane’s work on cognitive entrenchment (Academy of Management Review, 2010) suggests that the longer a team operates in a kind environment with frequent positive feedback, the harder it becomes to update toward the wicked side at all.
A worked illustration. Consider control 3.5.3 in NIST SP 800-171: Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
The assessor checks: is MFA implemented? Is there evidence of enforcement? Are the privileged accounts inventoried? Is the access policy documented? If those answers are yes, the control is met. The kind-environment loop closes.
The threat actor asks a different question: is the MFA phishable? Is it bypassable through a session-token theft? Is the MFA tied to a device that can be enrolled by an attacker who has compromised the helpdesk workflow? Is the authentication boundary trusted by a downstream system that does not enforce its own MFA?
flowchart TD
C["Control 3.5.3, require MFA on<br/>privileged and network access"]
C --> A["Assessor's question (kind):<br/>Is MFA implemented and enforced?<br/>Are privileged accounts inventoried?"]
C --> T["Threat actor's question (wicked):<br/>Is the MFA phishable?<br/>Bypassable via session-token theft?<br/>Trusted by a downstream system?"]
A --> P["Control met. The loop closes."]
T --> R["Where the real risk lives.<br/>The SSP gives no credit for it."]The two questions are different. The first is necessary; the regulatory requirement is real. The second is the actual threat-driven question, and the SSP does not reward it. The architect’s job is to ensure that the second question gets asked, and that the budget for answering it does not get cannibalized by the budget for documenting the first.
Where to deliberately exceed the requirement
The fastest way to spot where compliance undershoots threat reality is to look at controls whose 800-171 language was last meaningfully revised before the relevant threat existed.
The configuration management family (3.4.x) was written before the modern firmware-supply-chain attack surface existed. Compliant configuration management does not stop a malicious firmware update from a trusted vendor’s signed image.
The incident response family (3.6.x) assumes a threat model in which incidents are discovered locally. It does not force an architecture for the threat model in which incidents are discovered by a third party (the FBI, a customer, a researcher) months after the fact.
The risk assessment family (3.11.x) is written for periodic, document-driven risk assessment, which is a kind-environment exercise. It does not require, and therefore does not reward, the kind of continuous, adversary-emulation-driven risk assessment that the wicked environment actually demands.
In each case, the compliant minimum is genuinely lower than the threat reality, and an architect who is doing the job rather than the compliance-theater version of the job builds in the gap deliberately.
Where to deliberately not gold-plate
The other half of the architect’s job is recognizing when additional rigor does not reduce wicked-environment risk and therefore should not be paid for.
A common mistake: treating every 800-171 control as if exceeding the requirement were always better. It is not. The compliance program has a fixed budget, both in dollars and in organizational attention. Energy spent over-engineering the audit log retention policy (which is a kind-environment control with a clean answer) is energy not spent on the wicked-environment problems where the same dollars compound.
The honest architectural read is: meet the control. Document the artifact. Move on. The energy you save goes to the wicked side, which is where the program’s actual risk lives.
What this means in practice
CMMC L2 is necessary. The Department of Defense’s adoption timeline (CMMC 2.0 rulemaking finalized in 2024, phased implementation now underway through the Defense Federal Acquisition Regulation Supplement) is making the kind-environment work a precondition for the covered contracts. For organizations pursuing that work, there is no skip-it option.
But “necessary” is not “sufficient,” and the temptation to confuse the two is the entire architectural problem. A clean assessment means you have implemented the controls the framework requires. It does not mean you can detect, respond to, or recover from an actual intrusion. The two questions are different, and the program needs both.
The architectural discipline, more than anything specific to controls, is the refusal to let the kind side absorb the wicked side. The auditor’s job is to verify the controls. The architect’s job is to ensure that the controls are not mistaken for the threat model.
That mistake is the CMMC problem. Solving it is the work.