CMMC Compliance for Small Defense Contractors: The Complete Guide

What Is CMMC and Why Does It Apply to Small Defense Contractors?

CMMC (Cybersecurity Maturity Model Certification) is a DoD (Department of Defense) program that requires defense contractors to demonstrate cybersecurity practices aligned to NIST SP 800-171 (National Institute of Standards and Technology Special Publication 800-171) before being awarded contracts that involve CUI (Controlled Unclassified Information). Level 2, the most broadly applicable tier, requires 110 security practices and is mandated by 32 CFR Part 170, effective December 16, 2024.

The program does not stop at the prime contractor. Under DFARS 252.204-7021, primes are required to flow CMMC requirements down through every subcontractor that handles CUI or provides operationally critical support. A small SDVOSB (Service-Disabled Veteran-Owned Small Business) firm performing software development, IT support, or data processing on a DoD program is within scope even if the prime holds the contract and manages the customer relationship. If your company touches CUI, CMMC applies to you regardless of your position in the contract hierarchy.

Many small contractors assume that CMMC is a large-business problem or that a DoD program manager will grant an exception for firms below a revenue threshold. Neither is accurate. The DoD CIO's CMMC program page is explicit: size does not affect the requirement. What determines your applicable level is the sensitivity of the information you handle, not your company's headcount or annual revenue.

What Are the Four Phases of CMMC Implementation?

DoD is implementing CMMC through four phases, each expanding the scope of contracts that require certification. The phases are established in the DFARS 252.204-7021 acquisition rule, effective November 10, 2025, and run consecutively from that date forward.

Phase 1: November 10, 2025 through November 9, 2026. Level 1 self-assessments and Level 2 self-assessments begin appearing in new DoD solicitations. Contractors are required to have a current self-assessment score in SPRS (Supplier Performance Risk System) at the time of contract award. Self-assessment does not require a third party, but the score must reflect a genuine evaluation against all applicable controls, and submitting a false score carries legal risk under the False Claims Act.

Phase 2: November 10, 2026 through November 9, 2027. C3PAO (Certified Third-Party Assessment Organization) assessments become required at contract award for prioritized acquisition programs. Phase 2 is the threshold that most small contractors are treating as their hard deadline. A C3PAO assessment requires engaging an assessor accredited through the Cyber AB (Cybersecurity Maturity Model Certification Accreditation Body). Assessment timelines, including remediation windows, typically run four to six months for small organizations, which means readiness work for a Phase 2 award must begin no later than mid-2026 to avoid missing award windows.

Phase 3: November 10, 2027 through November 9, 2028. CMMC Level 3 requirements begin appearing in contracts for the most sensitive DoD programs. Level 3 assessments are conducted by DIBCAC (Defense Industrial Base Cybersecurity Assessment Center), a government-led body, not a commercial C3PAO. Level 3 adds 24 or more practices derived from NIST SP 800-172 on top of the 110 from NIST SP 800-171. Most small contractors will not be in scope for Level 3 unless they are handling the most sensitive program categories.

Phase 4: November 10, 2028 onward. Full CMMC implementation across all applicable DoD acquisitions. By this phase, self-assessment, C3PAO assessment, and DIBCAC assessment are all standard features of the DoD contracting landscape.

See our dedicated post on the CMMC timeline for small primes and subs for a step-by-step remediation sequence organized around these phase boundaries.

What Are the 14 Domains and 110 Controls in NIST SP 800-171?

NIST SP 800-171 Revision 2 organizes the 110 security requirements into 14 control families. Each family addresses a distinct area of the security architecture. Understanding how controls distribute across families helps organizations prioritize remediation work, because failures are not distributed equally. Some families are routinely cited in assessments as common gaps; others are easier to satisfy with standard commercial tools.

The families most commonly cited as gaps in assessments of small contractors are Access Control, Audit and Accountability, Configuration Management, Incident Response, Risk Assessment, System and Communications Protection, and System and Information Integrity. These are not necessarily the largest families; they are the families where small organizations tend to have undocumented or absent processes. An organization may be doing the right things operationally but have no SSP (System Security Plan) language to demonstrate it, which is functionally equivalent to a finding during assessment.

Personnel Security and Physical Protection tend to be lower-risk gaps because small contractors often already maintain personnel agreements and physical access controls as baseline business practices. Maintenance and Media Protection are moderate because they require documented procedures rather than technically complex implementations. The high-gap families require both technical implementation and documented evidence, which is why they appear repeatedly in assessment findings for small organizations.

What Is a System Security Plan and Why Is It the Foundation of CMMC?

The SSP (System Security Plan) is the document that describes how your organization implements each of the 110 NIST SP 800-171 controls within the boundary of systems that handle CUI. It is not a marketing document and it is not a checklist. It is a formal security architecture description that defines the CUI boundary, enumerates every system component within that boundary, and explains the specific mechanisms that satisfy each control.

Assessors read the SSP first. Before running a single technical test or reviewing a single log file, a C3PAO assessor will read your SSP to understand what you claim your environment looks like. Every subsequent finding is evaluated in the context of what the SSP says. If a control is marked as implemented in the SSP but the assessor's technical testing does not confirm the implementation, that is a finding. If a control is not addressed in the SSP at all, the assessor will treat it as not implemented regardless of what is actually running in the environment.

The SSP must define the CUI boundary precisely. This means enumerating specific systems, endpoints, storage locations, and data flows that touch CUI. Vague language such as "the corporate network" or "all servers" is not acceptable because it makes the control scope unmeasurable. The boundary definition directly determines the scope of your POA&M (Plan of Action and Milestones), your SPRS score submission to SPRS (Supplier Performance Risk System), and the scope of any C3PAO assessment.

A well-constructed SSP includes a network topology diagram, a data flow diagram showing where CUI enters and exits the boundary, a complete asset inventory of in-scope systems, a control-by-control narrative for all 110 requirements, and a reference to the POA&M for any controls not yet fully implemented. The CMMC timeline post covers the SSP creation step in context of the full remediation sequence with recommended completion dates relative to Phase 2.

How Does CMMC Level 2 Differ from Level 1 and Level 3?

The three CMMC levels address different categories of federal information and require different assessment approaches. Contractors need to understand which level applies to them and what the compliance obligation actually entails.

CMMC Level 1 covers 17 practices derived from FAR (Federal Acquisition Regulation) 52.204-21. These are basic safeguarding requirements for protecting FCI (Federal Contract Information), which is information the government provides or generates under a contract that is not intended for public release. Level 1 does not involve CUI. Assessment is an annual self-assessment conducted internally with no third-party verification required. The contractor submits an affirmation to SPRS. Level 1 is the entry point for contractors who handle federal data but are not working with sensitive program information.

CMMC Level 2 covers all 110 practices from NIST SP 800-171 Revision 2 and applies to contractors handling CUI (Controlled Unclassified Information), which is defined and categorized by the CUI Registry maintained by the National Archives and Records Administration. Level 2 has two assessment tracks. For programs not designated as critical by the DoD, a triennial self-assessment with SPRS affirmation is acceptable. For prioritized acquisition programs, a triennial C3PAO assessment conducted by a Cyber AB-accredited organization is required as a condition of contract award. The DoD determines which programs require C3PAO assessment; contractors cannot self-select into the self-assessment track for a program that DoD has designated as requiring third-party assessment.

CMMC Level 3 applies to contractors on the most sensitive DoD programs and adds 24 or more practices on top of the 110 from Level 2. These additional practices are derived from NIST SP 800-172, which addresses Advanced Persistent Threat (APT) risk in ways that NIST 800-171 does not fully address. Level 3 assessments are conducted by DIBCAC (Defense Industrial Base Cybersecurity Assessment Center), not commercial C3PAOs. DIBCAC assessments are government-led and are reserved for the highest-sensitivity program categories. Most small contractors pursuing standard DoD IT services, software development, or logistics support will not reach Level 3 requirements.

What Are the Most Common CMMC Assessment Failures for Small Contractors?

Assessment failures are concentrated in a predictable set of controls. Small contractors who address these specific controls before engaging a C3PAO have a materially better outcome than those who treat all 110 controls as equal priority. The following controls appear repeatedly in assessment findings from organizations that have been through the process.

Audit logging gaps (3.3.1 and 3.3.2). Control 3.3.1 requires creating and retaining system audit logs to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity. Control 3.3.2 requires ensuring the actions of individual users can be uniquely traced to those users. Many small contractors have logging enabled on their endpoints and servers but have not verified that log retention meets the requirement, that logs are centralized and tamper-protected, or that individual user actions are distinguishable in the log record. Assessors test this by requesting logs from specific dates and asking for the user attribution chain.

Configuration management (3.4.2). Control 3.4.2 requires establishing and enforcing security configuration settings for information technology products used in organizational systems. This means documented baselines, not ad hoc configurations. An assessor will ask to see your documented security baseline for Windows workstations, servers, network equipment, and any other in-scope device. If the baseline exists only in someone's head or as an informal practice, 3.4.2 is a finding.

Incident response planning (3.6.1 and 3.6.2). Control 3.6.1 requires establishing an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. Control 3.6.2 requires tracking, documenting, and reporting incidents to designated officials. Small contractors often have no written incident response plan and have never conducted a tabletop exercise. An assessor will ask for the plan, ask who is responsible for each phase, and ask for evidence of a test or exercise in the past year.

Encryption (3.13.11). Control 3.13.11 requires employment of FIPS (Federal Information Processing Standard)-validated cryptography when used to protect the confidentiality of CUI. Standard commercial encryption tools may not use FIPS-validated modules even when they are configured for strong encryption. This is a common gap for contractors using cloud storage, email, or VPN solutions without verifying FIPS compliance status. The control requires not just that encryption is in use, but that the specific cryptographic modules are FIPS-validated.

Malware defense (3.14.2 and 3.14.6). Control 3.14.2 requires providing protection from malicious code at appropriate locations within organizational systems. Control 3.14.6 requires monitoring organizational systems to detect attacks and indicators of potential attacks. Small contractors who rely on built-in Windows Defender without central management, signature updates, and alert forwarding to a monitored log repository typically fail both controls. An assessor will ask to see that malware defense is actively monitored, not just installed.

Access control (3.1.1 and 3.1.3). Control 3.1.1 requires limiting system access to authorized users, processes acting on behalf of authorized users, and devices. Control 3.1.3 requires controlling the flow of CUI in accordance with approved authorizations. These controls fail when contractors have not documented which users are authorized to access CUI systems and have not implemented controls that prevent CUI from flowing to unauthorized destinations such as personal email, personal cloud storage, or unauthorized removable media.

Boundary protection (3.13.5). Control 3.13.5 requires implementing subnetworks for publicly accessible system components that are physically or logically separated from internal networks. Small contractors who run CUI systems on the same network segment as general office workstations, guest WiFi, or internet-facing services fail this control. Network segmentation around the CUI boundary is a prerequisite for a defensible SSP, not an optional enhancement.

What Technical Controls Does CMMC Actually Require?

The 110 NIST SP 800-171 controls translate into specific technical implementations. Understanding what assessors are looking for at the infrastructure level helps IT teams and IT providers scope the work correctly. The following list covers the implementations that appear most frequently in assessment methodologies for small contractor environments.

MFA (Multi-Factor Authentication) on all systems touching CUI. Control 3.5.3 requires using MFA for local and network access to privileged accounts and for network access to non-privileged accounts. MFA must be enforced, not optional. A policy that says MFA is required but does not technically enforce it is a finding. Single sign-on solutions that federate to an identity provider with MFA enforcement satisfy this control. Shared accounts that cannot be attributed to individual users fail control 3.3.2 regardless of MFA status.

FIPS-validated encryption at rest and in transit. Control 3.13.8 requires implementing cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. Control 3.13.16 requires protecting the confidentiality of CUI at rest. Both controls require FIPS-validated cryptographic modules. TLS 1.2 or higher with FIPS-compliant cipher suites satisfies the in-transit requirement. BitLocker in FIPS mode or an equivalent FIPS-validated solution satisfies the at-rest requirement. Verify the specific product's FIPS certificate on the NIST Cryptographic Module Validation Program list before documenting it in your SSP.

Audit logging with retention and tamper protection. Controls 3.3.1 through 3.3.9 require creating, protecting, reviewing, and retaining audit logs. Logs must be protected from unauthorized modification or deletion (control 3.3.8), which means log forwarding to a centralized SIEM (Security Information and Event Management) with access controls that prevent the local administrator from modifying the log record. Log retention periods must be documented in the SSP and enforced technically. Three years is a common defensible retention period for federal contractor environments.

EDR (Endpoint Detection and Response) with central management. Controls 3.14.2 and 3.14.6 require active malware defense and system monitoring. A standalone antivirus product without central management, centralized alerting, and a monitored response workflow does not satisfy these controls for assessment purposes. An EDR platform that provides behavioral detection, centralized alert management, and audit-capable event logging is the standard implementation. As we documented in our honeypot post on nation-state tradecraft, SSH key persistence attacks achieve 0 of 76 detection rates against commercial antivirus. EDR with behavioral monitoring is required to detect this class of threat.

Vulnerability scanning and patch management. Control 3.14.1 requires identifying, reporting, and correcting information and information system flaws in a timely manner. This requires a documented patching cadence, evidence of patch application, and a process for tracking exceptions. Control 3.11.2 requires scanning for vulnerabilities in organizational systems periodically and when new vulnerabilities potentially affecting those systems are identified. An authenticated vulnerability scanner run on in-scope systems on a documented schedule, with findings tracked to remediation, satisfies both controls.

Incident response plan with documented procedures and evidence of testing. Controls 3.6.1 and 3.6.2 require an operational incident-handling capability and a process for reporting incidents to designated officials, including reporting to the DoD under DFARS 252.204-7012 within 72 hours of discovery of a cyber incident involving CUI. A written plan exists is not sufficient evidence for an assessor. Evidence of a tabletop exercise or simulated incident response, with documented outcomes and lessons learned, demonstrates that the plan is operational.

Backup, recovery, and documented RTO and RPO. Control 3.8.9 requires protecting the confidentiality of backup CUI at storage locations. Control 3.6.1 includes recovery as a component of incident handling. Backup solutions that protect CUI backup copies with FIPS-validated encryption, store copies off-site or in a geographically separated cloud region, and have documented and tested recovery procedures satisfy both requirements.

Network segmentation around CUI. Control 3.13.5 requires network boundary protection that separates publicly accessible components from internal networks. The CUI boundary defined in your SSP must be enforced at the network layer, not just as a policy. Firewalls with CUI-specific rulesets, VLAN (Virtual Local Area Network) segmentation for CUI systems, and documented egress filtering to prevent CUI from leaving the boundary without authorization are the standard technical implementations.

How Should Small Contractors Approach CMMC Readiness?

The remediation sequence matters as much as the individual controls. Organizations that address controls in the wrong order spend time implementing technical solutions before they have defined what they are protecting, which leads to scope creep, duplicate work, and documentation that does not match the implemented environment. The following six-step sequence is organized to avoid those failure modes.

Step 1: Determine whether you actually handle CUI. Not all defense contractors handle CUI. If you provide services that do not involve access to sensitive program data, technical specifications, export-controlled research, or other categories listed in the CUI Registry, your CMMC requirement may be Level 1 only. Confirm with your contracting officer or prime contractor whether CUI is in scope for your specific work. Do not assume Level 2 applies; verify it. However, do not assume you are exempt without verification. Many contractors discover CUI in their environment only after they have mapped their data flows.

Step 2: Define the CUI boundary. Once you confirm CUI is present, enumerate every system, application, storage location, and data flow that touches it. This is the CUI boundary, and it defines the scope of everything that follows. A tightly defined boundary reduces the scope of your assessment and the cost of remediation. A loosely defined boundary expands scope unnecessarily. The boundary must be documented in your SSP with a network topology diagram and a data flow diagram that shows where CUI enters, where it resides, and where it exits.

Step 3: Conduct a gap assessment against NIST SP 800-171. Evaluate your current security posture against each of the 110 controls, using the defined CUI boundary as the scope. For each control, determine whether it is fully implemented, partially implemented, or not implemented. Score each gap by risk. Prioritize gaps in the control families that appear most frequently in assessment findings: Access Control, Audit and Accountability, Configuration Management, Incident Response, System and Communications Protection, and System and Information Integrity.

Step 4: Write the SSP. The SSP documents how each control is implemented in your environment. It is not written after remediation is complete; it is written as remediation progresses, with controls marked as implemented, partially implemented, or planned. The SSP is a living document. Assessors expect to see the SSP reflect the current state of the environment, not an aspirational target state. For controls not yet implemented, the SSP references the POA&M.

Step 5: Build the POA&M. The POA&M (Plan of Action and Milestones) documents every control gap identified in the gap assessment, the remediation approach, the responsible owner, and the target completion date. A well-structured POA&M demonstrates to assessors that gaps are being actively managed, which is required under control 3.12.2 (develop and implement plans of action). An organization with a documented POA&M and evidence of progress is in a better assessment position than an organization with no gaps documented but also no evidence of implementation.

Step 6: Implement controls in priority order starting with highest-risk gaps. Use the SPRS (Supplier Performance Risk System) scoring methodology to calculate your current self-assessment score and track improvement as controls are remediated. The SPRS scoring system assigns point values to each control, and the total score ranges from -203 (all controls missing) to 110 (all controls implemented). DoD program managers can view SPRS scores, and a very low score is a risk signal for prime contractors evaluating subcontractor selection. See the CMMC timeline post for the recommended remediation sequence with specific dates tied to Phase 2.

What Does CMMC Flowdown Mean for Subcontractors?

CMMC flowdown is one of the most misunderstood aspects of the program for small businesses. Many SDVOSB firms and small subcontractors assume that CMMC is the prime's problem and that they can rely on the prime to handle certification. That assumption is incorrect.

Under DFARS 252.204-7021, prime contractors are required to include CMMC requirements in subcontracts at the same level as their own contract when the subcontractor will handle CUI or provide operationally critical support. The subcontractor must independently meet the CMMC requirement. The prime cannot certify on behalf of a subcontractor, and a subcontractor cannot pass assessment by pointing to the prime's C3PAO assessment.

Practically, this means that primes are increasingly screening potential teaming partners for CMMC readiness before pursuing opportunities together. A small contractor who cannot demonstrate a credible path to Level 2 certification, including a current SPRS score and a documented POA&M, is a liability to a prime competing for a contract where all subcontractors must be certified. As Phase 2 approaches, primes will tighten their subcontractor vetting processes, and firms with no visible CMMC progress will be replaced by firms that have begun the process.

For SDVOSB firms pursuing teaming arrangements on set-aside contracts, CMMC readiness is increasingly a prerequisite for being selected as a teaming partner. See our SDVOSB Federal IT Contracting Guide for teaming strategy context, including how to position CMMC readiness as a competitive differentiator in capability statement language and teaming conversations.

How Is TDS-IS Positioned for CMMC Assessment Support?

TDS-IS (Trinity Data Solutions and IT Services, LLC) is an SDVOSB managed IT services provider that has built the internal infrastructure that CMMC assessors look for: centralized audit logging with tamper-protected retention, FIM (File Integrity Monitoring) on authentication-critical files, EDR with behavioral detection, network segmentation with documented CUI boundary controls, and documented incident response procedures tested against realistic threat scenarios.

Our threat intelligence infrastructure is not a theoretical capability. We operate an active honeypot and publish technical findings that directly map to NIST SP 800-171 control gaps. The nation-state tradecraft post documents a three-year-old SSH persistence campaign achieving 0 of 76 antivirus detection rates. The 21-day honeypot analysis maps the specific attack patterns we observe to the NIST 800-171 controls they affect. These are not marketing documents. They are the raw output of operating real detection infrastructure and using what we observe to improve the specific controls that CMMC assesses.

For small contractors who need managed IT support that holds up under a Level 2 assessment, we provide gap assessment services, SSP development, POA&M management, and ongoing managed detection and response through our AI-augmented operations platform. Our approach to AI tooling is described in the AI without shipping CUI post, which covers the architectural decisions that allow us to use modern AI capabilities without creating supply chain exposure for federal clients.

If you are evaluating subcontractors or teaming partners for DoD work, the right question to ask an IT provider is not whether they are familiar with CMMC. Ask for their SSP, their current SPRS score, and their last assessment result. Ask which threat intelligence they have produced and how it maps to their detection controls. Ask for the audit logs from a specific date range. Those questions separate organizations that have done the work from organizations that have read the framework.