A CMMC Level 2 assessment is a carefully specified piece of process engineering. The security requirements and assessment objectives are published, and the assessor can examine artifacts, conduct interviews, and test implementation. Judgment still matters, but the organization knows which requirements are in scope and what kind of evidence the assessment will seek. In Robin Hogarth’s vocabulary, that is closer to a kind learning environment: relatively stable rules, legible feedback, and a visible relationship between preparation 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 has many kind-environment properties:
- The 110 security requirements are drawn from NIST SP 800-171 Rev. 2 and do not change weekly.
- The assessment objectives are documented in NIST SP 800-171A.
- The assessment methods are explicit: examine, interview, and test, with assessor judgment about whether the objectives are satisfied.
- The feedback loop is comparatively short: findings are tied to named assessment objectives and recorded evidence.
- 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. Threat actors don’t operate inside that assessment.
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 2025 Cost of a Data Breach report put mean time to identify and contain a breach at 241 days across the organizations it studied. That vendor study is not a universal measurement of dwell time, but it illustrates the asymmetry: an assessment finding arrives on a schedule, while evidence that a defensive assumption failed may arrive months later. A quiet quarter might mean your controls worked, or it might mean you have not found the intrusion.
Adversaries adapt. Once a defensive technique is understood, operators can change tools, timing, infrastructure, or tradecraft to route around it. A control that caught yesterday’s campaign may still be useful, but its past performance is not a guarantee against the next one.
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 | Legible: findings map to assessment objectives | Delayed: breaches may remain undiscovered for months |
| 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 a predictable pressure on a security program operating across two environments with very different feedback properties. The assessable work has dates, owners, and visible completion criteria; exploratory threat work often has uncertain payoff. Erik Dane’s 2010 paper offers cognitive entrenchment as a useful conceptual warning about expertise becoming rigid, but it does not establish that CMMC assessment work causes that outcome.
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["Residual threat questions.<br/>The requirement alone does not answer them."]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
One way to find residual risk is to ask what a requirement proves, then list the attack paths that can remain even when it is satisfied.
The configuration management family (3.4.x) does not, by itself, prove that a trusted vendor’s signed firmware image is benign.
The incident response family (3.6.x) does not, by itself, prove that an organization can absorb and act on a credible notification from a customer, researcher, or government agency months after an intrusion begins.
The risk assessment family (3.11.x) can be satisfied without making adversary emulation a continuous practice. Whether that additional investment is warranted depends on the system, threat model, and contract risk.
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 disciplined architectural read is: meet the control, document the artifact, and move on. Spend the attention you save on the parts of the threat model the assessment cannot settle.
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.
Meeting the requirement doesn’t prove the system is defensible, and confusing the two is the core architectural mistake. 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 verifies the controls; the architect keeps anyone from mistaking that verification for the threat model.
Budget for both jobs explicitly: proving the required controls, and testing the threats that remain after those controls pass.
Sources
- 32 CFR Part 170: Cybersecurity Maturity Model Certification Program
- DFARS Subpart 204.75: Cybersecurity Maturity Model Certification
- NIST SP 800-171 Rev. 2
- NIST SP 800-171A: Assessing Security Requirements for CUI
- IBM (2025): Cost of a Data Breach Report summary
- Erik Dane (2010): Reconsidering the Trade-Off Between Expertise and Flexibility