Blackhawk Computer Repair
Remote Support
Blackhawk Computer Repair
Please log in to view your CMMC checklist.

CMMC 2.0 Level 2 – Plain-English Explainer

This page breaks down the main CMMC Level 2 domains in non-legal, beginner-friendly language. It is meant to be read by business owners, managers, and technical staff who need to understand what the requirements actually mean in day-to-day operations.

For each domain, you will see:

  • A simple description of what the domain is about.
  • Key practices and how they show up in real environments.
  • Concrete examples of evidence you can gather for an assessment.
Aligned with your CMMC checklist plugin Written in practical, non-jargon language Usable as staff training material
Access Control (AC)
Who can get to what – and under what conditions.
+
Access control is about answering two questions: who is allowed to access CUI, and what are they allowed to do when they get there.

Plain-English overview

CMMC Level 2 expects you to deliberately limit access to systems and data that handle Controlled Unclassified Information (CUI). That means:

  • You know which roles need access to CUI and which do not.
  • You grant access based on job duties, not convenience.
  • You use technical controls (permissions, groups, VPNs, firewalls) to enforce those decisions.
  • You regularly review access to make sure it still makes sense.

Key practices in this domain

  • Define CUI access roles and permissions: Make a simple matrix that lists job roles (e.g., Contracts Manager, System Admin, Help Desk) and the CUI systems or data they can access, with a short business reason.
  • Enforce least privilege: Users should only see the systems and data required to do their work. For example, a help desk technician might be able to reset passwords but not open contract files with CUI.
  • Control remote access: Remote access into the environment that handles CUI should be limited, monitored, and protected with VPN + MFA.
  • Control shared and admin access: Limit how many people can use administrator accounts or shared accounts, and record who uses them and when.

What this looks like in real life

  • Active Directory groups for “CUI-Readers”, “CUI-Editors”, “CUI-Admins” rather than everyone using generic groups.
  • File shares where only specific project teams can see CUI folders, not “Everyone”.
  • VPN configured so only approved staff can connect, and only from approved devices.
  • Help desk staff following a written procedure before granting new access (ticket, manager approval, etc.).
Examples of evidence you can show an assessor:
  • Documented access control policy and role-to-system matrix.
  • Screenshots of AD groups, file permissions, or role-based access in key apps.
  • VPN/MFA configuration screenshots and a list of users allowed remote access.
  • Access review records (for example, quarterly review of who can access CUI repositories).
Asset Management (AM)
Know what you have, so you can protect it.
+
You cannot protect CUI if you do not know where it lives or which systems touch it. Asset management is about keeping that map up to date.

Plain-English overview

For CMMC, asset management focuses on identifying the systems, applications, and locations that store, process, or transmit CUI. Once those are defined, they become in scope for your security controls, patching, and monitoring.

Key practices in this domain

  • Inventory in-scope systems: Keep a list of servers, workstations, network gear, cloud services, and SaaS apps that are part of your CUI environment.
  • Identify CUI data locations: Document where CUI actually exists: specific folders, databases, apps, and shared mailboxes.
  • Track ownership: Assign an “owner” for each critical asset. This person is responsible for security decisions and approvals related to that system.

What this looks like in real life

  • A spreadsheet or asset management system listing all CUI-relevant assets with fields like: hostname, IP, role, location, OS, owner, in-scope (yes/no).
  • A simple network diagram showing CUI servers, users, VPN, and internet connections.
  • Clear identification of which cloud services hold CUI (for example, specific SharePoint sites or Teams channels).
Examples of evidence:
  • Asset inventory export with a filter flag for “CUI in-scope”.
  • Diagrams or documentation describing where CUI is stored and processed.
  • System ownership list showing who is responsible for each CUI system.
Audit & Accountability (AU)
Being able to answer “who did what, when, and from where.”
+
Logs are your “flight recorder” for security. If something goes wrong with CUI, you need to be able to reconstruct what happened.

Plain-English overview

This domain requires that you turn on logging, store logs safely, and actually review them. The goal is to detect suspicious behavior, support investigations, and prove that your controls are working.

Key practices

  • Enable logging on in-scope systems: Servers, endpoints, firewalls, and key apps should log security-relevant events.
  • Centralize and protect logs: Forward logs to a central system (SIEM, log collector) and restrict who can modify or delete them.
  • Define what to log: Decide which events matter: logons, failed logons, admin actions, permission changes, security alerts, etc.
  • Review and respond: Have someone look at alerts or summaries on a routine schedule, and know how to respond when something looks wrong.

What this looks like day-to-day

  • Windows and Linux event logs configured to capture logon failures and admin actions.
  • Firewall logs sent to a centralized logging or SIEM platform.
  • A weekly or daily routine where IT/Security staff review dashboards or email summaries.
Evidence examples:
  • Screenshots of logging configuration on servers, endpoints, and firewalls.
  • Sample SIEM dashboards or log search results.
  • Documented SOPs for log review and incident triage.
  • Tickets or records showing how past alerts were investigated.
Configuration Management (CM)
Keeping systems in a known, secure state – and tracking changes.
+
Configuration management is about deciding how systems should be built and making sure they stay that way.

Plain-English overview

In practice, this means hardening systems, documenting standard builds, and controlling configuration changes so nothing drifts into an insecure state that could put CUI at risk.

Key practices

  • Baseline secure configurations: Decide on a “gold image” or baseline config for servers, workstations, and network devices that handle CUI.
  • Change management: Require review/approval for meaningful changes (new software, new firewall rules, major upgrades).
  • Track changes: Keep records of what changed, when, why, and who approved it.

Real-world examples

  • A standard build document for Windows servers used for CUI applications.
  • Change tickets in a helpdesk or ITSM system for firewall modifications.
  • Group Policy Objects (GPOs) enforcing hardening settings on domain-joined machines.
Evidence examples:
  • Configuration baseline documents or exported GPO reports.
  • Change control tickets or spreadsheets listing recent changes to CUI systems.
  • System configuration management tool screenshots (e.g., Intune, RMM, Ansible, etc.).
Identification & Authentication (IA)
Proving that users and devices are who they claim to be.
+
If you cannot reliably identify users and devices, you cannot trust any other control. This domain is about accounts, MFA, and password policies.

Plain-English overview

CMMC Level 2 expects strong, well-managed identities for people, services, and (in some cases) devices. You must know who is logging in, and use more than just a password for sensitive access.

Key practices

  • Unique user IDs: No shared “generic” accounts for normal user work. Each person has their own login.
  • Multi-factor authentication (MFA): Required for remote access, admin accounts, and other high-risk access paths.
  • Strong passwords and lockout: Length, complexity, lockout after repeated failures, and password reuse limits.
  • Service and device identities: Carefully managed service accounts and device credentials, with restricted use.

Real-world examples

  • Azure AD / Entra ID configured to enforce MFA for admins and remote users.
  • Password policies set via GPO and enforced in cloud directory.
  • Service accounts stored in a password vault with limited admin access.
Evidence examples:
  • Screenshots of MFA enforcement policies.
  • Password policy configuration (GPO, MDM, or cloud directory settings).
  • List of service accounts with descriptions and owners.
Incident Response (IR)
Being ready for “bad days” involving CUI.
+
Incident response is about turning chaos into a repeatable process. The question is not “if” something goes wrong, but “how you will handle it.”

Plain-English overview

CMMC wants you to have a plan, train people on it, test it occasionally, and keep records when incidents actually occur. The focus is on incidents that affect CUI or systems that process CUI.

Key practices

  • Written incident response plan: A document explaining roles, contact info, communication plans, and step-by-step activities.
  • Clear reporting path: Staff know how to report suspicious events and whom to call after hours.
  • Exercises: Tabletop or technical exercises using realistic scenarios (e.g., ransomware in a CUI file share).
  • Incident records: Document what happened, when you discovered it, how you responded, and lessons learned.
Evidence examples:
  • Incident response plan document with version history.
  • Training or awareness records showing staff were briefed on reporting incidents.
  • Tabletop exercise agendas, notes, and action items.
  • Incident tickets or reports from actual past incidents.
Maintenance (MA)
Doing maintenance in a controlled, documented way.
+
Maintenance is about who is allowed to work on your systems and how you keep that work from accidentally weakening security.

Plain-English overview

For CUI systems, you should plan maintenance windows, control remote tools used for support, and record what work was done. This prevents “stealth” changes and helps with troubleshooting later.

Key practices

  • Scheduled maintenance windows: Regular, predictable times for system updates and upgrades.
  • Controlled remote maintenance: Limit who can use remote tools (RDP, remote support tools) and how.
  • Maintenance logs: Capture who performed maintenance, what they changed, and whether it was successful.
Evidence examples:
  • Maintenance policy or SOPs.
  • Tickets documenting maintenance activities and approvals.
  • Configuration of remote support tools showing restricted access.
Media Protection (MP)
Protecting data when it leaves the screen.
+
Media protection covers USB drives, printed documents, backup tapes, exported files, and any other way CUI can be stored or moved.

Plain-English overview

You need rules and controls for how CUI is saved, transported, and destroyed. Without them, a lost laptop or USB drive can become a reportable incident.

Key practices

  • Control removable media: Decide when USB drives are allowed, how they are scanned, and how to prevent uncontrolled copying of CUI.
  • Protect media with CUI: Encrypt laptops, mobile devices, and external drives that store CUI. Lock them up when not in use.
  • Sanitize or destroy media: Use approved wiping or destruction methods (shredding, degaussing, physical destruction) for media that held CUI.
Evidence examples:
  • Written media protection policy.
  • Disk encryption configuration screenshots (e.g., BitLocker, FileVault).
  • Records of media disposal or certificates from shredding vendors.
Physical Protection (PE)
Doors, locks, badges, and visitor controls for CUI areas.
+
Physical security is often the simplest to understand but the easiest to overlook – especially in smaller offices or multi-tenant buildings.

Plain-English overview

You must control who can physically reach systems that handle CUI. This includes office doors, server rooms, wiring closets, and workstations that routinely access CUI.

Key practices

  • Control facility access: Locks, badge systems, keys, and visitor check-in procedures.
  • Escort and log visitors: Keep a visitor log and ensure guests are escorted in sensitive areas.
  • Secure workstations and ports: Position screens away from public view, use privacy screens where needed, and secure network ports in public areas.
Evidence examples:
  • Photos or diagrams of physical security controls (locked doors, badge readers).
  • Visitor log templates or electronic visitor records.
  • Policies or signage about visitor escort and restricted areas.
Personnel Security (PS)
Making sure the right people have access to CUI – and that access is removed when needed.
+
Personnel security connects HR processes with IT access control.

Plain-English overview

This domain is about screening people who will access CUI, making sure they understand their responsibilities, and quickly removing access when they leave or change roles.

Key practices

  • Screen personnel: Use background checks or similar methods allowed by law and contract.
  • Manage onboarding and offboarding: New hires get the right access; departing staff have access removed on or before their last day.
  • Define responsibilities: Job descriptions include any CUI-handling expectations.
Evidence examples:
  • HR procedures for background checks and onboarding/offboarding checklists.
  • Records showing timely account disablement for terminated employees.
  • Job descriptions that mention cybersecurity and CUI responsibilities.
Risk Assessment (RA)
Deciding which cybersecurity problems matter the most.
+
Risk assessment is how you decide where to spend time and money first.

Plain-English overview

CMMC expects you to periodically step back and ask: “What could go wrong with our CUI, how bad would it be, and how likely is it?” Then you decide which risks to address and how.

Key practices

  • Perform risk assessments: At least annually, list threats, vulnerabilities, and impacts related to CUI systems.
  • Consider changes: When you add new systems, move to the cloud, or change processes, revisit your risk picture.
  • Track risk treatment actions: Document which risks you are mitigating and how, along with timelines and owners.
Evidence examples:
  • Risk assessment reports or spreadsheets.
  • Meeting notes where risk decisions were made.
  • A risk register that tracks open risks and mitigation plans.
Security Assessment (CA)
Checking that your security program actually works.
+
Security assessment is about measuring yourself – finding gaps and proving that improvements are happening.

Plain-English overview

This domain covers internal and external assessments, handling findings, and keeping a Plan of Action and Milestones (POA&M) for gaps that are not yet fully closed.

Key practices

  • Assess controls: Perform self-assessments, gap analyses, or third-party reviews to see how you match up to CMMC requirements.
  • Remediate findings: Track issues found and make sure someone is responsible for fixing them.
  • Maintain a POA&M: Keep a living document listing gaps, planned fixes, owners, and dates.
Evidence examples:
  • Internal CMMC self-assessment results.
  • Penetration test or vulnerability assessment reports and remediation tickets.
  • Your POA&M document or tracking tool export.
System & Communications Protection (SC)
Protecting data on the wire and at system boundaries.
+
This domain looks at how your systems talk to each other and to the outside world – and how you prevent attackers from eavesdropping or sneaking in.

Plain-English overview

Think of SC as network hygiene: segmentation, encryption in transit, secure gateways, and controlled use of remote management protocols.

Key practices

  • Segment CUI systems: Place them on dedicated VLANs or network segments so they are not directly exposed to the whole corporate network.
  • Encrypt CUI in transit: Use TLS and VPNs to protect CUI whenever it crosses networks, including internal Wi-Fi.
  • Protect external connections: Use firewalls, web application security, and secure proxies for internet-facing services.
  • Control remote management protocols: Restrict RDP, SSH, and other protocols to trusted admins and secure jump hosts.
Evidence examples:
  • Network diagrams showing segmented CUI networks.
  • Firewall rule documentation and screenshots.
  • Configuration screenshots for VPN and TLS settings.
System & Information Integrity (SI)
Finding and fixing problems before they become incidents.
+
SI is about keeping systems healthy: patching, malware protection, monitoring, and detecting unauthorized changes.

Plain-English overview

CMMC expects you to deploy security tools, keep them updated, apply patches, and monitor for unusual or malicious activity that could affect CUI.

Key practices

  • Endpoint protection: Use anti-malware or endpoint detection and response (EDR) on CUI systems.
  • Patch management: Track and apply OS, application, and firmware patches on a defined schedule.
  • Alert monitoring: Configure tools to alert on suspicious events and make sure someone is responsible for reviewing them.
  • Integrity monitoring: Detect unauthorized changes to critical files, configurations, or applications.
Evidence examples:
  • Endpoint protection console screenshots and deployment reports.
  • Patch management reports showing compliance status for CUI systems.
  • Alert notification examples and related incident tickets.