Is Your Security Plan Telling the Truth?

Most government contractors believe their security plan describes how they protect the information they’re trusted with. Across more than 80 assessments, we’ve learned how often that belief holds, and how quickly a plan shows whether it does.

The size of the plan tells you nothing on its own. What matters is whether it’s true.

If you handle Controlled Unclassified Information (CUI), your contract already requires a System Security Plan (SSP) under NIST SP 800-171. If you don’t handle CUI, a plan is still the clearest way to show how you protect what the government gives you. Either way, the same question applies.

Certification timing still matters, and the program that verifies it isn’t going away what applies today but there’s a question underneath it that matters every day: can you show that your organization does what your plan says it does?

Anyone who relies on your plan will ask that question in some form: a prime deciding whether to trust you with its data, a contracting officer, a government assessor, your own leadership before they sign. It comes down to two expectations.

First: say what you do

NIST SP 800-171 requires you to develop, document and periodically update a System Security Plan (3.12.4). A strong one lets a knowledgeable reader understand your system boundary, where sensitive information lives, the technology and services behind it, who is responsible for what, and how each requirement is met. It describes the environment you have today, not the one you plan to have.

Anyone reading it will ask two things.

Does it describe your company, or a generic one? Starting from a template is fine. A plan that still reads like one is the problem. Watch for statements that say “the organization employs mechanisms” without naming the mechanism, or that describe an office server room when you run in the cloud. A real description of who can access your systems (3.1.1) says who approves an account, where it’s created, and how it’s removed when someone leaves.

Are the boundaries reasoned, or just drawn? Scope decides what you’re protecting. Why is the machine controller on the shop floor treated differently from an office laptop? What actually separates the “out of scope” network from the one holding sensitive data? Which responsibilities does your IT provider handle, and which stay with you? A line on a diagram is an assertion. A reasoned boundary survives the question “how do you know?”

Second: do what you say

If the plan says something happens, you should be able to show that it happens. For contracts that include it, the government keeps the right to assess that itself. (DFARS 252.240-7997, formerly 252.204-7020)

Two more questions follow.

Does the evidence match the claim? If the plan says multifactor authentication protects administrator and remote access (3.5.3), the settings should show it. If it says logs are reviewed weekly, there should be a record of those reviews. If your company reports a score or your leadership signs an affirmation, both rest on the evidence, not solely the document.

Does anyone recognize it as their own? Ask the person who runs a system how accounts get disabled. Their answer should match the documented process without them reading it first. If nobody recognizes it, it isn’t your process. It’s wishful thinking.

Demonstrated effectiveness is the standard

Every one of those questions asks the same thing: can you show it, or can you only say it? When the Department of War announced its review of CMMC in July 2026, it described the goal as replacing the bureaucratic compliance with “scalable, resilient cybersecurity measures.” That isn’t a retreat from rigor. It’s the rigor that was always the point.

We sell documentation, so we’ll say this plainly: pages prove nothing.

Volume was never what made anyone safer. Accuracy was — and you can see the difference before you open a single control.

This isn’t an argument for less documentation. It’s an argument for documentation that’s true.

None of this is new. It’s how assessments already work: examining records, interviewing the people who run the system, and testing that controls operate. In practice, demonstrated effectiveness has five marks:

• Evidence created by doing the work, not written for the assessment.
• Evidence over time, not a control switched on the week before someone checked.
• Evidence that traces to a claim: every statement in the plan points to something that proves it.
• People who can show it live, without reading from the document.
• A plan that changes when the environment does: updated, versioned and dated.

You should be able to explain not only that you believe you are protected, but how you reached that conclusion. An accurate plan is that explanation.

It’s also why we work the way we do. Every contractor answers the same requirements, but a machine shop, a cloud-only engineering firm and a research lab keep sensitive information in very different places, run by different people on different systems. A plan can only be true if it starts from the environment it describes, so we start with what kind of organization you are, and build the plan around how your work actually operates.

Where you are is fine. Where you say you are is the risk.

An honest System Security Plan and or Control Implementation Summary at the start of the journey, is worth more than a polished one that claims you’ve finished. The standard expects gaps; that’s what a plan of action is for (3.12.2). Your security plan says where you are, and your plan of action says how you get to the next step.

Cybersecurity is the journey. Compliance is the outcome. However, verification works next year or in five years, evaluating it will start by reading the same document.

Try it this week

Pick three requirements at random. Hand those descriptions to the person who runs that system and ask two questions: “Is this true?” and “What’s the next step?” The first tells you where you are. The second starts the journey from there.

Kieri Solutions is an Authorized C3PAO. We assess the CMMC Assessment Process as written, and we never assess an organization we’ve helped prepare.

Start with a conversation, not a contract.