Module 5: CMMC Domains and Core Control Families

Step 1 – Orienting CMMC Level 2 to NIST SP 800-171 Domains

In CMMC 2.0, Level 2 is effectively a conformity layer on top of NIST SP 800-171 Rev. 2 (as of late 2025; Rev. 3 is still in draft and not yet adopted in contracts). That means:

• The core security expectations come from NIST SP 800-171’s 14 control families ("domains").
• CMMC adds assessment structure, scoping, and enforcement for DoD contractors handling Controlled Unclassified Information (CUI).
• Protection of Federal Contract Information (FCI) is largely covered at CMMC Level 1, but many organizations must meet both Level 1 (FCI) and Level 2 (CUI) in parallel.

For Level 2, the 14 NIST SP 800-171 domains are:

1. Access Control (AC)
2. Awareness and Training (AT)
3. Audit and Accountability (AU)
4. Configuration Management (CM)
5. Identification and Authentication (IA)
6. Incident Response (IR)
7. Maintenance (MA)
8. Media Protection (MP)
9. Personnel Security (PS)
10. Physical Protection (PE)
11. Risk Assessment (RA)
12. Security Assessment (CA)
13. System and Communications Protection (SC)
14. System and Information Integrity (SI)

In this module we will:

• Focus on the most operationally challenging domains for CMMC Level 2: AC, IA, AU, CM, IR, SC, SI.
• Show representative controls and how they work together to protect FCI/CUI.
• Highlight interdependencies and why no domain is truly isolated.

> Mental model: Think of the 14 domains as subsystems in a single security engine. If one subsystem fails (e.g., logging, incident response, or configuration control), the entire engine is at risk, regardless of how strong the others are.

Step 2 – Access Control (AC) and Identification & Authentication (IA)

Access Control (AC) and Identification & Authentication (IA) are the front door of your CUI environment.

Access Control (AC)

Purpose: Limit access to CUI systems and data to authorized users, processes, and devices, and only as needed.

Representative NIST SP 800-171 controls:

• AC.1.001 – Limit system access to authorized users, processes, and devices.

CMMC impact: Documented user provisioning, role-based access, and removal of access when no longer needed.

• AC.2.009 – Limit access to CUI on system media to authorized users.

Example: Only specific project team members can access a CUI SharePoint library; others see nothing.

• AC.3.012 – Employ the principle of least privilege.

Example: Engineers can see design drawings but cannot access HR data; HR can access personnel records but not source code.

• AC.3.015 – Authorize remote access prior to allowing such connections.

Example: Only managed, compliant laptops can connect via VPN with MFA; no random home PCs.

Identification & Authentication (IA)

Purpose: Ensure the entity requesting access is who/what it claims to be.

Representative controls:

• IA.1.076 – Identify information system users and processes.

Example: Unique accounts for each user; no shared “CUIuser” logins.

• IA.2.078 – Enforce a minimum password complexity and change of characters.

Example: 14-character passwords, no reuse of last 24 passwords, blocked common passwords.

• IA.3.083 – Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts.

CMMC reality: MFA is one of the most visible Level 2 requirements and a frequent audit focus.

Interdependency: AC ↔ IA

• IA proves identity; AC enforces what that identity can do.
• Weak IA (e.g., simple passwords, no MFA) undermines even perfect AC design.
• Poor AC (e.g., everyone is a local admin) makes IA almost irrelevant.

> Edge case to think about: Service accounts and APIs. They are not humans, but they still must be uniquely identified (IA) and tightly scoped (AC). Many contractors fail here because these accounts are hidden in legacy systems and scripts.

Step 3 – Mini Case: Fixing Access Control in a Small Defense Contractor

Consider a 120-person engineering firm newly targeting CMMC Level 2 contracts.

Initial state (non-compliant):

• All engineers are in a single “Engineering” AD group with full access to all project shares.
• A shared local admin account (`Admin123`) exists on all workstations.
• VPN requires only username/password; no MFA.
• When employees leave, HR notifies IT by email sometimes; accounts are often left active for weeks.

Target state (aligned with AC & IA controls):

1. Role-based access groups

• Separate AD groups per project (e.g., `ProjAEng`, `ProjBEng`).
• CUI libraries mapped only to groups that legitimately need access (AC.3.012 – least privilege).

1. Unique administrative identities

• Each admin has a separate privileged account (`j.smith_admin`) with MFA enforced (IA.3.083).
• Shared `Admin123` account disabled; local admin rights removed from standard users.

1. Strong identity verification

• VPN and cloud access require MFA for all users (IA.3.083).
• Password policies updated to enforce length, complexity, and banned-password lists (IA.2.078).

1. Automated deprovisioning

• HR system integrated with identity management: when HR marks an employee as terminated, AD account is auto-disabled (AC.1.001, IA.1.076).
• A daily report lists accounts inactive for >30 days for manual review.

Result:

• The firm can show clear evidence for AC/IA controls: group membership records, MFA policies, deprovisioning logs.
• The attack surface for stolen credentials and insider misuse is significantly reduced.

> Analytical question: If an attacker steals one engineer’s password but not their MFA token, which specific IA/AC controls meaningfully limit the damage?

Step 4 – Audit & Accountability (AU): Making Security Observable

Audit & Accountability (AU) enables you to see and reconstruct what happened in your systems. Without AU, you cannot prove or even know whether CUI was compromised.

Key purposes:

• Record relevant security events (log generation).
• Correlate and analyze events (log aggregation/monitoring).
• Retain logs long enough to support investigations and CMMC assessments.

Representative controls:

• AU.2.041 – Ensure that the actions of individual system users can be uniquely traced to those users.

Example: Log entries that show `UserID`, `Source IP`, `Timestamp`, `Action` (e.g., file read, file delete).

• AU.2.042 – Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting.

Practice point: CMMC assessors often ask: How long do you retain logs? Where? Are they tamper-resistant?

• AU.3.048 – Collect audit information (e.g., logs) into one or more central repositories.

Example: A SIEM (Security Information and Event Management) system ingesting logs from endpoints, servers, firewalls, and cloud services.

Interdependencies: AU with AC, IA, and IR

• AC/IA define who can do what; AU records what they actually did.

E.g., if a privileged user exports 10 GB of CUI, AU logs should show it.

• Incident Response (IR) depends on AU to detect anomalies and reconstruct events.

No logs → IR is guesswork.

• Security Assessment (CA) uses AU outputs to verify that controls are working in practice (e.g., no excessive privilege use).

> Edge case: Cloud logging. Many contractors assume the cloud provider “handles logging.” For CMMC, you must show you have access to, and retain, logs needed to monitor access to CUI, even if the platform is managed by someone else.

Step 5 – Configuration Management (CM): Controlling Change and Baselines

Configuration Management (CM) ensures your systems are built and changed in a deliberate, documented, and repeatable way. Most CMMC Level 2 failures trace back to uncontrolled change.

Primary goals:

• Establish secure baselines for systems that handle CUI.
• Control and document changes to those systems.
• Prevent unauthorized or ad hoc modifications.

Representative controls:

• CM.2.061 – Establish and maintain baseline configurations and inventories of organizational systems.

Example: A golden Windows 11 CUI workstation image with defined settings, plus an asset inventory that maps which devices use that image.

• CM.2.062 – Employ the principle of least functionality by configuring the system to provide only essential capabilities.

Example: Disabling unneeded services, removing default apps, and blocking non-business software on CUI endpoints.

• CM.2.064 – Track, review, approve/disapprove, and log changes to organizational systems.

Example: Formal change tickets for firewall rule changes, OS upgrades, and new software deployments.

• CM.3.068 – Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.

Example: Blocking SMBv1, disabling Telnet, restricting PowerShell to signed scripts.

Interdependencies: CM with SI, SC, and IR

• System & Information Integrity (SI) relies on CM to ensure patches and anti-malware configurations are deployed consistently.
• System & Communications Protection (SC) depends on CM for enforcing secure network configurations (e.g., TLS versions, firewall rules).
• Incident Response (IR) assumes you know the expected configuration; otherwise you cannot tell if a change is malicious or just undocumented.

> Common contractor pitfall: A “shadow IT” culture where admins make direct changes on production systems without change tickets or documentation. This breaks CM and undermines almost every other domain.

Step 6 – Incident Response (IR), System & Communications Protection (SC), and System & Information Integrity (SI)

These three domains are about resisting attacks and responding effectively when they occur.

---

Incident Response (IR)

Purpose: Prepare for, detect, analyze, contain, eradicate, and recover from incidents involving CUI.

Representative controls:

• IR.2.093 – Develop an incident response plan.

Must define roles, communication paths, severity levels, and interaction with external parties (e.g., DoD, law enforcement).

• IR.2.094 – Detect and report events.

Tightly coupled with AU; users and systems must be able to report suspicious activity.

• IR.2.096 – Train personnel in their incident response roles and responsibilities.

Not just IT: management, legal, HR, and communications all have roles.

• IR.2.097 – Test the incident response capability.

Tabletop exercises, simulated phishing, or red-team events.

---

System & Communications Protection (SC)

Purpose: Protect data in transit and enforce secure boundaries between networks.

Representative controls:

• SC.1.175 – Monitor, control, and protect communications at external boundaries and key internal boundaries.

Example: Firewalls and segmentation between CUI and non-CUI networks.

• SC.2.179 – Use cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission.

Example: TLS 1.2+ for web traffic, VPN encryption for remote access.

• SC.3.192 – Separate user functionality from system management functionality.

Example: Admin interfaces only accessible from a management network, not from general user VLANs.

---

System & Information Integrity (SI)

Purpose: Detect, report, and correct system flaws and malicious activity.

Representative controls:

• SI.1.210 – Identify, report, and correct information system flaws in a timely manner.

Example: A formal patch management process with defined SLAs.

• SI.2.214 – Monitor system security alerts and advisories and take appropriate actions.

Example: Subscribing to vendor security bulletins and CISA alerts; adjusting defenses accordingly.

• SI.3.219 – Implement spam protection mechanisms to detect and act on unsolicited messages.

Example: Email security gateways with phishing detection.

• SI.3.220 – Implement protections against malicious code.

Example: Endpoint detection and response (EDR), real-time anti-malware.

---

Interdependencies

• IR depends on AU and SI for detection and evidence; without logs and alerts, you cannot respond effectively.
• SC and SI work together to prevent and detect attacks (e.g., secure protocols + IDS/IPS + EDR).
• CM and SI must be aligned so that patching and anti-malware deployment follow controlled change processes.

> Advanced point: For CMMC Level 2, you are not required to adopt all the advanced cyber-resiliency techniques from NIST SP 800-172, but many organizations voluntarily implement selected 800-172 practices (e.g., deception, redundancy) to strengthen IR/SC/SI in high-risk environments.

Step 7 – Map a Single Event Across Multiple Domains

Thought exercise: A user reports that their laptop behaved strangely, and you later discover malware exfiltrated CUI over an encrypted channel. Map which domains must work correctly for this scenario to be handled well.

Work through these prompts (mentally or in notes):

1. Initial compromise

• Which AC/IA weaknesses might have allowed the malware in (e.g., local admin rights, weak MFA)?
• Which SC controls should have limited the attacker’s ability to communicate externally?

1. Detection

• Which SI controls should detect the malware (e.g., EDR, anomaly detection)?
• Which AU controls ensure you have logs of the exfiltration activity?

1. Response

• Which IR controls come into play once the incident is suspected?
• How does CM help you restore the system to a known-good baseline?

1. Post-incident improvement

• Which RA (Risk Assessment) and CA (Security Assessment) activities should be triggered to prevent recurrence?
• How might AT (Awareness & Training) be updated based on what users did or failed to do?

> Challenge: Try to phrase the incident entirely in terms of control failures or successes (e.g., “Failure of SI.3.220 to detect malware due to outdated signatures,” “Success of AU.2.042 allowed reconstruction of data exfiltration timeline”).

Step 8 – Quick Check on Domains and Interdependencies

Answer the question based on what you have learned so far.

Step 9 – Flashcards: Core Domains and Their Roles

Flip these cards (mentally) to reinforce key domains and what they do.

Step 10 – Ranking: Which Domains Are Hardest in Practice?

Contractors commonly struggle with some domains more than others when preparing for CMMC Level 2 assessments.

Task: Rank these four domains from most challenging to least challenging for a typical mid-sized contractor and justify your ranking:

• Access Control (AC)
• Configuration Management (CM)
• Incident Response (IR)
• Audit & Accountability (AU)

Consider:

• Existing maturity (e.g., do they already have logging or IR playbooks?).
• Cultural resistance (e.g., admins giving up direct changes without tickets, users accepting MFA).
• Tooling and cost (e.g., SIEM, EDR, ticketing systems).
• Evidence requirements for a CMMC third-party assessment (C3PAO audit) once the CMMC 2.0 rule is fully implemented in DoD contracts.

Write a brief justification (3–5 sentences) for your ranking. Be explicit about trade-offs (e.g., “IR is conceptually easier but often neglected; CM is technically straightforward but organizationally painful”).

Step 11 – Pulling It Together: Domains as a Cohesive Security Fabric

To close this module, connect the domains into a single narrative of how CUI is protected in a CMMC Level 2 environment:

1. AC + IA define who is allowed to access which CUI resources and under what conditions.
2. SC + SI make it hard for attackers to exploit systems or exfiltrate data, and help detect malicious activity if they try.
3. CM ensures the environment is built and changed in a controlled, documented way, reducing misconfigurations and drift.
4. AU gives visibility into what actually happens, enabling detection, investigation, and proof of compliance.
5. IR orchestrates the response when controls fail or are bypassed, minimizing damage and enabling recovery.
6. CA, RA, AT, PE, PS, MA, MP and others provide supporting structure: assessing risk, training people, securing facilities, managing media, and continuously improving.

For CMMC Level 2 success, you must:

• Avoid treating domains as isolated checklists; design them as an integrated system.
• Be able to show evidence that controls are not only documented, but operational and effective over time.
• Understand that weakness in one domain (e.g., AU) can nullify strength in others (e.g., AC, SC).

> As you move to later modules, keep asking: If this control failed, which other domains would detect or compensate for that failure? That systems-level thinking is what distinguishes basic compliance from robust, resilient security.