Most teams preparing for CMMC think the challenge is technical. Dr. Jeff Baldwin, who trains the assessors conducting those evaluations, explains the systems engineering mindset that separates real readiness from paper compliance.
Most defense contractors don't realize that the people evaluating your CMMC assessments aren't just checking boxes. They're applying systems engineering principles to determine whether your entire environment, component by component, actually does what you say it does.
Dr. Jeff Baldwin is the CEO of Space Coast Cyber, a CMMC Approved Training Provider that has trained hundreds of students through the CCP and CCA certification process. But Jeff isn't just a trainer. Over 20 years in cybersecurity, he's worked as a government assessor, a systems security engineer at L3 Harris, a CISO for a managed VDI provider serving the defense contracting base, and a consultant who helped some of the very first organizations achieve CMMC certification.
That combination of perspectives gives Jeff an unusually complete view of what actually happens during an assessment and where most organizations fall short before they even get there.
Jeff's role in the CMMC ecosystem is distinct. As the person training the assessors who will evaluate your organization, he shapes how readiness gets measured across the entire framework.
"When I go into my instruction, I hit it from every direction. I have been a consultant, I've been an OSC, I've been the CISO that got a CMMC certified organization through that process. And I train all the assessors." — Jeff Baldwin
When Jeff teaches, he can show assessors how to evaluate from multiple angles. And when he consults, he can tell organizations exactly how an assessor will think about their evidence.
"I can say with my consultant hat, here's how I would approach that scenario. With my assessment hat, here's how I would approach that scenario." — Jeff Baldwin
His company, Space Coast Cyber, pioneered evening training courses to make certification accessible for working professionals. Jeff is also currently building out Space Coast Cyber's C3PAO capability, which means he'll soon be conducting assessments directly in addition to training the people who do
.
The most common failure pattern Jeff sees isn't a lack of security controls. It's a gap between what organizations provide as evidence and what assessors actually need to see.
Most organizations treat their environment as one big thing and provide a single set of evidence to cover all 110 NIST 800-171 requirements. But that's not how assessors are trained to think.
"There's no one component that will implement all 110 requirements. The 110 requirements are levied upon the information system." — Jeff Baldwin
Jeff teaches assessors to decompose systems into individual components: firewalls, virtual machines, laptops, phones, servers, SaaS applications, and even people. Then, for each component, they determine which of the 110 requirements actually apply.
"A firewall does not get personal screening. People do not have FIPS mode. You can't turn FIPS mode on a person." — Jeff Baldwin
Once an assessor maps requirements to components, they need evidence from each one. This is the concept Jeff calls "sufficiency of evidence," and it's where most organizations create gaps without realizing it.
"If I can articulate that my very first requirement applies to these five different components, and here's how each of those five have implemented it, then I'd want to see the evidence from those five different components. If you only provide me evidence of one of those components, then that would be insufficient evidence." — Jeff Baldwin
The other major misconception? Treating the System Security Plan as a plan.
"Start viewing the SSP as not being a plan. I know it says 'plan' in the name, so a lot of people will try to put future state things in there, but I cannot prove you have done something in the future. We have to get into viewing the SSP as a collection of claims that you're making, and the assessor is just validating the accuracy of those statements." — Jeff Baldwin
Jeff's approach draws on systems engineering principles he's applied across two decades of government and commercial cybersecurity work. Here's the framework he teaches both assessors and the organizations preparing for assessment.
Before you can prove compliance, you need to know what your system actually consists of. Jeff starts every engagement by breaking the information system down into its individual elements.
"You're going to need to decompose that system into all of its elements. I figure out what all of the things that make up my system are." — Jeff Baldwin
This means cataloging every firewall, virtual machine, physical laptop, phone, server, and SaaS application in scope. It also means recognizing that people are system components too, with their own set of applicable requirements.
Not every requirement applies to every component. Once you've decomposed the system, Jeff's next step is determining which of the 110 requirements are relevant to each element.
"Now we have created a system design and architecture that maps and traces back to each of the requirements as they apply to each component." — Jeff Baldwin
This mapping creates the foundation for everything that follows: your evidence collection, your SSP structure, and ultimately what the assessor will evaluate.
This is the step that transforms CMMC from an abstract compliance exercise into something your team can actually execute. Jeff describes a straightforward translation process he uses as a consultant.
"I'll take the NIST language, which is not really written in English. I'll translate it into usable English for them and say, 'Hey, how are you doing X?' And they say, 'Oh, we do X by doing A, B, C.' And I say, 'Great, can you demonstrate that?' And they say, 'I would go open up this dashboard, I'd pull this report, I'd pull these tickets.' And I say, 'Great. Write that down. You just created a repeatable assessment procedure.'" — Jeff Baldwin
The result is a written, repeatable procedure your team can use for annual self-assessments, preparation for third-party assessments, or anytime an assessor asks how you meet a specific requirement.
"CMMC is not an IT problem. CMMC is a company problem. You're probably doing a lot of the stuff already, but it's probably not documented very well. So a lot of that's getting in, claiming credit, and then translating it into a way that an assessor will consume it." — Jeff Baldwin
Once your system is designed and implemented, Jeff applies two systems engineering concepts that sit at the heart of every assessment.
Verification answers the question: did I build it right?
"Say what you do and then do what you say. Did you actually build it to your design specification? And if you did, you pass verification." — Jeff Baldwin
Validation answers a different question: did I build the right thing?
"I could pass verification and fail validation. Under the hood, that's what assessors are really doing. We're looking at what you're saying in your SSP. Then we're looking for evidence that you're actually following the things that you say you do. And then we're looking at whether you're actually achieving those outcomes. And that is the simplification down of what an actual assessment is." — Jeff Baldwin
Jeff emphasizes that one of the most effective ways to simplify your path to certification is to shrink what's in scope. If your system doesn't need printing, eliminate it. If you don't need removable media, remove it.
"If the system doesn't need to achieve something, then you can engineer around that and make it as restrictive as possible. And by doing so, you reduce your attack surface." — Jeff Baldwin
For organizations that rarely handle CUI directly, this can mean standing up a minimal enclave that meets the contractual requirement while keeping the rest of your environment out of scope.
"Maybe you stand up an Azure Virtual Desktop and there's one desktop. And if anybody ever needed to work with CUI, you go to that one desktop. But you have a certified system that meets that contractual requirement, but all your actual work is being done on government provided equipment." — Jeff Baldwin
💡Thinking through scope, evidence, and assessment readiness doesn't have to be a solo effort.
BEMO coordinates the full CMMC compliance process, from mapping your system components to getting you through assessment day, so your team can focus on the work that keeps contracts moving.
The stakes in CMMC are higher than most compliance frameworks. Jeff doesn't sugarcoat this.
"A good assessor is looking for reasons to pass you. We're not necessarily looking for reasons to fail you. If I wanted to fail somebody, I could fail anyone, even Raytheon, Lockheed Martin, any of them. Is that even reasonable? It doesn't make sense." — Jeff Baldwin
There's empathy built into how Jeff trains assessors to approach evaluations, and for good reason.
"The table stakes here are you are going to destroy people's livelihoods. You can't win this contract because you didn't have a screensaver?" — Jeff Baldwin
Jeff also points out a structural advantage in the CMMC framework worth knowing: assessors can't sell you consulting after the assessment. A C3PAO engages with you for either consulting or assessment, but not both. That means assessors don't have a financial incentive to find problems, unlike some other compliance frameworks where assessors get paid per finding and then sell remediation services.
When you approach your assessment with the systems engineering mindset Jeff teaches, the outcomes improve across the board. Your evidence is organized at the component level, so assessors can evaluate it efficiently. Your SSP contains provable claims, not aspirational statements. And your team has repeatable procedures ready to demonstrate on the spot.
For early adopters, there's one more practical benefit.
"When your primes and everybody else give you a supplier questionnaire about your CMMC status, you can be like, 'Here's my certificate. Leave me alone. I proved my compliance. I shouldn't have to do anything else.'" — Jeff Baldwin
💡BEMO is the managed compliance provider built for this.
From gap assessment to implementation to audit day, BEMO coordinates the entire process so you can stop worrying about evidence gaps and start earning the contracts that depend on certification.
Verification checks whether your system was built to the design specification you documented. It's the "say what you do, do what you say" test. Validation checks whether your system actually achieves the security outcomes the requirements are looking for. As Jeff explains, you can pass verification and still fail validation if your implementation matches spec but doesn't deliver the intended result.
No. The 110 requirements are levied on the information system as a whole, but they apply differently to each component. A firewall has different applicable requirements than a person or a SaaS application. Jeff's approach is to decompose your system into components and map which requirements apply to each one, which also determines the scope of evidence assessors will expect.
Sufficiency of evidence means providing proof of compliance across every component where a requirement applies, not just one. If a requirement applies to five different components and you only show evidence from one, your evidence is insufficient. This is one of the most common gaps Jeff sees, and it's entirely avoidable with proper system decomposition and mapping up front.
No. Jeff is clear that your SSP should be a collection of provable, present-tense claims, not a future-state plan. Assessors can only validate what you've already implemented. If your SSP includes things you plan to do but haven't done yet, those statements can't be verified or validated during an assessment.