Encrypting Controlled Unclassified Information (CUI) at rest and managing the associated cryptographic keys is a core requirement of NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 (SC.L2-3.13.16); this post gives a practical, step-by-step implementation plan, real-world examples for a small business, specific technical recommendations, and audit-ready evidence to demonstrate compliance.
Overview and key objectives
The objective of SC.L2-3.13.16 is to ensure CUI stored on disks, databases, filesystems, object stores, backups, and removable media is protected with strong encryption and that cryptographic keys are managed securely over their lifecycle. For small businesses that handle DoD-related CUI, this means: identifying all CUI at rest, applying FIPS-acceptable algorithms (e.g., AES-256), using hardened key storage (KMS or HSM), enforcing access controls and separation of duties for key usage, logging key operations, and maintaining key rotation/retirement processes with documented evidence.
Step-by-step implementation (practical)
Step 1 — Inventory and classification
Start by inventorying where CUI resides: endpoints (laptops, mobile), servers (file shares, databases), cloud services (S3 buckets, object storage), backups, and removable media. Tag each asset with CUI scope and risk level. Produce a simple CSV or CMDB entry with columns: asset, owner, storage type, encryption status, key type (device TPM, KMS, HSM), and evidence pointer (config file, screenshot).
Step 2 — Choose encryption and key storage models
For symmetric data protection, standardize on AES-256 in an authenticated mode (AES-GCM where available). Use envelope encryption: data encrypted with a data key (AES-256) and that data key encrypted (wrapped) by a long-lived master key stored in a Key Management System (KMS) or Hardware Security Module (HSM). For cloud: AWS KMS (customer-managed CMK) or CloudHSM, Azure Key Vault (with HSM-backed keys), GCP Cloud KMS. For on-prem: a FIPS 140-2/3 validated HSM or appliance, or an enterprise KMS that integrates with your applications via KMIP.
Step 3 — Implement encryption for common asset types
Examples for a small business: full-disk encryption on laptops with BitLocker (Windows) bound to TPM and MDM policy, FileVault on macOS, LUKS2 + TPM on Linux. For file/object storage, enable SSE-KMS (S3 with SSE-KMS) or client-side envelope encryption using your KMS. For databases: enable Transparent Data Encryption (TDE) integrated with your KMS or use application-layer encryption for particularly sensitive fields (PII, financial data). For backups, store only encrypted backup artifacts and escrow the keys securely.
Key management lifecycle and controls
Define and document the lifecycle: key generation (use FIPS-validated RNG), distribution (never send plaintext keys in email), activation, rotation, compromise handling, archival, and secure destruction. Enforce least-privilege access to key policies: separate duties so that administrators who can create keys cannot unilaterally export master key material. Require dual control or split knowledge for key recovery and support key escrow mechanisms (e.g., split key shares stored in different secure locations).
Technical recommendations and examples
Technical specifics to implement: generate symmetric data keys of 256 bits, keep master keys at 3072-bit RSA or better (or ECC P-256/P-384) for wrapping if asymmetric is used. For AWS example: create a customer-managed CMK with automatic annual rotation disabled/enabled per policy, attach a least-privilege key policy granting only required IAM roles the kms:Encrypt/kms:Decrypt permissions, and record CloudTrail entries for each Encrypt/Decrypt/GenerateDataKey call as audit evidence. For on-prem, use an HSM with KMIP and ensure it is FIPS 140-2/3 validated; collect HSM certification number in your evidence package.
Operational practices, logging, and evidence for auditors
Log all key management events centrally (CloudTrail, SIEM) and retain logs per contract requirements (commonly 1–7 years depending on agreements). Create and keep artifacts for audits: key policies, KMS console screenshots, CLI audit outputs, rotation schedules, runbooks for key compromise, and periodic key use reports. For each CUI-bearing asset include configuration notes (e.g., BitLocker policy applied via Intune, LUKS header backup file hash stored in vault). These artifacts demonstrate the "implementation" and "sustained operation" reviewers look for under NIST/CMMC.
Real-world small-business scenario
Scenario: a small contractor stores CUI in a PostgreSQL database hosted on AWS RDS and in S3 for document storage. Implementation: enable RDS encryption with a customer-managed CMK in AWS KMS (master key stored with AWS KMS, optionally backed by CloudHSM). Configure the application to use envelope encryption for sensitive columns prior to insertion so database backups contain encrypted fields. For S3, enable SSE-KMS with the same CMK. Document the architecture diagram, the CMK ARN, key policy JSON, rotation schedule, and export CloudTrail logs that show key usage before the assessment.
Risks of non-implementation and common pitfalls
Failing to encrypt CUI at rest or poorly managing keys creates high-impact risks: data exfiltration with readable CUI, contract termination, legal exposure, fines, and loss of DoD trust. Common pitfalls include storing keys on the same machine as encrypted data, insufficient rotation or testing of key recovery, using non-authenticated encryption modes (e.g., CBC without integrity), and lack of access controls on key usage. Any of those can lead to undetectable data modification or unauthorized decryption.
Compliance tips and best practices
Best practices: (1) maintain a written Key Management Policy and a short key management runbook; (2) use envelope encryption and centralized KMS/HSMs; (3) enable and retain detailed audit logs; (4) implement least privilege and separation of duties for key operations; (5) rotate keys on a documented schedule and test key recovery quarterly; (6) collect and store evidence artifacts for audits. Automate enforcement where possible (IaC, policy-as-code) so configuration drift is minimized.
Summary: Meeting SC.L2-3.13.16 requires a practical combination of inventory, strong encryption (AES-256 GCM), hardened key storage (KMS/HSM), lifecycle processes (generation, rotation, recovery, destruction), logging, and documented evidence; for a small business, using cloud KMS with envelope encryption, TPM-backed disk encryption on endpoints, and clear policies/runbooks provides a repeatable, auditable implementation path that satisfies NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 expectations.
