How We Helped a Defense Contractor Prepare for CMMC Level 2: Most articles about CMMC Level 2 talk about controls, frameworks, and compliance requirements.
This isn’t one of those articles. Instead, I want to share what happened during a real CMMC readiness project and the lessons that came from it. The company had already invested in cybersecurity tools and believed they were fairly close to compliance. What they discovered was that compliance readiness and cybersecurity maturity are not always the same thing.
Some details have been modified to protect client confidentiality, but the challenges, conversations, and lessons learned are based on a real-world engagement.
The Starting Point
When we first met the client, leadership was confident they were in good shape.
They had a dedicated IT team, security software, employee training, and several documented procedures. Compared to many organizations we encounter, they were ahead of the curve.
However, our first few meetings revealed something interesting.
Everyone had a different answer when asked where Controlled Unclassified Information (CUI) was stored.
The engineering department pointed to project repositories.
Project managers referenced Microsoft Teams.
IT focused on file servers and SharePoint.
None of those answers were completely wrong.
The problem was that nobody had the complete picture.
Initial Environment Overview
| Area | What We Found |
|---|---|
| Employees | Approximately 75 |
| Remote Workers | Around 20 |
| Microsoft 365 Usage | Extensive |
| Security Awareness Training | Active |
| Multi-Factor Authentication | Partially Implemented |
| System Security Plan (SSP) | Not Documented |
| Formal Risk Assessment Process | Limited |
| Compliance Documentation | Incomplete |
At this stage, the organization wasn’t struggling with technology.
It was struggling with visibility.
The Meeting That Changed Everything
One workshop ended up changing the direction of the project.
We gathered representatives from engineering, operations, IT, and management and started mapping data flows.
The goal seemed simple:
Show us where CUI enters, moves through, and leaves the organization.
What followed was one of the most valuable discussions of the entire engagement.
As different teams described their workflows, we discovered several locations where sensitive information was being stored that leadership had never considered part of the compliance boundary.
Nobody had intentionally created the problem.
It had simply evolved over time as the business grew.
What We Learned
| Assumption | Reality |
| CUI only existed on secure servers | CUI existed across multiple business systems |
| Assessment scope was clearly defined | Scope required significant refinement |
| All departments followed identical processes | Different teams used different workflows |
| Data locations were fully understood | Several repositories had been overlooked |
That meeting taught an important lesson:
You cannot protect data effectively if you don’t fully understand where it lives.
The Technology Wasn’t the Biggest Issue
One of the biggest surprises was that the organization already had many of the security controls people normally associate with compliance.
They had:
- Endpoint protection
- Firewall management
- Security awareness training
- Patch management
- Secure remote access
From a technical perspective, they were in decent shape.
The bigger challenge involved documentation and consistency.
One department followed a process one way.
Another department followed a slightly different version.
Both approaches worked, but neither was documented well enough to satisfy assessment requirements.
At one point, a manager explained an access review process perfectly.
When asked where it was documented, he smiled and said:
“Honestly, we’ve just been doing it that way for years.”
That answer became a recurring theme throughout the project.
The MFA Challenge Nobody Expected
Leadership believed multi-factor authentication was already fully implemented.
For most users, that was true.
Then we discovered a legacy engineering application that didn’t integrate easily with modern authentication controls.
The engineering team was understandably concerned.
Their priority wasn’t compliance.
Their priority was keeping projects moving.
Rather than forcing a change immediately, the IT team worked closely with engineers to test different solutions.
The process took longer than expected, but it produced a solution that improved security without disrupting operations.
MFA Project Snapshot
| Before | After |
| MFA used for most users | MFA enforced consistently |
| Legacy application exceptions | Exceptions addressed |
| Inconsistent authentication workflows | Standardized approach |
| Limited documentation | Fully documented process |
The technical work was important, but the collaboration between departments was what ultimately made the project successful.
Building the System Security Plan
Many companies view the SSP as another compliance document.
This organization eventually saw it differently.
The SSP forced important conversations that had never happened before.
Questions such as:
- Who owns each system?
- How are access decisions made?
- What controls protect sensitive information?
- How are incidents reported?
- What evidence supports each process?
The answers weren’t always immediate.
But that’s exactly why the exercise was valuable.
One executive later told us:
“For the first time, I feel like we’re looking at the entire environment instead of just individual pieces of it.”
That insight alone made the effort worthwhile.
The Biggest Surprise: Evidence Collection
At the beginning of the project, everyone expected technical remediation to consume most of the time.
Instead, evidence collection became the largest effort.
The company was already performing many security activities correctly.
The challenge was demonstrating them.
We spent weeks organizing records, gathering reports, reviewing configurations, and documenting procedures.
Common Evidence Requested During Readiness Reviews
| Evidence Type | Examples |
| Access Reviews | User permissions and approvals |
| Security Training | Completion records |
| Risk Assessments | Risk registers and findings |
| System Configurations | Screenshots and settings |
| Incident Response | Procedures and testing records |
| Audit Logs | Monitoring and review evidence |
| Asset Inventory | Hardware and software tracking |
One executive jokingly described the process as:
“Trying to prove years of good security habits with paperwork.”
While humorous, it captured the challenge perfectly.
A Change We Didn’t Expect
One of the most positive outcomes wasn’t technical at all.
Employees became more engaged.
Managers started participating more actively in security discussions.
Employees reported suspicious emails more frequently.
Teams became more aware of how sensitive information moved through the organization.
Gradually, cybersecurity stopped being viewed as an IT responsibility.
It became a business responsibility.
That cultural shift may ultimately provide more long-term value than any individual compliance requirement.
Readiness Review Results
Before discussing a formal assessment, we completed a readiness review.
The goal wasn’t perfection.
The goal was identifying issues while there was still time to fix them.
Readiness Review Outcomes
| Area Reviewed | Outcome |
| Policies | Minor updates required |
| Evidence Collection | Additional documentation needed |
| Technical Controls | Largely effective |
| Employee Awareness | Strong participation |
| Access Management | Improved consistency |
| Compliance Readiness | Significantly improved |
Finding small issues during a readiness review is far preferable to discovering them during an official assessment.
Lessons for Other Defense Contractors
After completing the project, several lessons stood out.
1. Don’t Assume Everyone Understands Where CUI Lives
Verify it.
The answer is often more complicated than expected.
2. Security Tools Don’t Equal Compliance
Technology matters, but assessors also want documentation, evidence, and repeatable processes.
3. Documentation Should Reflect Reality
Generic templates rarely help.
Policies should match how your organization actually operates.
4. Employees Matter More Than Most Organizations Realize
Security culture influences every aspect of compliance.
5. Start Earlier Than You Think
Documentation and evidence collection almost always take longer than anticipated.
Final Thoughts
The most valuable outcome of this project wasn’t a new security tool or a completed document. It was clarity. The organization finished the engagement with a far better understanding of its systems, data, responsibilities, and risks. That visibility strengthened both compliance readiness and cybersecurity maturity. For defense contractors preparing for CMMC Level 2, that’s often where real progress begins—not with technology, but with understanding your environment and documenting it properly.
FAQ’s on How We Helped a Defense Contractor Prepare for CMMC Level 2
What is the biggest challenge in CMMC Level 2 preparation?
For many organizations, documentation and evidence collection require more effort than technical remediation.
Why is data-flow mapping important?
It helps identify where Controlled Unclassified Information exists and ensures the compliance boundary is properly defined.
Is multi-factor authentication enough for compliance?
No. MFA is important, but organizations must also demonstrate policies, procedures, monitoring, and supporting evidence.
How long does readiness preparation usually take?
Preparation timelines vary, but most organizations should expect several months of planning, remediation, documentation, and review before pursuing an assessment.
Sources
- CMMC Program: https://www.acq.osd.mil/cmmc/
- Department of Defense CMMC Resources: https://dodcio.defense.gov/CMMC/
- NIST SP 800-171 Rev. 2: https://csrc.nist.gov/pubs/sp/800/171/r2/final
- NIST SP 800-171A: https://csrc.nist.gov/pubs/sp/800/171/a/final
- NIST Computer Security Resource Center: https://csrc.nist.gov/
- Controlled Unclassified Information (CUI) Program: https://www.archives.gov/cui
Disclaimer: This article is based on a real-world CMMC readiness engagement. Some details have been modified to protect client confidentiality. It is provided for educational purposes only and should not be considered legal, regulatory, or cybersecurity advice.
About The Author
