---
name: cmmc-expert
description: Expert guidance for CMMC compliance assessment, scoping, and implementation
---

# CMMC Expert

You are an expert in the Cybersecurity Maturity Model Certification (CMMC) framework. Use this guidance to help organizations understand, scope, assess, and achieve CMMC compliance.

## References

| Reference | Type | Location | When to Use |
|-----------|------|----------|-------------|
| CMMC Reference XML | File | `reference-docs/cmmc/cmmc_reference.xml` | When looking up practice requirements and assessment objectives |
| L2 Assessment Guide | File | `reference-docs/cmmc/cmmc-assessment-guide-l2.md` | When understanding L2 practice intent and assessment methods |
| L3 Assessment Guide | File | `reference-docs/cmmc/cmmc-assessment-guide-l3.md` | When understanding L3 enhanced requirements |
| L2 Scoping Guide | File | `reference-docs/cmmc/cmmc-scoping-guide-l2.md` | When determining L2 assessment scope boundaries |
| L3 Scoping Guide | File | `reference-docs/cmmc/cmmc-scoping-guide-l3.md` | When determining L3 assessment scope boundaries |
| CMMC Program FAQs | File | `reference-docs/cmmc/CMMC-FAQsv5.md` | **Authoritative program-policy answers** — assessment frequency, POA&M/OPA rules, ESP/MSP/CSP scoping, FedRAMP-Moderate-equivalency for cloud, significant-change reassessment triggers, FCI vs CUI |
| CMMC Website | URL | `https://dodcio.defense.gov/CMMC/` | When checking current program guidance |
| NIST 800-171 | URL | `https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final` | When reviewing base practice definitions |

## What is CMMC?

CMMC protects Controlled Unclassified Information (CUI) in the Defense Industrial Base (DIB). Version 2.0 defines three maturity levels:

- **Level 1**: 17 basic safeguarding practices (FAR 52.204-21), self-assessment only
- **Level 2**: 110 practices from NIST SP 800-171, self-assessment or C3PAO certification
- **Level 3**: 24 additional enhanced requirements from NIST SP 800-172, DIBCAC assessment required

## Core Concepts

### The CUI-Centric View

Every compliance decision starts with: "Does this asset process, store, or transmit CUI?"

- **Process**: CUI is actively used (accessed, edited, generated, printed)
- **Store**: CUI is at rest (on media, in memory, in physical format)
- **Transmit**: CUI moves between assets (network, physical transport)

Security controls follow data flow, not organizational boundaries.

### Assessment Mindset

CMMC is evidence-based demonstration, not checkbox compliance:

- Assessment objectives are the ground truth (every [a], [b], [c] must be MET)
- Three methods: **Examine** (documents), **Interview** (people), **Test** (systems)
- One NOT MET objective = entire practice NOT MET
- Testing > Documentation > Interviews in evidence strength

## Scoping Framework

### Asset Categories

| Category | Description | Assessment |
|----------|-------------|------------|
| **CUI Assets** | Process, store, or transmit CUI | All requirements |
| **Security Protection Assets** | Protect CUI assets (SIEM, firewalls, etc.) | Relevant requirements only |
| **Contractor Risk Managed** (L2) | Could touch CUI but controlled by policy | SSP review, limited checks |
| **Specialized Assets** | IoT, OT, GFE, test equipment | Risk-based management |
| **Out-of-Scope** | Physically/logically separated from CUI | None |

### Scoping Questions

1. Where does CUI flow in the environment?
2. What systems protect those flows?
3. What is truly isolated from CUI?

## Level Progression

### Level 1 to Level 2

- L2 adds 93 practices to the 17 L1 basics
- Requires formal System Security Plan (SSP)
- May require C3PAO certification (contract-dependent)
- POA&M allowed for some practices (180-day closeout)

### Level 2 to Level 3

- Must achieve Final Level 2 (C3PAO) first
- L3 scope can be subset of L2 scope (e.g., data enclave)
- CRMAs become CUI Assets in L3 scope
- DIBCAC conducts all L3 assessments
- Enhanced protections against Advanced Persistent Threats

### XML Reference Structure

The `cmmc_reference.xml` file contains structured practice data:

```xml
<practice>
  <level>L1|L2|L3</level>
  <nist>3.X.X</nist>
  <name>Practice Name</name>
  <description>Requirement text</description>
  <discussion>Intent and guidance</discussion>
  <score>Point value</score>
  <poam>Yes|No</poam>
  <assessment>
    <objective>[a] First objective</objective>
    <objective>[b] Second objective</objective>
    <examine>Evidence to review</examine>
    <interview>People to consult</interview>
    <test>Systems to verify</test>
  </assessment>
</practice>
```

## Common Patterns

### Gap Assessment

1. Define scope using the appropriate Scoping Guide
2. For each domain, identify applicable practices by level
3. Evaluate each practice against all its objectives
4. Document evidence or gaps with remediation plan

### Implementation Planning

1. Prioritize: POA&M-eligible? Score weight? Domain grouping?
2. Group related practices (often share implementation)
3. Leverage shared services for cross-cutting requirements
4. Build evidence library continuously (don't wait for assessment)

### Assessment Preparation

1. Organize evidence by practice ID
2. Pre-brief personnel who will be interviewed
3. Prepare system demonstrations for testable controls
4. Review POA&M eligibility for any gaps

## Anti-Patterns to Avoid

- **Checkbox mentality**: Assessors test controls, not just verify documents exist
- **Cloud = compliant assumption**: You own implementation even with FedRAMP services
- **Ignoring Specialized Assets**: They're in scope, just assessed via risk-based policy
- **Over-scoping**: Increases burden unnecessarily
- **Under-scoping**: Missing CUI flows creates compliance gaps
- **Last-minute evidence gathering**: Build your evidence library continuously

## Key Terms

- **OSA**: Organization Seeking Assessment (self-assessment)
- **OSC**: Organization Seeking Certification (C3PAO or DIBCAC)
- **C3PAO**: CMMC Third Party Assessment Organization
- **DIBCAC**: Defense Industrial Base Cybersecurity Assessment Center
- **POA&M**: Plan of Action and Milestones (remediation tracking)
- **SSP**: System Security Plan
- **SPRS**: Supplier Performance Risk System — DoD's NIST 800-171 self-assessment scoring system

## SPRS Scoring

DoD's NIST 800-171 / CMMC scoring starts at 110 and deducts point values for unmet practices. Point weights live in `reference-docs/cmmc/cmmc_reference.xml` under each practice's `<score>` element.

### Verdict → Deduction mapping

| Verdict | Point Treatment | Rationale |
|---------|-----------------|-----------|
| Implemented | 0 (full credit retained) | Practice fully satisfied |
| Partially Implemented | −(score) | DoD treats partial as unmet for SPRS purposes — no partial credit |
| Planned | −(score) | Documented plan does not count toward score until implemented |
| Alternative Implementation | 0 if assessor accepts compensation; otherwise −(score) | Equivalent control accepted on the same terms as Implemented |
| Not Applicable | 0 (excluded; not in 110-denominator) | Justified N/A removes from both numerator and denominator |
| Not Assessed | 0, flagged unscored | Cannot compute score for this practice; practice contributes neither credit nor deduction |

### Score range

- Maximum: **+110** (all 110 L2 practices Implemented, no N/A)
- Floor: **−203** (worst-case full-deduction profile per DoD scoring methodology)
- Negative scores are valid; report them as-is — they signal the OSC is not within self-affirm range

### Composite computation

```
composite_score = 110
for each in-scope practice:
    if verdict in {Partially Implemented, Planned}:
        composite_score -= practice.score
    elif verdict == Alternative Implementation and not assessor_accepted:
        composite_score -= practice.score
    elif verdict == Not Assessed:
        flag practice as unscored; do not modify composite_score
    # Implemented, Alternative Implementation (accepted), Not Applicable: no change
emit composite_score, unscored_count, per_domain_breakdown
```

Per-domain breakdown is the same math limited to the practices in that domain (starting credit = sum of practice scores within the domain; deductions apply only within domain).

## POA&M Eligibility

A practice is **POA&M-eligible** when its `<poam>` element in `cmmc_reference.xml` is `Yes`. The DoD-CIO POA&M closeout window is **180 days** post-assessment for self-assessment and post-certification for C3PAO.

```
poam_eligible = (practice.poam_field == "Yes")
```

### Non-POA&M-eligible practices

Practices with `<poam>No</poam>` MUST be remediated before assessment or certification can proceed. They cannot be deferred. These are typically foundational controls whose absence creates immediate risk to CUI.

### Edge cases

- **Alternative Implementation accepted**: does not generate a POA&M item (already Implemented via the compensating control)
- **Not Applicable**: does not generate a POA&M item (excluded from scope)
- **Partially Implemented**: POA&M-eligible if the practice's `<poam>` field is Yes; otherwise must be fully remediated before assessment

## Effort Rubric

Use this when sizing remediation effort.

| Size | Definition |
|------|------------|
| **S (small)** | Under 1 week of focused effort. Single team or owner. Typical: documentation update, single-system configuration change, attestation collection, training rollout for an existing capability. |
| **M (medium)** | 1–4 weeks. Single team but may require coordination with one adjacent team. Typical: procedure authoring + rollout, technical control deployment on existing infrastructure, evidence repository setup, control automation for a single family. |
| **L (large)** | Over 4 weeks OR cross-team coordination beyond a single adjacent team. Typical: new technology deployment (SIEM, IdP, DLP), CUI flow re-architecture, multi-system encryption rollout, formal policy framework rewrite, capability that depends on third-party procurement. |

### Family-level defaults

When no practice-specific override is set, use these family defaults:

| Family | Default | Rationale |
|--------|---------|-----------|
| AC (Access Control) | M | Identity and authorization changes typically span multiple systems |
| AT (Awareness and Training) | S | Training rollouts are mostly logistics |
| AU (Audit and Accountability) | M | Logging coverage typically requires touching every in-scope system |
| CA (Security Assessment) | M | Continuous monitoring setup is multi-week |
| CM (Configuration Management) | M | Baseline definition + enforcement is multi-week |
| CP (Contingency Planning) | M | Plan authoring is short; testing is multi-week |
| IA (Identification and Authentication) | L | MFA / passwordless rollouts touch every account holder |
| IR (Incident Response) | M | Plan + tabletop |
| MA (Maintenance) | S | Procedure-heavy |
| MP (Media Protection) | S | Procedure-heavy |
| PE (Physical Protection) | S | Procedure / facility-coordination heavy |
| PS (Personnel Security) | S | HR-coordination |
| RA (Risk Assessment) | M | Methodology + execution |
| SC (System and Communications Protection) | L | Crypto / network architecture |
| SI (System and Information Integrity) | L | Monitoring / patching / FIM rollout |

### Practice-specific overrides

Override the family default when a practice is unusually large or small:

| Practice ID | Default | Override | Reason |
|-------------|---------|----------|--------|
| AC.L2-3.1.3 (Control CUI Flow) | M | **L** | Almost always requires data-flow re-architecture |
| AC.L2-3.1.20 (External System Connections) | M | **L** | Boundary inventory + control across all egress paths |
| MA.L2-3.7.4 (Maintenance media inspection) | S | **M** | Tooling / procedure development beyond simple rollout |

When a practice does not appear in the override table, use the family default.
