The Open System Problem in CMMC Compliance

There is a distinction in CMMC compliance that most contractors have never been asked to think about, and that most consultants have no incentive to explain.

The distinction is between an open system and a closed system.

An open system, in this context, is a compliance environment where the contractor or their users can modify, bypass, or override the controls that are supposed to enforce the 15 Level 1 practices. The policies exist. The documentation exists. But the technical enforcement is optional because it depends on people following procedures rather than systems preventing violations.

A closed system is one where the controls are technically enforced. You can't share admin credentials because the system doesn't allow shared credentials. You can't access FCI from an unauthorized device because the system blocks unauthorized devices. The compliance isn't a set of rules people follow. It's a set of constraints the system imposes.

The vast majority of CMMC compliance setups in the current market are open systems. This isn't a secret. But consultants are actively avoiding this conversation because the moment a contractor understands the open/closed distinction, they understand that a closed system eliminates the need for ongoing advisory. The relationship between this distinction and the consulting business model is something most contractors haven't been asked to consider. The consultant's business model depends on the contractor remaining in an open system, one that requires continuous human judgment, continuous policy interpretation, and continuous advisory hours to maintain. A closed system that enforces controls technically doesn't generate follow-up work. So the distinction doesn't get explained.

The problem with open systems becomes apparent when you consider what the self-assessment actually certifies. When you sign your Level 1 attestation, you're certifying that the 15 practices are implemented. Not that you have policies describing them. Not that your employees have been told about them. That they are implemented.

In an open system, "implemented" means "we told people to do this and we believe they are doing it." In a closed system, "implemented" means "the system prevents the alternative."

The documentation gap that contractor groups are finding almost always traces back to this distinction. The documentation describes controls. The systems allow those controls to be bypassed. The person who signed the attestation certified implementation. But what was actually implemented was a suggestion, not a constraint.

The question of whether an open system "counts" as implementation under the applicable contract clauses is not clearly resolved. The language says the practices must be performed. It doesn't specify whether technical enforcement is required. But when the verification question comes, and it will, the contractor with a closed system has evidence that the practice was enforced. The contractor with an open system has evidence that the practice was recommended.

That's a meaningful difference when a federal signature is involved. And it's the distinction driving what some contractor groups are now calling locked verification, a fundamentally different approach to proving compliance.