What CMMC 2.0 Requires Before Your First Assessment

CMMC 2.0 certification is a prerequisite for maintaining defense contracts, yet many organizations approach the assessment date without clarity on what must be in place, who decides the organization is ready, or how to measure progress toward compliance. The result is predictable: delayed certifications, stalled contracts, and executive accountability for an outcome with no clear owner.

This article explains what CMMC 2.0 requires before your first assessment, who inside your organization must own readiness, and how executive leadership closes the gap between technical implementation and business accountability.

1The Business Problem: Accountability Without Ownership

Defense contractors are legally required to protect Controlled Unclassified Information (CUI) and demonstrate that protection through third-party assessment. Certification is not an IT project. It is a binding representation to the Department of Defense that your organization has implemented specific security practices, documented them accurately, and can sustain them under examination.

The chief executive is accountable for that representation. In most mid-sized contractors, however, no single person owns the strategic questions that determine readiness: Are the documented controls accurate? Do they reflect what actually happens? Who decides when the organization is ready for assessment? What are the consequences of a failed audit?

IT teams implement technical controls. Compliance staff manage documentation. Neither role answers the executive question: Is the organization ready to certify? That gap delays certification and exposes leadership to regulatory and contractual risk.

2What CMMC 2.0 Requires Before Assessment

CMMC 2.0 builds on NIST SP 800-171, which establishes 110 security requirements organized into 14 families. Before assessment, your organization must have completed four distinct categories of work, each requiring different expertise and each commonly underestimated in initial planning.

Technical Implementation of Controls

NIST SP 800-171 specifies controls across access management, configuration, audit logging, incident response, media protection, physical security, personnel screening, and system integrity. These controls map to the 14 families documented in NIST SP 800-53 Revision 5, which provides the detailed implementation guidance underlying CMMC assessments.

Implementation is not a checklist exercise. Each control must be configured to the specific architecture, workflows, and risk profile of your environment. A firewall rule that satisfies the requirement in one network design may be inadequate in another. An access control policy written generically will fail under examination if it does not reflect actual practice.

Technical implementation requires understanding not just what the control requires, but how it interacts with existing systems, business processes, and operational constraints. Access control requirements, for example, must account for how users authenticate across multiple systems, how privileged access is granted and revoked, and how the organization monitors for unauthorized access attempts. Logging requirements must specify what events are captured, how long logs are retained, where they are stored, and who reviews them for anomalies.

Configuration management controls require maintaining accurate inventories of hardware and software assets, documenting baseline configurations, controlling changes through formal processes, and verifying that systems remain in their approved state. Incident response controls require documented procedures for detecting, analyzing, containing, and recovering from security events, along with evidence that those procedures have been tested and that staff are trained to execute them.

Each of these domains requires decisions about what tools to deploy, how to configure them, and how to integrate them into daily operations in a way that can be sustained over time and verified under assessment.

Documentation That Reflects Actual Practice

Assessors test whether documented controls match observed reality. A system security plan that describes daily log reviews is falsified by evidence that logs are reviewed weekly. A password policy requiring complexity is contradicted by user accounts that bypass the rule. The assessment tests integrity, not aspiration.

Documentation must describe what your organization actually does, using language precise enough that an assessor can verify it through interview, observation, and technical testing. Vague statements, unsupported claims, and generic policy language are common causes of assessment failure.

A complete documentation package for CMMC includes a System Security Plan that describes the boundary of the assessment, the systems that process CUI, the controls implemented to protect those systems, and the assessment methodology. It includes policies and procedures for each of the 14 control families, written to describe specific responsibilities, timelines, and escalation paths rather than generic best practices.

Documentation also includes evidence artifacts: configuration exports that prove settings match policy, training records that demonstrate personnel understand their responsibilities, incident logs that show the response process has been exercised, and audit reports that confirm controls are operating as described. These artifacts must be current, meaning they reflect the state of the environment at the time of assessment, not six months prior.

Where documentation describes a control as implemented, the organization must be prepared to demonstrate it on demand. Where documentation acknowledges a gap, it must be accompanied by a Plan of Action and Milestones that explains the deficiency, its risk, and the timeline for remediation. Inconsistency between documentation and observed practice is treated as evidence of inadequate governance, not merely a documentation error.

Governance and Risk Decisions

Not every requirement applies in every context, and some controls can be implemented through alternative measures if documented and justified. Those decisions require risk judgment, regulatory interpretation, and executive approval. They cannot be delegated to implementation teams without introducing liability.

Where a control is not fully implemented, CMMC requires a documented Plan of Action and Milestones (POA&M) specifying the gap, the risk it presents, the mitigation in place, and the timeline for closure. These are governance artifacts, not technical ones, and they establish accountability at the executive level.

Governance decisions include determining the scope of the assessment, meaning which systems and networks will be included in the boundary that protects CUI. This decision has both technical and business dimensions: a narrow scope reduces compliance cost but may limit operational flexibility, while a broad scope increases the burden of maintaining controls but simplifies data handling.

Risk decisions also include evaluating whether compensating controls satisfy a requirement when the specified control cannot be implemented. For example, if a legacy system cannot enforce multi-factor authentication due to technical limitations, the organization might implement network segmentation and additional monitoring as compensating measures. That decision requires documenting why the primary control is infeasible, what risk remains, and why the alternative approach provides equivalent protection. It requires executive approval because it directly affects the organization's security posture and regulatory position.

Governance also includes establishing the process by which the organization decides it is ready for assessment. This requires defining what level of control implementation is sufficient, what gaps are acceptable under a POA&M, and what evidence must be in hand before scheduling the assessment. Without that process, readiness becomes a matter of opinion rather than documented judgment.

Evidence Collection and Readiness Testing

Before the formal assessment, your organization should conduct an internal review that simulates assessor examination. This identifies documentation gaps, control deficiencies, and conflicting evidence while there is still time to remediate. Organizations that schedule assessment without internal readiness testing routinely encounter surprises that delay certification by months.

Evidence must be current, complete, and accessible. Assessors will request logs, configuration exports, policy acknowledgments, training records, and incident reports. Missing evidence is treated as a control failure regardless of actual implementation.

Readiness testing means conducting interviews with staff to confirm they understand their security responsibilities, reviewing technical configurations to verify they match documented baselines, and examining logs to ensure monitoring processes are functioning as described. It means testing incident response procedures to confirm the organization can execute them under pressure, not just document them in a plan.

Evidence collection requires knowing what assessors will ask for and having it organized for rapid retrieval. This includes audit logs covering the required retention period, change management records showing that configurations are controlled through a formal process, and training records demonstrating that security awareness activities occurred as scheduled. It includes vendor contracts that specify security responsibilities for third-party service providers, and evidence that those responsibilities are being met.

Readiness testing also identifies inconsistencies that would undermine an assessment. If the password policy requires 14-character passwords but the domain controller enforces 12, that gap must be closed before assessment. If the security plan states that access reviews occur quarterly but the most recent review is eight months old, that deficiency must be remediated and documented. Assessors will test these details, and failures that could have been identified through internal review introduce costly delays.

3Who Owns CMMC Readiness

CMMC readiness cannot be owned by IT alone, because IT does not make risk decisions, set policy, or attest to regulatory compliance. It cannot be owned by compliance alone, because compliance staff do not design security architectures or implement technical controls. It cannot be owned by external consultants, because certification is a binding executive representation that cannot be delegated.

The role that owns readiness is the one that answers to the chief executive for security strategy, regulatory position, and risk decisions. In large organizations, this is the Chief Information Security Officer. In mid-sized defense contractors, it is typically a <a href="/vciso/">vCISO leadership</a> engagement structured to provide executive-level ownership without the overhead of a full-time hire.

Adequate ownership of CMMC readiness includes the following responsibilities, each of which requires security expertise and executive authority.

• Interpreting NIST SP 800-171 requirements in the context of your specific architecture and business model
• Making documented risk decisions about control implementation, alternative measures, and acceptable gaps
• Ensuring that policies, procedures, and technical configurations reflect a coherent security strategy rather than disconnected compliance artifacts
• Coordinating across IT, HR, legal, and operations to implement controls that require cross-functional support
• Conducting readiness reviews that test whether the organization can withstand assessor scrutiny
• Reporting to executive leadership on certification status, timeline risks, and remediation priorities
• Serving as the single point of accountability for whether the organization is ready to schedule assessment

Without this level of ownership, CMMC preparation becomes a series of uncoordinated tasks with no one authorized to declare readiness or accountable for the outcome.

4How This Relates to Regulatory and Framework Readiness

CMMC is one application of a broader discipline: translating regulatory and framework requirements into operational reality. The same executive gap that delays CMMC certification appears in NIST Cybersecurity Framework implementation, HIPAA security rule compliance, and state privacy law readiness. In each case, the organization has technical capability and compliance documentation but lacks the strategic layer that ensures the two align.

The NIST Cybersecurity Framework, referenced extensively in CMMC guidance, provides a structure for managing cybersecurity risk across five functions: Identify, Protect, Detect, Respond, and Recover. CMMC testing examines whether your organization has implemented that structure in a way that protects CUI. The framework does not prescribe specific technologies. It requires risk-informed decisions about what controls are necessary, how they will be implemented, and how their effectiveness will be measured.

Similarly, the NIST Privacy Framework offers a tool for managing privacy risk through enterprise risk management, relevant where defense contracts involve personal information alongside CUI. Organizations subject to overlapping requirements must ensure their control implementations satisfy all applicable obligations without creating conflicting documentation.

These are governance questions, not technical ones. They require someone with the authority to make risk decisions, the expertise to interpret regulatory language, and the accountability to report progress to executive leadership. That is the definition of <a href="/vciso/">vCISO leadership</a>, and the reason <a href="/services/regulatory-and-framework-readiness/">Regulatory and Framework Readiness</a> is a distinct service category requiring strategic ownership rather than technical execution.

5What Leadership Should Do Next

If your organization has a CMMC certification deadline and no clear answer to the question "who decides when we are ready?", the next step is to establish executive ownership of readiness. That means identifying or engaging a qualified security leader with the authority to make risk decisions, the expertise to interpret NIST requirements, and the accountability to report certification status to the chief executive.

Concretely, leadership should take the following actions in the next 30 days.

• Identify who currently owns the relationship between technical implementation and regulatory compliance. If no single person has that accountability, recognize the gap as a risk to certification.
• Request a written assessment of readiness that answers: What controls are implemented? What documentation exists? What evidence can be produced on demand? What gaps remain? When will the organization be ready for assessment?
• Establish a governance process for risk decisions, including who approves compensating controls, who signs off on POA&Ms, and who authorizes the decision to schedule assessment.
• Ensure that the person reporting on readiness has the expertise to evaluate NIST SP 800-171 implementation, not just the ability to summarize task completion.
• If your organization does not have internal security leadership at this level, evaluate whether a vCISO engagement provides the strategic ownership necessary to close the gap.

CMMC certification is an executive responsibility that requires security expertise. Treating it as a technical project managed by IT or a documentation exercise managed by compliance introduces delays and regulatory risk. The organizations that certify on schedule are the ones that establish clear ownership of readiness early and ensure that owner has the authority and expertise the role requires.

Heights Consulting Group provides <a href="/vciso/">vCISO leadership</a> structured specifically for this accountability gap, with particular expertise serving <a href="/industries/government-and-defense-contractors/">government and defense contractors</a>. If your organization faces a CMMC deadline and lacks internal security leadership at the executive level, <a href="/contact/">a confidential consultation</a> can clarify what readiness requires and how vCISO engagement closes the gap. Reach out when the question of ownership becomes urgent.