Editor’s note: This is part two of a three-part blog series highlighting several aspects of preparing for CMMC program success.
Part 1 of this blog series focused on the scope decision: which Department of War (DoW) work you want and what you’re choosing not to pursue. If that decision led you to Controlled Unclassified Information (CUI) work and Level 2 certification, this post is about what comes next: how you’ll structure your environment to protect CUI and, more importantly, how you’ll govern the build.
Choose Your Architecture with Eyes Open
There are a few common models. Some organizations pursue whole-enterprise compliance, bringing their entire IT environment into scope. Others build a segmented enclave, isolating CUI workflows from the rest of the business. Others stand up a separate legal entity for defense work.
Cost and complexity pull in different directions here. Whole-enterprise compliance avoids the overhead of maintaining separate environments, but the compliance surface is large and some system changes carry CMMC implications. A separate enclave narrows the compliance boundary, but the engineering effort to segment, monitor, and maintain that boundary is significant. A carved-out entity limits organizational exposure but introduces operational duplication and legal complexity.
The right model depends on how much of your revenue comes from CUI-bearing contracts, how intertwined your defense and commercial IT environments are and what your organization can sustain operationally. Make the decision, resource it and move forward. What matters next is protecting whatever you chose.
Engineering and Compliance Are Partners
Before you break ground on an enclave or start configuring systems, you have to get one thing right: the relationship between engineering and compliance.
CMMC is a DoW compliance program. The assessor evaluates your environment against 320 assessment objectives, and engineering decisions either satisfy those objectives or they don’t. When engineering treats compliance as an advisory function that gets consulted after decisions are made, the architecture erodes through a hundred small choices that nobody flags as scope changes.
I’ve seen this pattern repeatedly in Level 2 builds. Engineers optimize the enclave design. Stakeholders surface new requirements. Each change makes sense in isolation, but without a structure that forces the question, “Does this affect our CUI boundary?” scope drifts. By the time anyone notices, the SSP no longer reflects the environment and remediation becomes a project of its own.
The fix is straightforward: establish engineering and compliance as equal partners from day one. Both functions at the table, both with authority, neither moving without the other weighing in.
Stand Up a Change Control Board Before You Build
The mechanism that makes this partnership operational is a Change Control Board (CCB). Most organizations know they need one eventually. The mistake is waiting until the first scope crisis to create it.
Stand up the CCB before the build starts. If your business is small, you can create a lightweight CCB. Define its membership: engineering, security, compliance, and a business owner who can make scope decisions. Establish a simple rule: no system change, no vendor addition, no architectural adjustment happens without a CCB review that answers two questions. Does this change our CUI footprint? And if so, who authorizes that?
The CCB keeps your architecture stable and creates a defensible record. When an assessor asks why your environment is configured a certain way, you have documentation showing what changed, when and who approved it. Organizations without this discipline spend months building an enclave only to discover that incremental decisions have expanded their boundary beyond what they scoped, budgeted, or can sustain.
Draft the SSP on Day One
The System Security Plan describes how your environment meets each CMMC security requirement. Most organizations treat it as something to write after the build is complete: stand up the enclave, configure the systems, then document what you did.
That sequence is backwards. Draft the SSP on day one and build it alongside the enclave.
The SSP, written in parallel with the build, becomes a design discipline. Every engineering decision gets tested against the control objectives in real time. You can’t document how you satisfy a requirement if you haven’t thought through how the system will meet it. The SSP prevents the build team from drifting into a configuration that works from an engineering standpoint but doesn’t satisfy the controls.
This approach also collapses what typically becomes a painful multi-phase cycle: build, document, discover gaps, remediate. When the SSP travels with the build, misalignments get caught while they’re still cheap to fix. The SSP you end up with reflects the environment because it shaped the environment.
And the teams doing the work experience it differently. Writing as you build feels like capturing progress. Writing after the fact feels like a compliance tax.
The Discipline Is the Differentiator
Architecture decisions get a lot of attention in CMMC planning. Enclave vs. whole-enterprise, cloud vs. on-prem, which MSP to use. Those choices matter, but the organizations that succeed are the ones that protect their architecture through disciplined governance with engineering and compliance working as equals, a CCB that enforces scope control and an SSP that governs the build from day one.
Get these three things right, and your CMMC program has a foundation. Skip them, and you’ll find yourself in SSP purgatory, constantly updating documentation to chase an environment that won’t stop moving.
Next in this series: the metrics that connect CMMC to business outcomes.
