StealthTech
A CMMC Level 2 certification doesn’t happen by accident. It happens because an organization systematically worked through 110 security practices, implemented each one at a depth that produces verifiable evidence, and built the documentation infrastructure that connects implementation to assessor scrutiny. The checklist below isn’t a shortcut to that work — but it is a practical reference for ensuring none of it gets missed.
This checklist is organized around the 14 NIST SP 800-171 control families that underpin CMMC Level 2, with the implementation and documentation requirements that matter most for each. Use it to structure your gap analysis, track remediation progress, and verify readiness before the formal C3PAO assessment begins.
Before You Check Anything Else: Foundational Prerequisites
Before working through individual control domains, three foundational elements need to be in place — because every other compliance activity depends on them.
Your assessment scope needs to be defined and documented. Without a clear, accurate scope definition, there’s no way to know which systems need to meet which requirements, which users are covered by access control policies, or which vendors are inside the compliance boundary. A scope that’s too broad inflates cost and assessment surface area unnecessarily. A scope that’s too narrow leaves systems uncovered that an assessor will find. If you haven’t conducted a formal scoping exercise, that’s the starting point — not the control checklist. Our guide on how to scope your CMMC environment correctly covers the methodology.
Your System Security Plan needs to exist and be current. The SSP is the document an assessor reads before anything else, and every control determination made during the assessment is evaluated against what the SSP says. An SSP that doesn’t exist, is incomplete, or describes an environment that no longer reflects reality creates assessment problems that nothing else in the compliance program can compensate for. Our detailed guide on creating a System Security Plan covers what a compliant SSP requires.
Your POA&M needs to be a living document reflecting current compliance status. Any known gaps not yet remediated should be documented with specific owners, interim mitigations, and target dates. A POA&M created the week before assessment to satisfy a documentation requirement looks exactly like what it is, and assessors recognize the pattern.
Access Control (AC) — 22 Practices
Access control is the largest domain in CMMC Level 2 and consistently the one with the most assessment findings. The checklist items here address the most frequently cited gaps.
System access is limited to authorized users, processes acting on behalf of authorized users, and devices including other systems. Every account with access to in-scope systems is there because someone authorized it for a specific purpose — and that authorization is documented and reviewable.
Access permissions are consistent with the principle of least privilege. Users and service accounts have access only to the systems and data their role requires. Privileged accounts are separate from standard user accounts, and privileged access is used only when required for specific administrative functions.
Multi-factor authentication is enforced for all accounts with access to CUI systems — not offered, not recommended, enforced at the system level through directory service or conditional access policies. This enforcement covers service accounts, shared accounts, vendor accounts, and recently provisioned accounts, not just standard named user accounts.
Remote access to in-scope systems is authorized, documented, monitored, and controlled through defined mechanisms. Every remote access pathway into the CUI environment is known and logged. Session encryption is enforced on all remote connections.
External connections — every network path that crosses the assessment boundary — are documented in the SSP and governed by specific authorization and control requirements. Undocumented external connections are a consistent assessor finding that scope review should surface before the assessment does.
Access is reviewed on a defined schedule, and access is revoked promptly when users leave the organization or change roles. Evidence of those reviews — dated records showing who conducted them and what was found — exists in the compliance documentation package.
Mobile device access to CUI systems is governed by documented requirements covering configuration standards, access controls, and restrictions on the handling of CUI on mobile devices.
Identification and Authentication (IA) — 11 Practices
Every user, process, and device accessing CUI systems is uniquely identified. Shared accounts are eliminated or, where unavoidable, controlled with compensating measures and documented justification. Authenticator strength meets the requirements of the framework — password complexity and history requirements enforced at the system level, not just in policy. Default passwords on all in-scope systems have been changed.
MFA implementation provides replay resistance — meaning the authentication mechanism remains secure even against session hijacking and real-time proxy attacks. FIDO2 hardware tokens or equivalent phishing-resistant authenticators satisfy this requirement at the highest confidence level.
Audit and Accountability (AU) — 9 Practices
Audit logs are generated across all in-scope systems capturing the user activity, system events, and security-relevant actions specified in the framework. Log scope and granularity have been verified to cover what’s required — not just assumed based on default logging settings.
Audit logs are protected against unauthorized access, modification, and deletion. Log storage is separate from the systems generating logs where technically feasible. Retention meets the period specified in organizational policy, which should align with CMMC and contract requirements.
Log review happens on a documented schedule by a specific person or team, with records showing the review occurred, what was examined, and what the outcome was. This is not a passive log storage requirement — it’s an active review requirement with evidence of execution.
The capacity of audit log storage is monitored to prevent logs from being lost due to storage exhaustion. Alerts or automated monitoring notify responsible staff before capacity is reached.
Configuration Management (CM) — 9 Practices
Baseline configurations are documented for all in-scope system types — servers, workstations, network devices, cloud instances. These baselines reflect current CIS benchmarks or equivalent security standards and are specific enough that deviations are identifiable.
Baselines are actually applied to in-scope systems. The gap between documented baseline and deployed configuration — systems in production that don’t match the documented standard — is one of the most common configuration management findings. Configuration compliance scanning confirms alignment.
A change management process governs all modifications to in-scope systems. Changes go through authorization before implementation. Emergency changes have a defined expedited process with post-implementation documentation. The change management records form a part of the compliance evidence package.
Unnecessary programs, functions, ports, protocols, and services are disabled or removed on in-scope systems. The attack surface of CUI systems reflects only what’s needed for their defined function. User-installed software is controlled. Either technical controls prevent installation of unauthorized software, or monitoring detects it promptly. The policy governing this is understood by users, not just written.
Incident Response (IR) — 3 Practices
An incident response capability exists — not just a plan, but the personnel assignments, communication procedures, containment procedures, recovery procedures, and escalation paths that make the plan executable. The capability has been tested through a tabletop exercise or equivalent, with documented outcomes and follow-up actions.
The incident response plan addresses CUI-specific requirements including the obligation to report cyber incidents affecting CUI to the DoD within 72 hours per DFARS 252.204-7012. The person responsible for making that report knows they’re responsible, knows the reporting mechanism, and has the information needed to execute the report in time.
Lessons learned from incidents and exercises are incorporated into plan updates. The incident response plan has a revision history showing it’s maintained rather than static.
Risk Assessment (RA) — 3 Practices
Periodic risk assessments are conducted on a documented schedule, with records showing they occurred, who participated, what was evaluated, and what the findings were. Risk assessment findings connect to the POA&M and to control decisions — not to a report that gets filed without affecting what gets done.
Vulnerability scanning covers all in-scope systems on a defined frequency. Scan results are current, findings are prioritized by severity, and remediation timelines are documented and followed. The gap between scan date and current date — environments where scans were conducted for the gap analysis and haven’t recurred since — is an assessment finding in the making.
System and Communications Protection (SC) — 16 Practices
Network boundaries between the CUI environment and the general corporate network, and between the CUI environment and external networks, are enforced by technical controls — firewalls, network access control, or equivalent boundary protection mechanisms — not just described in documentation.
CUI is encrypted in transit using FIPS-validated cryptographic mechanisms. Unencrypted protocols for transmitting CUI are prohibited and technically blocked where feasible. The specific encryption standards in use are documented in the SSP.
Network segmentation supporting the assessment scope is technically enforced. If out-of-scope systems are excluded from the compliance environment based on network separation, that separation is enforced at the network layer and verifiable through technical testing — not just asserted in the scope documentation.
Cloud services handling CUI operate under FedRAMP Moderate authorization or equivalent. The specific services, subscription tiers, and configuration decisions that determine whether the cloud environment meets this requirement are documented and verifiable.
System and Information Integrity (SI) — 7 Practices
Malicious code protection is deployed on all in-scope systems and configured to update automatically. Coverage gaps — systems that don’t have endpoint protection, or that have it installed but not actively managed — are identified and addressed before the assessment.
Security alerts and advisories from software vendors and security organizations are received, reviewed, and acted upon. There’s a process for evaluating new vulnerabilities as they’re disclosed and assessing their relevance to in-scope systems.
In-scope systems are monitored to detect attacks, indicators of potential attacks, and unauthorized connections. Monitoring produces alerts, alerts are reviewed, and the review produces documented outcomes. A cybersecurity program that includes active monitoring with operational response — not just log storage — satisfies this requirement in substance.
Awareness and Training (AT) — 2 Practices
Security awareness training has been completed by all personnel with access to CUI systems within the last 12 months. Training completion records exist showing who completed training, what training they completed, and when. The training content addresses CUI-specific handling requirements, not just generic security hygiene.
Personnel with specific security responsibilities receive role-based training commensurate with those responsibilities. System administrators, incident responders, and other personnel with elevated security functions have training documentation beyond the general awareness program.
Remaining Domain Checklist Items
Physical protection requirements are met for facilities housing in-scope systems — physical access is limited to authorized individuals, visitor access is controlled and logged, and physical security controls protect against unauthorized removal of equipment or media.
Personnel security requirements address pre-employment screening for roles with CUI access and formal termination procedures that include immediate access revocation.
Media protection covers CUI stored on removable media — how it’s marked, stored, transported, and sanitized or destroyed when no longer needed. Maintenance activities on in-scope systems are performed by authorized personnel, and remote maintenance sessions are controlled and monitored.
The security assessment practice domain requires that CMMC controls are periodically assessed to confirm they remain implemented and effective — essentially, that the compliance program includes the internal audit function that prevents drift between assessment cycles. Our guide on building a continuous compliance program covers how this internal audit function operates in practice.
Pre-Assessment Final Verification
With control implementation complete, a final verification pass before the formal C3PAO engagement covers the elements that most often produce last-minute findings. The SSP is reviewed against the current environment for accuracy. Every system listed is still in scope and still configured as described. Every control description matches what technical testing would find. Every external connection and vendor relationship described in the SSP reflects current reality.
The evidence library is organized and complete. Evidence for each control family is current — not a single historical snapshot but a record of ongoing operation. Access review records, vulnerability scan histories, training completion logs, log review records, configuration compliance reports, and change management records all exist and are accessible.
Personnel who will be interviewed during the assessment have been briefed on their responsibilities and can describe how they execute them in their own words. They know what MFA they use and why. They know who to call if they discover an incident. They know what the change management process requires. They haven’t memorized scripts — they understand their roles.
The POA&M reflects the current state of any remaining gaps honestly. Items that have been remediated are closed with evidence. Items still in progress have realistic target dates and documented interim mitigations. Nothing appears on the POA&M that was supposed to be complete and isn’t.
With these elements in place, the formal assessment becomes what it should be — a verification of work already done, not a discovery of how much remains.
Conclusion: The Checklist Is the Map, Not the Territory
A CMMC Level 2 checklist tells you what needs to exist. Building what needs to exist — the implemented controls, the operational processes, the continuous evidence, the accurate documentation — is the compliance program itself. Organizations that treat the checklist as a documentation exercise rather than an implementation guide arrive at their assessment having checked boxes without building controls, and the assessment finds the difference.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
