CMMC Readiness: What You Need Before Starting an Assessment

Most CMMC assessments fail during preparation, not during the actual assessment. Organizations schedule a C3PAO engagement before they understand what needs to be in place, what documentation assessors expect to see, and which controls will actually be tested. Then they scramble, delay, and pay for remediation that should have happened months earlier.

I've watched this pattern repeat across defense contractors of every size. The companies that pass on the first attempt share a common trait: they treated CMMC readiness as a systematic preparation process, not a compliance project that starts when the assessor arrives. They knew what had to be documented, tested, and operational before anyone from a third-party assessment organization walked through the door.

This isn't theoretical. CMMC Level 2 requires evidence of implementation for 110 security controls from NIST 800-171, plus maturity process requirements. Assessors will ask for specific artifacts, test specific systems, and interview specific personnel. If you can't produce what they need within minutes, you're not ready.

System Security Plan: Your Assessment Foundation

The System Security Plan is not just another document. It's the authoritative reference that defines your assessment scope, documents your security boundaries, and maps every control to your implementation. Assessors start here, and they return to it constantly throughout the engagement.

Your SSP must describe the entire environment that processes, stores, or transmits Controlled Unclassified Information. This includes network diagrams showing security boundaries, hardware and software inventories, data flow diagrams, and the security controls you've implemented. Most organizations underestimate how detailed this needs to be.

The pattern I see most often: companies create an SSP to check a box, not to document reality. They copy templates, fill in generic descriptions, and assume that's sufficient. Then during the assessment, the assessor asks about a specific control implementation described in the SSP, and the team can't point to where it actually exists. That's not a documentation problem. That's evidence the control isn't implemented.

Your SSP should be specific enough that a new CISO could read it and understand exactly how your environment is secured. If it wouldn't serve that purpose, it won't serve an assessor either. Include system names, specific configurations, responsible personnel by role, and references to your policies and procedures. Generic descriptions of "firewalls protect the network" won't pass. Which firewalls? What rules? Who manages them? How are changes controlled?

Scope Definition Drives Everything

Before you document anything else, nail down your CUI environment scope. This determines which systems get assessed, which controls apply, and how much effort you'll need to invest. Organizations that try to include everything in scope inevitably make CMMC readiness harder and more expensive than necessary.

I worked with a defense contractor that initially scoped their entire corporate network for CMMC. Hundreds of workstations, dozens of applications, multiple office locations. The remediation cost estimate was crushing. We rebuilt the scope around a dedicated CUI enclave with controlled access, specific systems, and clear data flows. Same compliance outcome, one-third the cost, and far easier to assess.

Your scope definition belongs in your SSP. Document the boundaries explicitly: which networks, which systems, which facilities, which personnel. Then document what's explicitly out of scope and why. Assessors need to understand both.

Policies and Procedures That Actually Map to Controls

Every CMMC Level 2 control requires documented policies and procedures. Not because documentation is the point, but because assessors need evidence that you've defined how the control works in your environment. They'll read your procedure, then verify you're actually following it.

This creates a specific trap. Organizations write procedures that describe an idealized security program, not their actual implementation. Then during the assessment, the assessor observes reality and finds it doesn't match the documentation. That's a finding, even if reality is acceptable. The mismatch itself is the problem.

Write procedures that describe what you actually do. If your access review happens quarterly instead of monthly, document quarterly and explain the risk-based decision. If certain systems use exception processes, document those exceptions with business justifications. Accuracy matters more than perfection.

Each procedure should map clearly to specific NIST 800-171 controls. When an assessor asks about control 3.1.1 (authorized access control), they need to find your procedure for provisioning, reviewing, and revoking access. That procedure should reference the tools you use, the personnel responsible, the frequency of reviews, and where you maintain records. If you're using POA&Ms for any controls, those need to be documented with timelines and progress tracking.

The Policy Framework That Works

Most organizations adopt one of two approaches: a single massive security policy document that covers everything, or dozens of individual procedures that don't connect to an overarching framework. Neither approach serves CMMC readiness well.

The structure that actually works for assessments: a concise master security policy that establishes your security program and authority, supported by specific procedures for each control family. Access control procedures, incident response procedures, configuration management procedures, media protection procedures. Each stands alone but references the master policy.

This structure lets assessors navigate quickly to the controls they're testing without wading through unrelated material. It also makes maintenance realistic. When you update your access review process, you modify one procedure, not a 200-page master document.

Evidence Collection Systems Must Already Exist

CMMC assessments require evidence. Logs showing access control enforcement. Scan reports demonstrating vulnerability management. Training records proving security awareness. Change management tickets documenting configuration control. Incident response records showing you actually execute your procedures.

This evidence must exist before the assessment starts. You can't generate it retroactively. If you haven't been collecting logs, conducting scans, tracking training, and documenting incidents, you don't have implementation evidence. You have a gap that will fail the assessment.

The organizations that pass CMMC readiness checks have spent months building evidence collection into their operations. They know where every required artifact lives, who maintains it, and how to produce it on demand. They've tested their own ability to respond to assessor requests.

Create an evidence matrix. List every NIST 800-171 control that requires documentary evidence, identify the specific evidence you'll provide, document where it's stored, and note the responsible personnel. Then actually collect that evidence for at least three months before your assessment. If you're aiming for CMMC Level 2, you need to demonstrate mature, consistent implementation over time, not spot compliance.

Automated Collection Beats Manual Tracking

Manual evidence collection fails under operational pressure. Someone forgets to download the monthly vulnerability scan. Training records sit in someone's email instead of a centralized system. Access reviews happen but nobody documents them consistently.

Invest in systems that collect evidence automatically. Your SIEM should retain logs according to your retention policy without manual intervention. Your vulnerability scanner should generate reports on schedule. Your training platform should maintain completion records. Your ticketing system should capture all change management activities. When evidence collection is automated, it actually happens.

Test Your Controls Before Someone Else Does

The assessor will test your controls. They'll attempt to access systems without authorization. They'll examine configurations to verify hardening. They'll review user account lists for orphaned access. They'll trace data flows to confirm encryption. If you haven't tested these same controls yourself, you're gambling on the outcome.

Internal testing serves two purposes. First, it identifies gaps you can remediate before the assessment. Second, it validates that your documented controls actually work as described. Both matter equally.

Run your own access control tests. Can you provision a new user account following your documented procedure? Does the account have appropriate permissions and nothing more? Can you revoke access and verify system access actually stops? If your procedure says access reviews happen quarterly, pull the last four reviews and confirm they're complete and documented.

Test your incident response plan with a tabletop exercise. Don't wait for the assessor to ask "what would you do if..." and discover your team doesn't know. Run the scenario. Document the exercise. Identify gaps. Remediate them. Keep the records as evidence of your incident response capability.

Test your configuration management process. Submit a change request, track it through approval, implement it in a test environment, document the results, and verify the change control board reviewed it appropriately. If this process doesn't work smoothly when you're testing it, it won't suddenly work during an assessment.

Vulnerability Management Testing Catches Most Gaps

In my experience, vulnerability management produces more findings than almost any other control family. Not because organizations don't scan, but because they scan inconsistently, remediate slowly, or can't produce evidence of either.

Test your vulnerability management process end-to-end. Run authenticated scans across all in-scope systems. Generate reports that categorize findings by severity. Track remediation in your ticketing system with assigned owners and due dates. Document risk acceptance for vulnerabilities you can't or won't remediate immediately. Maintain evidence of this complete cycle for at least three months.

Assessors will ask for your most recent scan, your remediation metrics, and your policy-defined timelines for addressing critical and high vulnerabilities. If you can't produce these within minutes, you're not ready for CMMC assessment.

Personnel Roles and Training Must Be Documented

CMMC requires defined security roles and trained personnel. Assessors will ask who's responsible for specific security functions. They'll verify those people understand their responsibilities. They'll review training records to confirm security awareness.

Document your security organizational structure. Who's your senior security official? Who manages access control? Who responds to incidents? Who conducts security reviews? These can't be generic role titles. They need to be specific positions with specific responsibilities documented in position descriptions or responsibility matrices.

Then verify those people are actually trained for their roles. Your incident response lead should have incident response training, not just general security awareness. Your system administrators should understand secure configuration. Your security awareness training should be role-based, not one-size-fits-all.

Maintain training records that show what was covered, when it was delivered, and who completed it. Annual security awareness training is baseline. Role-based training should happen when someone assumes a security responsibility and be refreshed based on your policy. If your policy says annual refresher training, you need evidence of that cadence.

Contractor and Third-Party Personnel Matter Too

Organizations often forget that contractors, consultants, and third-party personnel with access to CUI need the same training and clearance as employees. If you're using managed service providers who access your environment, they need training on your security policies and handling requirements for CUI.

Document these third-party relationships. Who has access? What access do they have? How are they trained? How are they monitored? Your SSP should identify all external parties with CUI access, and your evidence should demonstrate they're held to the same standards as internal personnel.

The Gaps That Consistently Fail Assessments

After working with dozens of organizations preparing for CMMC, certain gaps appear repeatedly. These aren't obscure controls or edge cases. They're fundamental requirements that organizations either misunderstand or underestimate.

Incomplete asset inventory. You can't secure what you don't know exists. Assessors will ask for your hardware and software inventory. They'll verify it's complete and current. Organizations that discover unauthorized systems or forgotten software during the assessment fail this control immediately. Your inventory must include every device that connects to your CUI environment and every application that processes or stores CUI.

Missing multifactor authentication. NIST 800-171 requires MFA for remote access and privileged access. Organizations implement MFA for VPN but forget about privileged administrative access to servers, databases, or network equipment. Every privileged account needs MFA, not just the obvious ones. Test this by listing every account with administrative rights and verifying each one requires multiple authentication factors.

Inadequate log retention. Your logs need to cover at least the assessment period. If you're retaining logs for only 30 days, you can't demonstrate three months of access control enforcement or incident detection capability. Set retention policies that support assessment evidence requirements, not just operational convenience. For most organizations, 90 days minimum makes sense for CMMC readiness.

Unencrypted CUI at rest. NIST 800-171 requires encryption of CUI on both endpoints and servers. Organizations encrypt laptops but forget about file servers, databases, or backup systems. Every location where CUI persists needs encryption. This includes backups, archives, and disaster recovery copies.

No evidence of continuous monitoring. Assessors want to see that your security controls operate continuously, not just when you're paying attention. Security information and event management systems should show consistent log collection and alert generation. Vulnerability scans should run on schedule. Access reviews should happen at defined intervals. Gaps in your evidence timeline raise questions about implementation maturity.

Configuration Management Requires More Than You Think

Configuration management consistently surprises organizations preparing for CMMC. The requirement isn't just baseline configurations or change control processes in isolation. It's establishing baselines, enforcing them, controlling changes, monitoring for drift, and maintaining evidence of all of it.

Your baseline configurations should be documented for every system type in your environment. Servers, workstations, network devices, security appliances. These baselines should implement security hardening based on recognized standards like CIS Benchmarks or DISA STIGs. Document why you chose specific settings and what security purpose they serve.

Then demonstrate you actually deploy systems according to these baselines. Build automation that applies configurations consistently, or document manual procedures that achieve the same outcome. Assessors may ask you to show them a recently deployed system and trace its configuration back to your documented baseline.

Change control processes need to cover configuration changes, not just application deployments. If someone modifies firewall rules, that goes through change management. If someone installs new software, that's a controlled change. If someone updates system configurations, there's a ticket, an approval, and documentation of what changed and why.

Monitor for configuration drift. Systems change over time through updates, troubleshooting, and accumulated modifications. Your configuration management process should include periodic reviews that compare current configurations to approved baselines and identify unauthorized changes. This needs to be documented and regular, not ad hoc.

Prepare for the Assessment Interview Process

CMMC assessments include interviews with personnel who implement and manage security controls. These aren't checkbox conversations. Assessors ask detailed questions to verify people understand their responsibilities and actually perform them.

Prepare your team by walking through likely questions. If someone manages access control, they should be able to explain how they provision accounts, what approval process they follow, how they conduct access reviews, and where they document everything. If someone handles incident response, they should know the escalation procedures, evidence preservation requirements, and reporting timelines.

Don't script answers. Assessors recognize coached responses immediately, and it undermines credibility. Instead, ensure people understand their actual responsibilities and can speak naturally about what they do. If your procedures accurately document reality, this shouldn't be difficult.

Role-play the interview process during your internal readiness testing. Have someone outside the security team ask the questions. This reveals gaps in understanding and identifies procedures that aren't as clear as you thought. It also reduces anxiety during the actual assessment.

Document Who Gets Interviewed

Your SSP or supporting documentation should identify key personnel by role for each control family. Access control administrator, incident response lead, configuration management lead, security awareness training coordinator, vulnerability management lead. When the assessor asks to speak with someone about a specific control, you should know immediately who that is and have them available.

For smaller organizations where one person wears multiple hats, that's fine. Document it accurately. The assessor needs to understand your organizational structure as it actually exists, not as you wish it existed.

The Readiness Assessment You Should Run Yourself

Before you schedule a C3PAO, conduct your own readiness assessment. Not a vendor's automated scan that checks basic configurations. A structured review that mirrors the actual CMMC assessment process.

Assign someone to play assessor who wasn't directly involved in implementing your controls. Give them your SSP, your policies and procedures, and your evidence matrix. Have them review documentation, request evidence, interview personnel, and test controls. Document every gap they find.

This internal assessment should happen at least 90 days before your scheduled C3PAO engagement. That gives you time to remediate findings, collect additional evidence, and run focused re-testing on controls that weren't ready. Organizations that skip this step consistently face surprises during the actual assessment.

The gaps your internal assessment finds are gifts. They're findings you can fix before they appear on an official assessment report. They're evidence your preparation process is working. Track them in your remediation plan with owners, due dates, and validation criteria.

When your internal assessment produces minimal findings and your team can respond confidently to evidence requests, you're approaching CMMC readiness. When people are still scrambling to locate documentation or can't explain their control implementations, you need more preparation time.

Strategic Implications for Leadership

CMMC readiness isn't a compliance exercise. It's an operational maturity threshold that determines whether you can sustain DoD contract work. Organizations that treat it as a one-time certification effort fail to maintain compliance between assessments and face difficult conversations when recertification comes around.

The investment in preparation pays dividends beyond passing the assessment. The documented processes, evidence collection systems, and trained personnel you build for CMMC create security capabilities that support business operations. They reduce incident impact, improve operational efficiency, and demonstrate maturity to primes evaluating subcontractor risk.

Leadership should understand that CMMC preparation timelines depend on current maturity, not desired outcomes. An organization with minimal cybersecurity infrastructure needs 12-18 months to reach CMMC Level 2 readiness. An organization with existing security programs might need 6-9 months to close gaps and build evidence. Compressed timelines produce failed assessments and wasted resources.

Budget for readiness work as a distinct phase before the assessment. Gap remediation, tool implementation, procedure development, evidence collection, and internal testing all require time and resources. The C3PAO fee is a small fraction of total CMMC preparation costs. Organizations that budget only for the assessment discover too late they can't afford to get ready for it.

Your CMMC certification becomes a competitive differentiator once you achieve it, but only if you can maintain it. The same readiness checklist you use for initial assessment applies to ongoing compliance monitoring. The preparation work never really ends. It becomes your operational baseline for handling CUI appropriately and maintaining the security posture DoD expects from its contractor base.