CMMC Level 2 Encryption Evidence Checklist

Encryption can be active across your environment and still fail an assessment if you cannot prove where it protects CUI, which module provides it, and how your team manages it. For a defense contractor, CMMC Level 2 encryption evidence must connect technical settings to the CUI boundary in the system security plan.

I treat encryption evidence as a chain of custody. Every link matters: the system inventory, the approved cryptographic module, the configuration, the policy, and the people who operate it.

The checklist below helps me prepare evidence that an assessor can examine, test, and discuss with the staff responsible for the environment.

Key Takeaways

• CMMC Level 2 assessments evaluate the 110 requirements in NIST SP 800-171 Rev. 2, including requirements that call for FIPS-validated cryptography to protect CUI.
• A vendor claim that a product “uses AES-256” is not proof of FIPS validation.
• Your evidence needs to identify the exact product version, cryptographic module, operating mode, and CUI use case.
• Screenshots alone are weak evidence unless they show the system name, setting, date, and relationship to the CUI boundary.
• Applicability depends on your system security plan, contract requirements, CUI environment, and the assessor’s interpretation.

Start With the CUI Boundary and Assessment Scope

I begin with the system security plan, often called the SSP. It establishes the boundary that drives every encryption decision. If the SSP does not identify where CUI is stored, processed, or transmitted, the encryption evidence will look disconnected and incomplete.

CMMC Level 2 is built on the 110 security requirements in NIST SP 800-171 Rev. 2. For encryption, the most relevant requirements often include:

• 3.13.8, which requires protection of CUI confidentiality at rest.
• 3.13.11, which requires protection of CUI confidentiality in transit.
• 3.13.16, which requires FIPS-validated cryptography when used to protect CUI confidentiality.
• 3.1.3, 3.1.16, and 3.13.1, which affect who can reach encrypted CUI and how systems are protected.

The CMMC program materials from the Department of Defense provide the current program framework. However, I don’t treat a generic compliance summary as a substitute for the actual contract, the SSP, or the assessment scope.

Encryption evidence must show more than a security feature exists. It must show that the feature protects CUI within the assessed environment.

Create or update a data-flow diagram before gathering screenshots. Mark every point where CUI enters, resides, moves, or leaves the boundary. Include laptops, file shares, Microsoft 365 tenants, backup repositories, mobile devices, VPNs, cloud workloads, managed service portals, and removable media.

Then build a scope worksheet that identifies the following for each component:

Component	CUI Activity	Encryption Need	Evidence Owner
Windows endpoint	Stores and accesses CUI	Full-disk encryption, TLS	IT administrator
Microsoft 365 tenant	Stores and shares CUI	Tenant encryption, secure access	Microsoft 365 administrator
VPN gateway	Transmits CUI remotely	FIPS-validated VPN cryptography	Network administrator
Backup platform	Retains CUI backups	Encryption at rest and key control	Backup administrator
Cloud workload	Processes CUI	Encryption, access controls, logging	Cloud administrator

This mapping prevents a frequent mistake: collecting strong evidence for systems that never handle CUI while leaving a backup appliance or shared mailbox undocumented.

Build a FIPS-Validated Cryptography Inventory

FIPS validation applies to a cryptographic module, not to an encryption algorithm alone. AES, TLS, SHA-256, and RSA can be part of a compliant configuration, but their presence does not establish that the module was validated for your use.

I verify modules through the Cryptographic Module Validation Program, or CMVP. The record should match the module vendor, module name, version, validation certificate, and operating environment where applicable.

For each in-scope product, retain a cryptography inventory with:

• Product name, edition, version, build number, and hostname or tenant identifier.
• The system’s CUI function, such as endpoint storage, file transfer, backup, remote access, or cloud collaboration.
• Encryption protocols and algorithms enabled for that specific use.
• The FIPS certificate number or a vendor document that maps the deployed module to the CMVP validation.
• Evidence that FIPS mode is enabled when the product requires a separate mode.
• The configuration owner, review date, and planned revalidation date.

The FIPS 140-3 standard sets security requirements for cryptographic modules. A certificate may apply only to a defined version and configuration. Therefore, I compare the CMVP listing against the installed version instead of relying on an old procurement record.

For example, an endpoint inventory should show which Windows devices store CUI, their BitLocker protection status, the encryption method, the TPM state, and recovery-key escrow location. A screenshot of BitLocker enabled is useful, but it needs supporting exports from Microsoft Intune, Active Directory, or your endpoint management platform.

Similarly, a firewall report should identify the active firmware version, VPN settings, approved cipher suites, user groups, and tunnel logs. If the appliance includes a FIPS mode, preserve an administrative screenshot and the change record that confirms when the team enabled it.

Capture Configuration Evidence That an Assessor Can Test

A clean folder of screenshots does not make a defensible evidence package. I collect configuration evidence in a way that allows an assessor to trace the claim from policy to system to user activity.

For CUI at rest, retain evidence for full-disk encryption, encrypted databases, encrypted file stores, and encrypted backups. On endpoints, include central-console exports that show device compliance. For servers, include encryption settings, key-management details, access-control settings, and system inventories.

Cloud services require equal care. Microsoft 365 encryption features are not a blanket answer for every CUI scenario. Document tenant licensing, the tenant type, conditional access policies, multifactor authentication, sharing controls, audit-log retention, endpoint restrictions, and the approved CUI workflow.

When I support an Office 365 Migration for a defense contractor, I preserve the pre-migration risk review, target architecture, migration runbook, validation tests, and post-migration access review. A move to Microsoft 365 changes where CUI resides, so the SSP, data-flow diagram, and encryption inventory must change with it.

For data in transit, retain configuration exports and test evidence for:

• TLS settings on web portals, email gateways, APIs, and file-transfer services.
• VPN configuration, including encryption settings, authentication method, and access groups.
• Secure remote administration protocols, such as SSH or HTTPS.
• Wireless encryption and segmentation where CUI-capable devices connect.
• Email and collaboration rules that prevent uncontrolled external sharing of CUI.

I also retain a dated test record. It can include a controlled file-transfer test, a VPN connection log, a vulnerability scan result, or a configuration review signed by the system owner. Test evidence should never expose actual CUI. Use a marked test file or a sanitized sample with no controlled content.

Keep Policies, Procedures, and Interview Evidence Aligned

Technical controls fail the evidence review when written procedures tell a different story. I compare the SSP, encryption policy, incident-response plan, asset-management policy, remote-access procedure, and media-protection procedure before the assessment.

The encryption policy should name the conditions that require approved cryptography, describe key management, assign responsibility, define exceptions, and state how the team reviews configurations. It should also direct staff on removable media, portable devices, cloud storage, backup restoration, and secure transmission.

A workable procedure contains the operational steps people follow. For example, a BitLocker procedure should show how the team provisions encryption, verifies protection, escrows recovery keys, handles a lost device, and records exceptions. A policy that says “encrypt laptops” without these steps leaves too much open to interpretation.

Interview evidence deserves preparation. I identify the people who can explain each control without guessing:

• The IT administrator can demonstrate endpoint encryption and recovery-key handling.
• The network administrator can explain VPN configuration, firewall management, and remote access.
• The cloud administrator can show Microsoft 365 settings, audit logs, and CUI collaboration controls.
• The security lead can explain policy reviews, risk decisions, exceptions, and remediation tracking.
• The business owner can describe how the organization identifies CUI and restricts its use.

I run a short evidence rehearsal with each owner. I ask them to locate the record, describe the control, and demonstrate the configuration in the same session. If documentation says one person owns the control while interviews identify another, I correct the record before the assessment.

Organize the Evidence Package for Review

I use a control-by-control evidence index rather than a single folder called “Encryption.” Each record identifies the NIST requirement, the CMMC practice, the evidence type, source system, owner, date collected, and sensitivity level.

A practical structure includes the following folders:

1. SSP, CUI data-flow diagrams, network diagrams, and asset inventories.
2. Cryptographic module inventory, CMVP validation records, and vendor attestations.
3. Endpoint, server, network, cloud, and backup configuration exports.
4. Policies, procedures, change tickets, risk decisions, and exception approvals.
5. Test records, audit logs, screenshots, interview notes, and remediation plans.

Screenshots should show enough context to stand on their own. Include the application name, device or tenant identifier, selected setting, and collection date. Redact passwords, recovery keys, secrets, IP addresses, and CUI before placing files into the assessor package.

I also maintain a remediation register for incomplete items. Honest evidence is stronger than a last-minute claim. Track the gap, affected system, compensating measures, owner, due date, and closure proof.

Bringing Encryption Discipline to Everyday IT Operations

My CMMC work draws on the same practices I use across Small Business IT, Cloud Infrastructure, and Office 365 Migration projects. Data Center Technology, Restaurant POS Support, and Kitchen Technology Solutions can introduce endpoints, networks, and remote support paths that require clear inventory and access decisions.

Cybersecurity Services should connect Endpoint Security and Device Hardening to documented operational procedures. Innovative IT Solutions and Tailored Technology Services only add value when the controls remain understandable to the people who operate them.

As a Business Technology Partner, I pair Technology Consulting with Cloud Management, Infrastructure Optimization, and Digital Transformation planning. That approach supports IT Strategy for SMBs, Secure Cloud Architecture, and Managed IT for Small Business without losing sight of Business Continuity & Security.

Conclusion

Strong CMMC Level 2 encryption evidence tells one consistent story: CUI is known, protected by approved cryptography, monitored, and managed by trained people. The story must hold up across the SSP, system settings, module records, policies, and interviews.

A well-maintained encryption evidence checklist reduces assessment stress because the proof already exists in the normal course of secure IT operations.