All 110 controls, mapped to practical engineering implementations
Author: Leonard Esere | Senior Cybersecurity Engineer, CMMC Registered Practitioner
Credentials: DoD Secret Clearance | DoE Q Clearance | MITRE ATT&CK Practitioner | LANL Full ATO Lead
Date: April 2026
Organization: Aeolitech
Abstract
NIST Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, defines the security baseline that every defense contractor must implement before pursuing CMMC Level 2 certification. The standard organizes 110 security requirements across 14 control families—from Access Control (22 requirements) through System and Information Integrity (7 requirements). For engineers tasked with operationalizing these requirements, the framework can feel abstract; this guide bridges that gap. Each control family receives practical implementation guidance mapped to real engineering tools: Microsoft Conditional Access, Microsoft Defender for Endpoint (MDE), Azure GCC High tenants, AWS GovCloud environments, and hybrid on-premises architectures. The companion assessment guide, NIST SP 800-171A, defines 320 assessment objectives against those 110 requirements, and DoD assessors in medium and high-confidence reviews follow those objectives closely. Organizations with an accurate System Security Plan (SSP), documented evidence for every objective, and a defensible Plan of Action and Milestones (POA&M) for any gaps are the ones that survive C3PAO assessments. This guide provides the engineering playbook to get there.
Table of Contents
1. Framework Overview and Regulatory Context
2. Scoping Your CUI Environment
3. Control Family Deep Dives: Families 3.1–3.7
4. Control Family Deep Dives: Families 3.8–3.14
5. Engineering Platform Mapping (Azure GCC High, AWS GovCloud, Hybrid)
6. Control-to-Tool Reference Table
7. NIST 800-171A Assessment Objectives: What Assessors Actually Check
8. Common Pitfalls by Family
9. SSP and POA&M Documentation Strategy
10. About the Author
11. References
1. Framework Overview and Regulatory Context
NIST SP 800-171 Rev 2 was published in January 2021 and remains the operative standard for DoD contracts under DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting. Although NIST released Revision 3 on May 14, 2024, the DoD issued a class deviation in May 2024 locking compliance requirements to Rev 2 for DFARS 7012 purposes, and the CMMC Final Rule (32 CFR Part 170) explicitly references Rev 2. C3PAO assessors are not authorized to evaluate against Rev 3 as of 2026.
The 110 security requirements derive from FIPS 200 and NIST SP 800-53, tailored for nonfederal organizations. They cover confidentiality of CUI—not integrity or availability—which explains why some 800-53 control families (Contingency Planning, Program Management, Privacy) are absent from 800-171.
Regulatory chain:
| Regulation | Role |
|---|---|
| DFARS 252.204-7012 | Requires CUI safeguarding and cyber incident reporting |
| DFARS 252.204-7019/7020 (now renumbered 252.240-7997) | Mandated SPRS self-assessment submission |
| 32 CFR Part 170 | CMMC Final Rule; maps Level 2 to all 110 requirements |
| NIST SP 800-171 Rev 2 | The 110 security requirements themselves |
| NIST SP 800-171A Rev 2 | 320 assessment objectives; used by C3PAOs and DIBCAC |
The maximum SPRS score is 110 (full compliance); the minimum is -203 (zero controls implemented). Contracting officers view SPRS scores during source selection, and scores significantly below 110 raise red flags during award decisions.
2. Scoping Your CUI Environment
Before touching a single control, define your CUI boundary. This is the single most important—and most frequently botched—step in any 800-171 implementation.
CUI boundary definition process:
1. Identify every system that processes, stores, or transmits CUI: workstations, servers, cloud tenants, shared drives, email systems, mobile devices, printers.
2. Map data flows: where does CUI enter, how does it move, where does it leave (or get destroyed)?
3. Define the enclave boundary: which network segments are in-scope vs. out-of-scope?
4. Document external service providers: cloud providers, MSPs, SaaS tools. Each must meet FedRAMP Moderate equivalency under DFARS 7012(b)(2)(ii)(D) if they touch CUI.
Proper scoping reduces assessment surface area, lowers cost, and prevents engineers from implementing controls against systems that don't need them. Organizations that over-scope waste engineering resources; those that under-scope fail C3PAO assessments when assessors find CUI outside the documented boundary.
3. Control Family Deep Dives: Families 3.1–3.7
3.1 Access Control (22 Requirements)
Access Control is the largest family, governing who can access CUI systems, under what conditions, and through which pathways. It covers user account lifecycle, least privilege enforcement, session management, remote access, wireless access, and mobile device controls.
Key requirements and implementations:
| Requirement | Description | Engineering Implementation |
|---|---|---|
| 3.1.1 | Authorize access to systems and CUI | Azure AD Conditional Access + account lifecycle automation |
| 3.1.2 | Limit system access to authorized transaction types | RBAC in Azure AD; IAM policies in AWS GovCloud |
| 3.1.3 | Control CUI flow across boundaries | DLP policies (Microsoft Purview); network segmentation |
| 3.1.5 | Employ least privilege | JIT access in Azure PIM; IAM least-privilege policies |
| 3.1.12 | Monitor and control remote access sessions | Azure AD Conditional Access + MFA; VPN with MFA |
| 3.1.13 | Employ FIPS-validated cryptography for remote access | FIPS 140-2 validated VPN (IKEv2/AES-256); Azure VPN GW |
| 3.1.14 | Route remote access via managed access control points | Forced tunneling in Azure; split tunneling disabled |
| 3.1.20 | Verify and control all external connections | Firewall rules + DLP; no unauthorized cloud sync |
| 3.1.22 | Control CUI on mobile devices | Intune MDM; Azure AD device compliance policies |
Common pitfall: Shared accounts. Every user must have a unique account (3.1.1 objective). Generic "admin" or "service" accounts without unique attribution are a near-automatic finding during C3PAO assessments. Implement privileged identity management and log every privileged action.
3.2 Awareness and Training (3 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.2.1 | Ensure users are aware of security risks | Annual security awareness training; phishing simulations |
| 3.2.2 | Ensure users are trained on CUI responsibilities | CUI-specific training module; documented completion records |
| 3.2.3 | Provide security awareness training for insider threats | Insider threat awareness module; SOAR alerts |
Tool mapping: KnowBe4 or Microsoft Viva Learning for training; document completion records in your SSP evidence library. Assessors will ask for training records by employee name and completion date.
3.3 Audit and Accountability (9 Requirements)
Audit logging is one of the highest-value families from a scoring perspective—several requirements carry 5-point SPRS weights. The family requires creation, protection, and review of audit logs sufficient to detect, investigate, and attribute security events.
| Requirement | Description | Implementation |
|---|---|---|
| 3.3.1 | Create and retain system audit logs | Azure Monitor + Log Analytics; AWS CloudTrail |
| 3.3.2 | Ensure actions of individuals can be traced | Unique user accounts + audit log correlation |
| 3.3.5 | Correlate audit review, analysis, reporting | SIEM (Microsoft Sentinel, Splunk); automated alerting |
| 3.3.8 | Protect audit information from unauthorized access | Immutable log storage (WORM); Log Analytics retention policies |
| 3.3.9 | Limit management of audit logging to subset of privileged users | Azure PIM; dedicated log admin role |
Common pitfall: Logging without reviewing. 3.3.5 requires correlation and analysis, not just collection. Implement Sentinel analytics rules or equivalent SIEM detections. Assessors ask "how do you review logs?" and expect a documented process with frequency and responsible party.
3.4 Configuration Management (9 Requirements)
Baseline configurations prevent security drift. This family requires establishing secure baselines for all systems, controlling changes, and tracking system components.
| Requirement | Description | Implementation |
|---|---|---|
| 3.4.1 | Establish baseline configurations | STIG baselines; CIS Benchmarks; Azure Policy; AWS Config |
| 3.4.2 | Establish system configuration change control processes | Change management workflow (ServiceNow, Azure DevOps) |
| 3.4.3 | Track, review, approve system changes | CAB process; change tickets with audit trail |
| 3.4.6 | Employ least functionality | Disable unnecessary ports, protocols, services (DISA STIGs) |
| 3.4.7 | Restrict/prevent use of prohibited components | Application whitelisting (Windows Defender App Control) |
| 3.4.8 | Apply deny-by-default / allow-by-exception software execution | WDAC policies; AppLocker in audit mode before enforcement |
Common pitfall: Undocumented baselines. "We follow CIS benchmarks" is not sufficient. Assessors want to see the actual baseline configuration documented in your SSP, with evidence of deviations tracked and approved.
3.5 Identification and Authentication (11 Requirements)
This family has some of the heaviest SPRS weights. Multifactor authentication (3.5.3) and password requirements are the most frequently cited gaps.
| Requirement | Description | Implementation |
|---|---|---|
| 3.5.1 | Identify system users, processes, devices | Azure AD identity governance; service principal management |
| 3.5.2 | Authenticate identities before access | Azure AD + MFA; FIDO2 keys; smart cards (PIV/CAC) |
| 3.5.3 | Use MFA for local/network access to privileged accounts and network access to non-privileged accounts | Azure AD Conditional Access MFA; Authenticator app or FIDO2 |
| 3.5.7 | Enforce minimum password complexity | Azure AD Password Protection; 12-character minimum |
| 3.5.8 | Prohibit password reuse | Azure AD password history (24 passwords) |
| 3.5.10 | Store and transmit only cryptographically-protected passwords | FIPS-validated hash (bcrypt, PBKDF2); never plaintext |
| 3.5.11 | Obscure feedback during authentication | Hidden password entry; no password hints |
Critical note on 3.5.3: The DoD Assessment Methodology assigns up to 5 SPRS points for MFA. Non-implementation of MFA for privileged accounts costs 5 points; non-implementation for all network access costs an additional 3. MFA is the single highest-leverage remediation for score improvement.
3.6 Incident Response (3 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.6.1 | Establish operational incident-handling capability | IR plan documented and tested; DFARS 7012 72-hour reporting |
| 3.6.2 | Track, document, report incidents | Incident ticketing (ServiceNow); DIBCAC reporting to cyber.mil |
| 3.6.3 | Test the organizational incident response capability | Annual tabletop exercises; quarterly IR reviews |
DFARS 72-hour rule: Under DFARS 252.204-7012, contractors must report cyber incidents to DoD within 72 hours of discovery. Your IR plan must explicitly cover this reporting pathway.
3.7 Maintenance (6 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.7.1 | Perform maintenance on organizational systems | Scheduled maintenance windows; patch management policy |
| 3.7.2 | Provide controls on tools, techniques, mechanisms for maintenance | Approved maintenance tools list; no unauthorized remote tools |
| 3.7.3 | Ensure non-local maintenance is performed with MFA | MFA required for all remote maintenance sessions |
| 3.7.5 | Require MFA to establish non-local maintenance sessions | Conditional Access policy covering all remote admin connections |
4. Control Family Deep Dives: Families 3.8–3.14
3.8 Media Protection (9 Requirements)
Media protection governs physical and digital media containing CUI—hard drives, USB drives, printed documents, backup tapes.
| Requirement | Description | Implementation |
|---|---|---|
| 3.8.1 | Protect CUI on system media during transport | BitLocker encryption on removable media; encrypted USB policy |
| 3.8.2 | Limit access to CUI on media to authorized users | DRM; access control on file shares |
| 3.8.3 | Sanitize/destroy media before disposal or reuse | NIST 800-88 media sanitization; documented certificate of destruction |
| 3.8.4 | Mark media with CUI markings | Physical labels on drives, tapes; digital watermarking |
| 3.8.5 | Control access to media with CUI | Locked media storage; access log |
| 3.8.6 | Implement cryptographic mechanisms to protect CUI during transport | AES-256 encryption; FIPS 140-2 validated tooling |
| 3.8.9 | Protect backups of CUI from unauthorized access | Encrypted offsite backups; backup access controls |
Common pitfall: Ignoring printed output. CUI printed from a contractor's system requires the same protections as digital CUI. Implement secure print release and document shredding procedures.
3.9 Personnel Security (2 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.9.1 | Screen individuals prior to authorizing access | Background checks; adjudication process |
| 3.9.2 | Ensure CUI is protected during and after personnel actions | Termination procedures; revoke access same day as departure |
3.10 Physical Protection (6 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.10.1 | Limit physical access to CUI systems | Badge readers; biometric locks; visitor logs |
| 3.10.2 | Protect/monitor physical facility and support infrastructure | CCTV; environmental monitoring; alarm systems |
| 3.10.3 | Escort visitors and monitor visitor activity | Visitor sign-in; escort policy |
| 3.10.4 | Maintain audit logs of physical access | Badging system logs; visitor logs retained |
| 3.10.5 | Control and manage physical access devices | Key/badge management; revoke on separation |
| 3.10.6 | Enforce safeguarding measures for CUI at alternate work sites | Remote work policy; endpoint management for remote workers |
3.11 Risk Assessment (3 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.11.1 | Periodically assess risk to organizational operations | Annual risk assessment; documented risk register |
| 3.11.2 | Scan for vulnerabilities periodically and when new vulnerabilities are identified | Tenable.io or Qualys monthly scans; patch within SLA |
| 3.11.3 | Remediate vulnerabilities in accordance with risk assessments | Patch management program; documented remediation timelines |
Vulnerability scanning is heavily weighted. Documented scanning frequency and a credible remediation SLA (e.g., critical: 30 days, high: 90 days) are expected in your SSP.
3.12 Security Assessment (4 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.12.1 | Periodically assess security controls | Annual internal assessment; C3PAO assessment every 3 years |
| 3.12.2 | Develop POA&Ms to correct deficiencies | Documented POA&M with owner, date, corrective action |
| 3.12.3 | Monitor security controls on an ongoing basis | Continuous monitoring; SIEM alerting |
| 3.12.4 | Develop, document, and periodically update SSP | Living SSP reviewed at least annually |
3.12.4 is binary: No SSP means no SPRS score possible, and no CMMC assessment can proceed. The SSP is the foundational document.
3.13 System and Communications Protection (16 Requirements)
The second-largest family, covering network boundary protection, encryption, and architectural security.
| Requirement | Description | Implementation |
|---|---|---|
| 3.13.1 | Monitor and control communications at boundaries | Next-gen firewall (Palo Alto, Fortinet); Azure Firewall |
| 3.13.2 | Employ security engineering principles | Secure by design; defense in depth; least functionality |
| 3.13.5 | Implement subnetworks for publicly accessible components | DMZ architecture; WAF in front of public systems |
| 3.13.8 | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI | TLS 1.2+ for data in transit; BitLocker for data at rest |
| 3.13.10 | Establish and manage cryptographic keys | PKI; Azure Key Vault; AWS KMS |
| 3.13.11 | Employ FIPS-validated cryptography to protect CUI | AES-256 (FIPS 197); RSA-2048+; validated modules only |
| 3.13.15 | Protect wireless access to systems containing CUI | WPA3-Enterprise; 802.1X; rogue AP detection |
| 3.13.16 | Protect CUI during wireless transmission | WPA3-Enterprise with AES-CCMP; no WEP or WPA |
3.13.11 FIPS-validated cryptography is a 5-point SPRS control. Using non-FIPS-validated encryption (e.g., consumer-grade TLS implementations) costs 3 points even if encryption is present.
3.14 System and Information Integrity (7 Requirements)
| Requirement | Description | Implementation |
|---|---|---|
| 3.14.1 | Identify, report, correct system flaws | MDE for endpoint protection; WSUS/MECM for patching |
| 3.14.2 | Provide protection from malicious code | Microsoft Defender Antivirus; CrowdStrike; SentinelOne |
| 3.14.3 | Monitor system security alerts and advisories | CISA alerts; vendor advisories; SIEM integration |
| 3.14.4 | Update malicious code protection mechanisms | Automatic signature updates; daily at minimum |
| 3.14.5 | Perform periodic scans and real-time scans | MDE real-time protection + scheduled full scans |
| 3.14.6 | Monitor systems to detect attacks and potential indicators of compromise | MDE EDR; Sentinel UEBA; network IDS/IPS |
| 3.14.7 | Identify unauthorized use of systems | UEBA baselines; anomaly detection; DLP alerts |
5. Engineering Platform Mapping
Azure GCC High
Azure Government Community Cloud High (GCC High) is purpose-built for contractors handling CUI and meets FedRAMP High authorization. It provides the cleanest path to CMMC Level 2 compliance for Microsoft-centric organizations.
| 800-171 Requirement | Azure GCC High Service |
|---|---|
| 3.1.1 / Access Control | Azure Active Directory + Conditional Access |
| 3.3.1 / Audit Logging | Azure Monitor + Log Analytics Workspace |
| 3.5.3 / MFA | Azure AD MFA + Microsoft Authenticator |
| 3.13.8 / Encryption in transit | TLS 1.2+ enforced by Azure services |
| 3.13.11 / FIPS cryptography | FIPS 140-2 validated Azure services (documented in Azure compliance docs) |
| 3.14.1 / Flaw remediation | Microsoft Defender for Cloud; MDE |
| 3.14.2 / Malware protection | Microsoft Defender Antivirus + MDE |
| 3.14.6 / Attack monitoring | Microsoft Defender for Endpoint + Sentinel |
Key advantage: Microsoft's FedRAMP High ATO package for GCC High provides substantial inherit-able controls. Contractors using GCC High inherit roughly 65–70 controls from Microsoft's authorization, reducing the implementation burden significantly.
AWS GovCloud (US)
AWS GovCloud hosts FedRAMP High–authorized services. It is preferred by contractors with Linux-heavy workloads or DevSecOps pipelines.
| 800-171 Requirement | AWS GovCloud Service |
|---|---|
| 3.1.1 / Access Control | AWS IAM + Identity Center (SSO) |
| 3.3.1 / Audit Logging | AWS CloudTrail + CloudWatch Logs |
| 3.3.5 / Log correlation | Amazon Security Hub + EventBridge |
| 3.13.10 / Key management | AWS KMS (FIPS 140-2 Level 3 HSMs) |
| 3.13.11 / FIPS cryptography | FIPS 140-2 endpoints available in GovCloud |
| 3.14.2 / Malware | Amazon Inspector + GuardDuty |
Hybrid Environments
Most mid-sized contractors run hybrid architectures: on-premises Active Directory, a cloud tenant (GCC High or GovCloud), and possibly legacy on-prem servers. Key hybrid considerations:
- Azure AD Connect syncs on-prem AD to Azure AD; ensure hybrid-joined devices meet Conditional Access policies.
- Azure AD Application Proxy extends Conditional Access to on-prem applications without a VPN.
- Microsoft Defender for Identity (MDI) protects on-prem domain controllers with behavioral analytics.
- Network segmentation between on-prem and cloud must enforce the same boundary controls as 3.13.1.
6. Control-to-Tool Reference Table
| NIST 800-171 Control | Control Description | Primary Tool | Secondary Tool |
|---|---|---|---|
| 3.1.1 | Limit system access to authorized users | Azure AD Conditional Access | Okta (for non-M365 orgs) |
| 3.1.12 | Monitor remote access sessions | Azure AD Sign-in Logs | Cisco DUO |
| 3.1.13 | FIPS-validated cryptography for remote access | Azure VPN Gateway (IKEv2/AES-256) | Palo Alto GlobalProtect |
| 3.3.1 | Create/retain audit logs | Azure Monitor / Log Analytics | Splunk |
| 3.3.5 | Correlate audit review | Microsoft Sentinel | Splunk SIEM |
| 3.4.1 | Establish baseline configurations | Azure Policy / AWS Config | STIG Viewer |
| 3.4.7 | Prevent unauthorized software | Windows Defender App Control | AppLocker |
| 3.5.3 | Multifactor authentication | Azure AD MFA | FIDO2 Security Keys |
| 3.11.2 | Vulnerability scanning | Tenable.io / Nessus | Qualys VMDR |
| 3.13.1 | Boundary protection | Azure Firewall / Palo Alto NGFW | AWS Network Firewall |
| 3.13.8 | Encrypt CUI at rest | BitLocker (Windows) / LUKS (Linux) | VeraCrypt |
| 3.13.11 | FIPS-validated cryptography | AES-256 + FIPS 140-2 modules | Azure Disk Encryption |
| 3.14.1 | Flaw remediation | Microsoft Endpoint Configuration Manager | WSUS + Ivanti |
| 3.14.2 | Malicious code protection | Microsoft Defender Antivirus (MDE) | CrowdStrike Falcon |
| 3.14.6 | Attack/IOC detection | Microsoft Defender for Endpoint (EDR) | CrowdStrike + Sentinel |
7. NIST 800-171A Assessment Objectives: What Assessors Actually Check
NIST SP 800-171A defines 320 assessment objectives for the 110 security requirements. Each objective is evaluated using three methods:
- Examine: Review of SSP, policies, configurations, system documentation.
- Interview: Conversations with system owners, administrators, and users.
- Test: Technical testing of control implementations.
For example, requirement 3.1.1 alone has six distinct assessment objectives. An assessor will not simply ask "do you limit access?" They will examine the list of authorized users, interview the system administrator about the provisioning process, and test whether a sample of accounts has appropriate access rights.
High-failure objectives by family:
| Family | High-Failure Objective |
|---|---|
| 3.1 Access Control | Shared accounts; accounts not terminated upon separation |
| 3.3 Audit/Accountability | Logs not reviewed; log retention under 90 days |
| 3.4 Config Management | No documented baseline; change control not followed |
| 3.5 Identification/Auth | MFA not enforced for all privileged accounts |
| 3.11 Risk Assessment | Vulnerability scans not performed on all in-scope systems |
| 3.13 System/Comm Protection | Non-FIPS cryptography in use |
| 3.14 System/Info Integrity | AV signatures older than 24 hours |
8. Common Pitfalls by Family
| Family | Top Pitfall | Remediation |
|---|---|---|
| 3.1 Access Control | Shared admin accounts | Implement unique accounts + PAM |
| 3.2 Awareness/Training | No documented completion records | LMS with exportable logs |
| 3.3 Audit/Accountability | Logs exist but aren't reviewed | SIEM with scheduled review reports |
| 3.4 Config Management | STIGs applied but not documented | Automated STIG compliance reporting (SCAP) |
| 3.5 Identification/Auth | MFA missing for service accounts | Azure Managed Identities; workload identity federation |
| 3.6 Incident Response | IR plan exists but was never tested | Annual tabletop with documented outcome |
| 3.8 Media Protection | No removable media policy | Intune policy to block/encrypt USB |
| 3.11 Risk Assessment | Scans run but findings not tracked | Tenable SC with asset tracking + SLA enforcement |
| 3.12 Security Assessment | SSP outdated by more than 1 year | Quarterly SSP review cadence |
| 3.13 SC Protection | TLS 1.0/1.1 still enabled | Azure TLS Policy; enforce TLS 1.2+ |
| 3.14 SI | AV not deployed to all in-scope endpoints | Intune MDE onboarding policy |
9. SSP and POA&M Documentation Strategy
The System Security Plan is the primary artifact for every NIST 800-171 assessment. It must describe how each of the 110 requirements is implemented, who is responsible, what tools are used, and where evidence can be found.
SSP minimum sections:
1. System name and CAGE code(s)
2. System description and architecture diagram
3. CUI data flow diagram
4. For each of the 110 requirements: implementation status (Implemented / Partially Implemented / Not Implemented), implementation description, responsible role, and evidence location.
5. Interconnections with external systems
6. Roles and responsibilities
7. System boundary and authorization
POA&M requirements: Every gap must have an entry with:
- Control ID and description
- Gap/weakness description
- Responsible owner
- Planned corrective action
- Estimated completion date
- Interim mitigations (compensating controls)
SPRS scores must reflect the POA&M. If 3.5.3 (MFA) is in the POA&M, it must be scored as not implemented (-5 points) until fully remediated. Inflating SPRS scores above the actual implementation state constitutes a potential False Claims Act violation.
About the Author
Leonard Esere is a senior cybersecurity engineer and CMMC Registered Practitioner with over a decade of experience securing defense and national laboratory environments. He holds a DoD Secret clearance and a Department of Energy Q clearance—the equivalent of Top Secret in the intelligence community—and has served as the lead systems engineer on a full Authority to Operate (ATO) engagement at Los Alamos National Laboratory (LANL), one of the most complex classified computing environments in the federal government. His work spans MITRE ATT&CK-based threat modeling, CMMC gap assessments for Defense Industrial Base (DIB) contractors, and cloud security architecture for Azure GCC High and AWS GovCloud environments. Leonard advises organizations from pre-assessment readiness through C3PAO engagement and remediation.
For a complimentary CMMC gap assessment, visit /services/cmmc-gap-assessment.
References
1. NIST SP 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (January 2021) — https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final
2. NIST SP 800-171A Rev 2, Assessing Security Requirements for Controlled Unclassified Information — https://csrc.nist.gov/publications/detail/sp/800-171a/rev-2/final
3. 32 CFR Part 170, CMMC Final Rule (October 2024) — https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program
4. DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting — https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting.
5. DoD CIO, NIST SP 800-171 DoD Assessment Methodology — https://www.acq.osd.mil/dpap/pdi/cyber/docs/NIST%20SP%20800-171%20Assessment%20Methodology%20Version%201.2%20%209.24.2020.pdf
6. NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations — https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
7. SPRS (Supplier Performance Risk System) — https://www.sprs.csd.disa.mil/nistsp.htm
8. Microsoft Azure Government Compliance Documentation — https://docs.microsoft.com/en-us/azure/compliance/offerings/offering-dod-il5
9. CUI Registry, National Archives — https://www.archives.gov/cui/registry/category-list
10. CMMC Accreditation Body (CMMC-AB) — https://cyberabi.org/