The world’s largest bureaucracy is not for the faint-of-heart.

What CMMC Actually Is

CMMC Level 1 Self Assessment is based on FAR 52.204-21: Basic Safeguarding of Covered Contractor Information Systems. The gist of this FAR is basically this line:

Federal contract information means information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government, but not including information provided by the Government to the public (such as on public websites) or simple transactional information, such as necessary to process payments.

Basically, if you are touching federal contracts, you are touching FCI. And, you need to do you CMMC Level 1 self-certification. But, you don’t need to pay someone for it (thank goodness).

There are 17 controls in the CMMC Level 1 Self Assessment Guide, spread across 6 categories:

• Access Control (AC)

• Identification Authentication (IA)

• Media Protection (MP)

• Physical Protection (PE)

• Systems and Communications Protection (SC)

• System and Information Integrity (SI)

These are foundational controls, things like: limiting system access to authorized users, using strong passwords, and sanitizing media before disposal. If you are an optimist, you would say that this provides a level of rigor and maturity that will help your company in other aspects of your business. Otherwise, this is just another painful hoop you have to jump through.

There is a scoring methodology here that is a good reference as you work your way through this process.

What is a Self-Assessment

A CMMC Level 1 assessment is a self-assessment. This means no third-party auditor is required. Your company evaluates itself against 17 practices drawn from FAR 52.204-21, all focused on basic safeguarding of FCI.

To complete the assessment, a senior company official (typically your CEO or CISO or the person most willing to take on the responsibility) must affirm the results in the Supplier Performance Risk System (SPRS) and assign a score.

Wait….The SPRS? Why yes! Where can you find the SPRS you may ask? I will cover that a bit further down in The Hidden Friction of PIEE and SPRS. So don’t despair!

The score is binary per practice: you either meet it or you don’t, giving a maximum of 110 points. You also have to reassess annually and after any significant change to your environment. I have a little reminder for August of each year to review my assessment and reassess where things are.

The key things that trip contractors up: the affirmation requirement carries legal weight (False Claims Act exposure if you misrepresent compliance), and “self-assessment” doesn’t mean informal: you need documented evidence that each practice is actually implemented, not just assumed.

As always — do NOT free-lance and hope Uncle Sam accepts vibes.

Companies who shortcut requirements will result in more (expensive!!) requirements for third party verifications. Plus, you and your company will likely be barred from doing business with the Federal Government.

What CMMC Is NOT

CMMC Level 1 Self-Certification is not NIST 800-171. This took me a minute to figure this out and I will be writing about this in my next post. NIST 800-171 involves 110 controls and opens up access to some CUI contracts (if you self-certify).

CMMC is not a scored system.

So far, CMMC is not an audit (yet). There is a whole other discussion about the costs of these audits and how it can preclude small businesses from accessing federal contracting opportunities. That is something I will save for another post as well.

The Real Work and Where People Get Stuck

While CMMC Level 1 Self Assessment does not require a formal System Security Plan (SSP) — unlike the NIST requirements — I am a bit of a documentation junkie and believe that if you WRITE IT DOWN, it will be A LOT easier to maintain compliance going forward and to advance into different levels of security certification.

Policies: keep them lightweight

You don’t need a 50-page binder. You need five short documents that tell your team what the rules are and give an assessor something to point at. Each one should fit on a single page. If it’s longer than that, you’re writing a manual, not a policy.

For each policy: name a document owner, set a review date (annually is fine), and get a signature from whoever runs the company. That signature is what makes it a policy rather than a suggestion. If you’re a one-person shop, then you are all of those roles.

Access Control Policy

Covers who can access systems that touch FCI, how access is requested and approved, and what happens when someone leaves or changes roles. The core statement to capture: access is granted on a least-privilege basis, approved by a named authority, and revoked immediately upon departure or role change.

Keep as evidence: the signed policy document, your access approval log (even a simple spreadsheet), and records of any access removals with dates.

Acceptable Use Policy

Covers what employees can and can’t do on company systems — including whether personal use is permitted, what cloud services are approved for FCI, and the prohibition on transferring FCI to unauthorized systems or personal accounts. This is the document that establishes that your employees knew the rules.

Keep as evidence: the signed policy document and acknowledgment records showing each employee (and relevant subcontractors) reviewed and signed it.

Password Policy

Covers minimum password length, complexity requirements, prohibition on password sharing, and lockout thresholds. If you have MFA enforced, note that here too — it strengthens your posture and is worth documenting even though Level 1 doesn’t mandate it.

Keep as evidence: the signed policy document and screenshots or configuration exports from your identity provider or systems showing the policy is actually enforced technically, not just on paper.

Device Security Policy

Covers which devices are authorized to access FCI (company-managed only, or BYOD with conditions), required security configurations (screen lock, encryption, antivirus), and what employees must do before a device is used for contract work. If your boundary includes remote or home-office work, this policy is where you establish the baseline.

Keep as evidence: the signed policy document and a device inventory showing each in-scope device, its owner, and confirmation that required configurations are in place.

Basic Incident Response Policy

Covers how your company identifies, contains, and reports a security incident — including who is responsible, what qualifies as a reportable incident, and your obligation to notify the government if FCI is involved. It doesn’t need to be elaborate. It needs to answer: who do employees call, what do they do first, and who makes the call to notify the contracting officer.

Keep as evidence: the signed policy document, a contact list for the response team, and records of any incidents or tabletop exercises conducted.

Tracking your evidence

The simplest approach that actually works: a shared folder (in whatever document system is inside your FCI boundary) with one subfolder per policy. Inside each subfolder, keep the current signed policy, any prior versions, and a running log of evidence artifacts — named with dates so you can demonstrate currency.

A basic evidence log doesn’t need to be sophisticated. A spreadsheet with four columns gets you most of the way there:

Remember: there are 17 controls in the DODCIO CMMC Level 1 Self-Assessment guide. You should have a line item for each control to keep track of where all this is located and to stay compliant.

The Hidden Friction (SPRS + PIEE)

When I started my own journey of CMMC self-certification (and then NIST 800-171 self-certification), I spent a lot of time getting to know the systems. This begins with the PIEE system. I want to share some of my learnings so that maybe you can reduce some of the headaches that I experienced.

New Vendor Set Up

I am going to assume that your company has a compliant, up-to-date UEI and CAGE code set up in SAM.gov. If you do not, then you should start there and then tackle this step after.

The PIEE has a pretty good help document that can be found here. The first step is to request to set up a vendor group. Here is pretty much what that email looked like for me:

I received a username and an account a few days after this email. They were actually quite responsive (this was in August 2025, so I would be curious to know if folks are seeing issues today).

After you receive your account activation, then you must request a role. To do that go to My Account → Request Roles. You will get to a screen that has a drop down where you can request SPRS. Then you will provide justification. Your justification can be as simple as: “User requires access to SPRS to submit CMMC Level 1 self-assessment for [Company Name].”

The vendor admin will need to approve the role request. In many cases, that may be the same person.

SPRS Submission

Then you will get a tile that looks like this.

In SPRS, click on RUN CYBER REPORTS (CMMC & NIST). Then you select your vendor hierarchy and click “add new CMMC Level 1 Self Assessment”.

For Level 1:

• Assessment Type: Basic / Level 1 Self

• Score: 17 (if fully compliant)

• Assessment Date: date completed

• Scope/System Description: short description (1–2 lines)

  • Example: “Company email and endpoint devices supporting federal contract work”

Take a screenshot of this. You never know: PIEE is notoriously finicky.

Once you submit your Level 1 self-assessment in SPRS and confirm the record is saved, you’ve completed the formal requirement.

However, you’re responsible for maintaining those controls and may need to reaffirm annually depending on your contract.

CMMC Level 1 is the floor, not the finish line, but it’s the floor you have to be standing on before any of the rest of it matters. The self-assessment guide gives you the framework. What this post gives you is a starting point for the documentation and evidence that make that affirmation honest.

The SPRS affirmation is a legal commitment. Treat the work behind it accordingly.

Are you looking for a downloadable checklist to help you keep track of your progress? I have created one here that you can download.

In the next post, I will discuss the importance of the DD2345 and NIST requirements, so I hope you will subscribe to learn more!

But read closely, and something else emerges: this RFI isn’t really asking what industry can build. It is asking how they think about delivering and evolving software in a highly uncertain, multi-vendor environment.

A common response from industry may be to align to a more traditional FAR-style approach, including architecture diagrams, end-state designs, exhaustive claims of end-to-end responsibility. All in the effort to cover the entire complex landscape.

Ironically, that kind of response may be more likely to push the government away from modern software acquisition under the new rules, instead of toward it.

The Software Acquisition Pathway exists precisely for problems like this: requirements are not fully known up front, multiple commercial and government providers must integrate, and usable capability is needed early. All of this while preserving the ability to adapt to changing needs of the many users and threat landscape.

The signals are in the details. Section 4.0 explicitly states that “MOC capabilities will be developed incrementally in phases based on operational timelines.” Phase 1 and 2 aren’t about sequencing paperwork, they’re about delivering usable capability early and demonstrating scalability.

Section 5.3.2 asks vendors to assess trade-offs like cloud vs. on-prem and MOC-managed vs. provider-managed PoPs. These are framed as decisions to be made collaboratively, not requirements to be met.

And the emphasis on orchestration and observability throughout? That’s the control plane: software’s natural habitat.

RFIs like this quietly shape acquisition behavior. If industry responds with over-specified, end-state-heavy narratives, the government learns that SWP is “too risky” and retreats to familiar patterns. If industry responds with disciplined, software-led approaches emphasizing learning, decision points, and credible paths to production, they make it safer for the government to stay in the pathway.

This RFI isn’t about who can do everything. It’s about who understands what not to decide yet and how to deliver value anyway.

If your company is considering a response, the real question isn’t “Can we meet every bullet?” It’s: “What acquisition behavior are we encouraging with this response?”

I’m working through frameworks for responding to acquisition signals like these. If you’re thinking through your approach to this RFI (or others like it) I’d be glad to compare notes.

The Disappointing Reality

I found it disappointing when I began to read through the requirements. For starters, the RFI reads like an old school major acquisition rather than a call for industry feedback on the future of Air Force software delivery.

Take this example: “The vendor shall provision and support all specified hardware assets required for project operations.”

This at first sounds like harmless government acquisition language, but it reads less like software-as-a-servie and more like hardware-as-a-line-item. The document contains 195 “shall” statements, complete with rationale that hark back to my days as a systems engineering doing requirements traceability in DOORS.

Remember:

How We Got Here

“The Kessel Run” is a nod to Hans Solo and his Millennium Falcom being able to complete a smuggling route extremely close to a black hole cluster, bending the space-time continuum, making the journey in under 12 parsecs.

The metaphor was perfect: bend the rules, compress time, deliver the impossible.

The Kessel Run Software Factory associated with Hanscom AFB in Massachusetts was created to move software through the pipeline to production faster than ever before. It became the poster child for what could be a new way of delivering software in the DoD.

I spoke with Bryon Kroger earlier this year about Kessel Run when I was writing “Breaking the Sabotage Cycle” for Gene Kim’s IT Revolution Leadership Journal. He mentioned:

When Kessel Run started, it focused entirely on mission software — building above the value line, buying everything below it. That focus produced the first operational apps in under four months.

But somewhere along the way, the mission blurred. The factory started building factories, platforms, and infrastructure and not outcomes.

This summer’s Kessel Run post-mortem revealed similar themes. As Bryon calls out in his recent Defense Scoop article, these organizations slipped into “Innovation Theater.” In other words, they were performing the rituals of innovation without delivering the results. The outcomes.

Reading Between the Lines of the PRIME RFI

All organizations go through cycles of success and then change. Success begets success and then it grows, both in its funding and its demands. And with growth comes new ways of needing to do things. As someone who came from the industry side of the Defense Industrial Base, producing and transforming software, I understand how difficult it can be to manage success and maintain control over a growing organization.

But the PRIME RFI screams JCIDS, even through the Software Acquisition Pathway was supposed to kill that very approach. Just last month, Breaking Defense reported the JCIDS was being reformed, if not eliminated, yet here we are with requirements that would make a 1990s acquisition professional feel right at home.

If Kessel Run was truly following the agile processes identified in the Software Acquisition Pathway, there would be feedback on a Capability Needs Statement focused on outcomes, not infrastructure requirements.

I’m not sure what operator may be thinking, “Man, I hope someone acquires the infrastructure for the application I hope to use someday.”

That would be like going to the Apple Store with a list of requirements that include: “The vendor shall acquire the hardware necessary to create a phone capable of sending and receiving calls.” Apple doesn’t sell you infrastructure, they sell you outcomes.

Why this Matters

While “Innovation Theater” is harmful, dressing up JCIDS and calling it “Agile” is equally destructive. The Capability Needs Statement is meant to open the conversation with end users to say, “I need something that helps me do my job better, faster, more effectively.” It’s not meant to prescribe the solution.

The tragedy here isn’t just that Kessel Run has lost its way, it’s that its transformation back into traditional acquisition sends a chilling message to every other software factory and innovation hub in the DoW: Eventually, the bureaucracy wins.

The Path Forward: Three Hard Truths

1. Measure Mission Impact, Not Infrastructure

Stop counting servers, platforms, and pipelines. Start counting missions enabled, decisions accelerated, and lives saved. If you can’t trace your work directly to a warfighter or operator outcome, you’re building the wrong thing.

2. Kill the Committees, Empower the Teams

As I wrote the “Breaking the Sabotage Cycle,” we’re following the 1944 OSS sabotage manual to the letter: forming committees, demanding perfect paperwork, and advocating caution. The teams closest to the mission know what they need. Let them build it.

3. Accept that Some Things Must Die (Kill Your Pretties)

The hardest truth is that sometimes the most innovative thing an organization can do is recognize when it’s become the problem it was meant to solve. If Kessel Run can’t return to its mission-first roots, perhaps it’s time to sunset it and let something new emerge.

A Final Thought

The original Kessel Run was about taking risks, breaking rules, and achieving the impossible. Han Solo didn’t file 195 “shall” statements before making his run. He didn’t provision infrastructure (he wasn’t even that positive that the Millennium Falcon would survive). He delivered an outcome.

I’m not sure that the Air Force needs another traditional acquisition vehicle dressed in agile clothing. It needs software capabilities that helps the organization win. If the PRIME RFI represents Kessel Run’s future, then we’re not watching a software factory evolve, we’re watching it fossilize.

The question isn’t whether Kessel Run can provision infrastructure, it’s whether it can still deliver the impossible.

But here’s the thing about the defense acquisition community: We’re remarkably good at proving doubters wrong when we remember why we started. The original Kessel Run team didn’t set out to build a factory, they set out to solve problems.

Maybe it’s time to remember that.