# CMMCpedia This is the complete Markdown export of CMMCpedia, a reference for the CMMC Level 2 Requirements. It carries the Official Source Material for every published requirement with its Practitioner Guidance. It is generated from the same content as the site. Site: https://cmmcpedia.com/ ## Guidance chapters - Chapter 01: What is CMMC (https://cmmcpedia.com/guidance/what-is-cmmc/) - Chapter 02: CUI or FCI (https://cmmcpedia.com/guidance/cui-or-fci/) - Chapter 03: Which level applies (https://cmmcpedia.com/guidance/which-level-applies/) - Chapter 04: Drawing your boundary (https://cmmcpedia.com/guidance/drawing-your-boundary/) - Chapter 05: Reading a requirement (https://cmmcpedia.com/guidance/reading-a-requirement/) - Chapter 06: Assessing yourself (https://cmmcpedia.com/guidance/assessing-yourself/) - Chapter 07: Policy and your SSP (https://cmmcpedia.com/guidance/policy-and-your-ssp/) - Chapter 08: Implementing without overbuilding (https://cmmcpedia.com/guidance/implementing-without-overbuilding/) - Chapter 09: Gaps and your POA&M (https://cmmcpedia.com/guidance/gaps-and-your-poam/) - Chapter 10: What assessors ask for (https://cmmcpedia.com/guidance/what-assessors-ask-for/) - Chapter 11: Staying compliant (https://cmmcpedia.com/guidance/staying-compliant/) - Chapter 12: What it costs (https://cmmcpedia.com/guidance/what-it-costs/) ## Access Control (AC) ### AC.L2-3.1.1 Authorized Access Control Official Source Material: Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). Determine if: - [a] authorized users are identified; - [b] processes acting on behalf of authorized users are identified; - [c] devices (and other systems) authorized to connect to the system are identified; - [d] system access is limited to authorized users; - [e] system access is limited to processes acting on behalf of authorized users; and - [f] system access is limited to authorized devices (including other systems). Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Your directory is not your authorization list. Your directory is the service that holds user accounts, such as Microsoft Entra ID or Active Directory. An export from it shows who has access, not who is supposed to have it. An account an attacker creates would count as authorized by that logic. Objective [a] needs an authorization record kept outside the system itself. A spreadsheet is enough, with the person's name, the reason they need access, and the date the entry was last validated. Compare the directory against that list. The comparison is what shows access is limited under [d]. Cover all three populations: users, processes, and devices. Objectives [a] through [c] identify authorized users, processes acting on their behalf, and devices. [d] through [f] limit access to what was identified. Service accounts, the accounts that applications run under rather than people, are the population people miss. Inventory each one with what it does and the ticket or record that authorized it. Capture its permissions from the directory as the evidence for [b] and [e]. A web server running under its own account belongs on that inventory. Device authorization needs its own mechanism, not just user logon. For [c] and [f], keep a list of devices allowed to connect, and put something behind the list that enforces it. Conditional access, the sign-in rules in Microsoft Entra ID, can require a compliant or registered device. A firewall allowlist of MAC or IP addresses works too, as does port-based network authentication. A small organization can pair the device list with a recurring network scan. Compare what is on the network against what is approved, and remove anything that should not be there. Authorize in writing, before access is granted. An assessor cannot validate an approval given verbally in a meeting nobody documented. Tie every account and device to a request and an approval: a ticket, an email, or a signed row in the authorization list. The question each entry answers is how IT knew to create it in the first place. Write the system security plan by asset category, not per device. Your system security plan is the document that describes how your system meets each requirement. Describe how all laptops, all servers, and all security protection assets are limited, rather than writing an entry per machine. Per-asset write-ups produce redundancy without adding evidence. What falls short: - A Microsoft Entra ID or Active Directory user export offered as the list of authorized users. It shows current reality, not authorization, so it does not satisfy [a]. - Verbal authorization with no records. There is nothing for an assessor to examine, so [a] and [d] have no evidence. - A policy that says only approved devices may connect, with no allowlist, conditional access, or connection log review behind it. Nothing limits the connections, so [f] is not met. Edge cases: - Local accounts on domain-joined computers belong in the authorized user inventory. They are accounts on the system even though the directory does not manage them. - Accounts inherited from shared infrastructure are in scope. If several business units share one directory and only your enclave is assessed, a service account created elsewhere that can reach your systems is yours to identify and justify. - Devices belonging to external customers or agencies that connect to a service you expose are not entries on your device list under [f]. Handle them contractually: an attestation that the external party connects only from endpoints able to handle the data. - Keep this requirement distinct from IA.L2-3.5.2. AC.L2-3.1.1 is the list of who and what may access the system and the limiting of access to that list, and IA.L2-3.5.2 is verifying the identity of whoever shows up. Page: https://cmmcpedia.com/requirements/3-1-1/ ### AC.L2-3.1.2 Transaction & Function Control Official Source Material: Limit system access to the types of transactions and functions that authorized users are permitted to execute. Determine if: - [a] the types of transactions and functions that authorized users are permitted to execute are defined; and - [b] system access is limited to the defined types of transactions and functions for authorized users. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Objective [a] is a document you write, not a setting. List the user types in your system, such as standard user, administrator, and finance, and the transactions and functions each may execute. Create, read, update, and delete per system or application is the level of granularity the assessment guide uses. A one-page matrix satisfies [a]. Objective [b] is the enforcement of that matrix. Show the roles and groups that implement it: Microsoft 365 role assignments, file share permissions, application roles, or an application control tool. Present the configuration next to the matrix so the assessor can see that what is defined is what is enforced. You do not need a directory service to meet this. A four-person shop can use local Windows standard versus administrator accounts and application allowlisting, which blocks unapproved programs. Confine CUI, the controlled unclassified information your contract requires you to protect, to specific application accounts. Define the split and enforce it with what you have. An answer scaled to your size is enough. Personal use is yours to define, not yours to ban. Nothing in the requirement forbids web mail or music streaming on a NIST SP 800-171 system. What it requires is that you define the limits and keep personal applications and accounts away from CUI and official duties. A wide personal-use allowance creates work elsewhere, in CM.L2-3.4.7 for least functionality and AC.L2-3.1.20 for external connections. The more personal use you allow, the more you have to control elsewhere. AC.L2-3.1.1 covers who gets access. This requirement covers what they can do once they have it. Keep the two answers distinct in your system security plan. Account authorization and inventories live under AC.L2-3.1.1. This requirement is where you show that a proposal writer cannot reach developer tools and a developer cannot reach the HR database. What falls short: - Role assignments in an admin portal with no written definition of what each role is permitted to execute. Enforcement without a definition leaves [a] unmet. - A corporate-owned, personally enabled model where users install anything they like. Without a denylist, monitoring, and a clear line between personal and official use, access is not limited to defined transactions and functions under [b]. Edge cases: - A corporate-owned, personally enabled device policy is defensible when written deliberately: name the approved software and connections for official duties, keep personal accounts and apps away from official data, and record management's acceptance of the residual risk. It will draw questions across several requirements, so decide up front whether the convenience is worth the extra evidence you will have to produce. Page: https://cmmcpedia.com/requirements/3-1-2/ ### AC.L2-3.1.3 Control CUI Flow Official Source Material: Control the flow of CUI in accordance with approved authorizations. Determine if: - [a] information flow control policies are defined; - [b] methods and enforcement mechanisms for controlling the flow of CUI are defined; - [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified; - [d] authorizations for controlling the flow of CUI are defined; and - [e] approved authorizations for controlling the flow of CUI are enforced. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Flow control is about where CUI travels, not who may access it. CUI is the controlled unclassified information your contract requires you to protect. AC.L2-3.1.1 and AC.L2-3.1.2 govern access. This requirement asks you to name where CUI is allowed to move: between your enclave and the prime, between your sites, into and out of cloud services and subcontractors. You do not have to account for where all traffic goes, only where CUI goes, so there is no obligation to list every website your users visit. A data flow diagram carries objective [c]. Draw every place CUI enters, lives, and leaves, the systems it sits in, and the channels between them, with a short explanation of each source and destination. That one artifact answers [c], and the rest of the requirement refers back to it. Objectives [a], [b], and [d] call for a policy. [e] asks for proof. Write down how CUI is allowed to move, which methods and mechanisms enforce that movement, and who is authorized to move it. Then show the enforcement: access control lists on the CUI library, sharing restrictions, or a data loss prevention (DLP) rule. In a small shop, the signed policy and the training records that back it are the enforcement. Objective [e] is where the assessor checks that [a] through [d] are real. Policy plus training is a legitimate enforcement mechanism for a small organization. The assessment guide's own example meets the requirement with a written transmission policy, manager approval, encryption or a secure transfer utility for outbound CUI, and a disciplinary clause. As users, devices, and data volume grow, add technical enforcement such as sensitivity labels and DLP, because at scale a signature does not stop an upload. Do not block the internet to pass this. No objective requires blocking public web access, allowlisting inbound email senders, or banning personal email sites. Building an egress allowlist of every site your users may reach is a huge undertaking the requirement never asks for. Keep the controls pointed at the paths CUI actually takes. What falls short: - A policy that only covers sending CUI to the prime contractor. Internal flows and flows to subcontractors are also flows, so [c] and [d] are incomplete. - Policy-only enforcement in a large organization with many users, devices, and data paths. At that scale [e] needs technical enforcement behind the signatures. Edge cases: - When some of your CUI is export controlled, apply the strictest flow rules to the whole set rather than maintaining parallel flow regimes. - A DLP workflow that prompts senders for justification and notifies IT satisfies the enforcement leg. Keep the authorize, implement, and monitor roles with different people so the workflow does not collide with AC.L2-3.1.4. Page: https://cmmcpedia.com/requirements/3-1-3/ ### AC.L2-3.1.4 Separation of Duties Official Source Material: Separate the duties of individuals to reduce the risk of malevolent activity without collusion. Determine if: - [a] the duties of individuals requiring separation are defined; - [b] responsibilities for duties that require separation are assigned to separate individuals; and - [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: You define which duties require separation, so define ones you can execute. The requirement is silent on what must be separated, which hands you the power of definition. A general statement that duties are reasonably divided fails [a]. Name the specific pairs: change approval separated from change execution, log review separated from system administration, account creation separated from granting CUI access. CUI is the controlled unclassified information your contract requires you to protect. Never define a separation you cannot staff, because you will be assessed against your own definition. Separate authorizing, doing, and auditing. That three-way split is the pattern that satisfies [b] and [c] in nearly any structure. Whoever approves a change does not implement it, and whoever reviews the logs is not the only administrator generating them. The purpose is visibility, not prevention. Separation of duties does not stop a bad act so much as make it impossible to hide, because someone else sees the tracks. Aim the design at that: a second set of eyes on privileged activity beats an elaborate approval chain nobody follows. A two- or three-person company can meet this without hiring. Two administrators reviewing each other's activity meets the intent. Here is a three-person model that works. One person runs IT, a second approves changes, and a third reviews logs for everyone including the first. An outside consultant with even an hour a month of genuine log review creates real separation for the auditing leg. Assigned authority must be real. An assessor probes whether the person can exercise the duty, not just whether their name is on it. If the change approver says no and the change ships anyway, the separation exists on paper only. Show competence and authority: training records for the assigned duty, an example of a rejected change, log reviews signed by the reviewer. What falls short: - A single administrator who reviews their own logs with nobody checking the work. The duties in [b] and the privileges in [c] sit with one person. - Duties divided on paper among people who lack the access or the competence to perform them. The assignments in [b] are not matched by the privileges in [c], and the arrangement collapses in interviews. Edge cases: - A married couple or family business still needs formal separation. Cross-audit works only when each person genuinely cannot reach the other's domain, and long-standing trust is not a control. - Separate the ability to delete logs from the administrators being logged. Where the platform keeps logs unchangeable until retention expires, as Microsoft Entra ID sign-in and audit logs are, saying so in the system security plan strengthens the auditing leg at no cost. Page: https://cmmcpedia.com/requirements/3-1-4/ ### AC.L2-3.1.5 Least Privilege Official Source Material: Employ the principle of least privilege, including for specific security functions and privileged accounts. Determine if: - [a] privileged accounts are identified; - [b] access to privileged accounts is authorized in accordance with the principle of least privilege; - [c] security functions are identified; and - [d] access to security functions is authorized in accordance with the principle of least privilege. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Identify your privileged accounts before anything else. Objective [a] is a list, and every environment has entries for it because somebody runs the IT. Claiming there are no privileged accounts earns a Not Met. You may define the category narrowly, domain admins and global administrators for example, but the list must exist, be written down, and match reality. Give every administrator two accounts. A daily account with no elevation and a separate admin account used only for administrative work is the pattern that answers [b] at any size. In a three-person company, two accounts per administrator is enough. A third tier adds ceremony without adding compliance. Objective [c] wants your security functions named. Establishing accounts, configuring access authorizations, setting events to be logged, and tuning intrusion detection are the guide's examples. List which of these exist in your environment and which roles reach them. Objective [d] then follows: restrict each function to the few people whose job requires it, and record that authorization. Stop using the highest privilege for everything. Running routine endpoint work with a domain admin account is the principle of most privilege, and one piece of malware in that session reaches everything the account reaches. Scope the credential to the task. Use a local admin credential for endpoint installs and narrow Microsoft Entra ID roles instead of Global Administrator. Where the platform offers it, use Privileged Identity Management, which grants admin rights just in time and takes them back after. What falls short: - A system security plan asserting the organization has no privileged accounts. Objective [a] cannot be met by denial, because somebody administers the system. - Domain admin credentials used for day-to-day tasks that do not require them. Access is not authorized in accordance with least privilege, so [b] fails even though the accounts are identified. Edge cases: - Outsourced IT does not remove the requirement. Identify the elevated accounts your provider holds in your environment, document how they were authorized, and treat their administrators as yours for [a] and [b]. - Accounts on government systems such as DISS are not privileged accounts in your scope, because the test for [a] is whether the account enforces security policy on your systems. Your own tenant's global administrators qualify, and a certificate-based PKI logon to a government portal does not. Page: https://cmmcpedia.com/requirements/3-1-5/ ### AC.L2-3.1.6 Non-Privileged Account Use Official Source Material: Use non-privileged accounts or roles when accessing nonsecurity functions. Determine if: - [a] nonsecurity functions are identified; and - [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement is policy and habit, built on the account separation from AC.L2-3.1.5. AC.L2-3.1.7 technically blocks non-privileged users from privileged functions. This requirement points the other way: privileged people must use their non-privileged account for ordinary work. The implementation is a written rule, training that reinforces it, and the two-account pattern that makes following it possible. Define nonsecurity functions as everything that is not a security function. Objective [a] does not demand a second inventory. Identify your security functions under AC.L2-3.1.5, then state that all other functions are nonsecurity functions and must be accessed with non-privileged accounts or roles. Assessors accept that definition, and it stays correct as your systems change. The rule in one sentence: do not read email or browse the web from a privileged session. Put that sentence in the rules for administrators, train on it, and keep the acknowledgment. A compromised browser tab in an administrative context is the exact exposure this requirement exists to prevent, and it is the first thing an assessor asks administrators about in interviews. Elevation models count as roles. sudo on Linux and Privileged Identity Management in Microsoft Entra ID both fit the requirement: the user operates without privilege until a scoped, temporary elevation, then drops back. What fails is standing elevation, an account that carries administrator rights all day while being used for daily work. What falls short: - A daily-use account that holds permanent administrator rights. The user is never on a non-privileged account, so [b] cannot be met no matter what the policy says. - An unwritten understanding that administrators know better than to browse from admin accounts. Without a documented requirement and training there is no evidence for [b]. Edge cases: - Users in the sudo group are using a non-privileged role until the moment they elevate, so sudo satisfies the requirement as long as people are not running everything as root. Tighten the sudoers file to the commands each role needs. - Developers who need local admin can be kept out of the privileged population by definition, provided their local admin rights cannot touch security functions. Write that definition deliberately and be ready to defend it. Page: https://cmmcpedia.com/requirements/3-1-6/ ### AC.L2-3.1.7 Privileged Functions Official Source Material: Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. Determine if: - [a] privileged functions are defined; - [b] non-privileged users are defined; - [c] non-privileged users are prevented from executing privileged functions; and - [d] the execution of privileged functions is captured in audit logs. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define privileged functions as categories, not a command inventory. Objective [a] is satisfied by categories: establishing accounts, configuring access authorizations, setting events to be audited, patching, administering security tooling, and managing cryptographic keys. Enumerating every individual command produces an unmaintainable list and no additional compliance. Objective [b] is one sentence, and [c] is your standard user build. Define non-privileged users as everyone not on the privileged account list from AC.L2-3.1.5. Prevention under [c] is what a correctly configured standard account already does: no administrator rights, elevation prompts the user cannot satisfy, installs blocked. The evidence is the central configuration that builds those accounts, a group policy or a mobile device management profile, plus a demonstration that a standard user cannot execute an administrative action. Objective [d] asks for capture, not review. Configure logging so privileged operations land in the audit log, and be ready to say which events you capture and why. There is no mandated list of event IDs. A reasoned selection with a recorded rationale is sufficient. Keep the specific event IDs in your configuration baselines, not in policy, so the policy states the expectation and the baseline carries the detail. Reviewing what you captured belongs to the Audit and Accountability requirements, not here. Log privileged use even where prevention is airtight. Objective [d] covers the privileged users themselves, not just blocked attempts by everyone else. The guide's own example is an accidental privilege grant that surfaced only because privileged activity was being logged and an unexpected actor appeared in it. What falls short: - A circular definition such as privileged functions are whatever requires elevation. It restates the mechanism without defining the functions, so [a] is not answered. - An application whose administrative actions cannot be logged, kept in scope with no mitigation. Objective [d] is unmet, so close the gap or replace the application. Edge cases: - A developer workstation that stores, processes, and transmits no CUI, controlled unclassified information, sits outside the boundary this requirement is assessed against. Solve privileged function control on the in-scope assets first, and do not let an out-of-scope lab complicate the answer. - An application with a privileged web interface and no useful logging has three fixes. Have it sign users in through your directory so access is logged there, restrict the interface to named administrative hosts, or front it with an authenticating proxy that records who did what. Page: https://cmmcpedia.com/requirements/3-1-7/ ### AC.L2-3.1.8 Unsuccessful Logon Attempts Official Source Material: Limit unsuccessful logon attempts. Determine if: - [a] the means of limiting unsuccessful logon attempts is defined; and - [b] the defined means of limiting unsuccessful logon attempts is implemented. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Pick a threshold and a lockout behavior, write both down, and configure them. Objective [a] wants the means defined: after a set number of consecutive failures the account locks, either for a fixed period or until an administrator releases it. Objective [b] wants that exact configuration present in the system. The number is yours to choose. There is no mandated value, and fewer permitted attempts means higher security. Prefer a temporary lockout with automatic release. A lockout that releases after a delay blunts password guessing without turning failed logons into a denial of service or a standing help desk queue. The guide's own example pairs a three-attempt lockout with a thirty-minute automatic release and an administrator override. Reserve permanent lockout for accounts where the risk justifies the friction. Apply the limit at every logon surface. Workstations, VPN gateways, and your identity provider, the service that checks user sign-ins, each present a logon, and each needs the defined limit. Windows account lockout policy, Microsoft Entra ID smart lockout, and the failure limit on your VPN are all implementations of the same defined means. List each surface and its setting so [b] is demonstrable everywhere someone can type a password. Edge cases: - A platform in scope with no native lockout capability leaves a gap to close another way. Restrict access to it to your managed endpoints or network paths, let those layers carry the lockout, and document the arrangement as the defined means for that system. Page: https://cmmcpedia.com/requirements/3-1-8/ ### AC.L2-3.1.9 Privacy & Security Notices Official Source Material: Provide privacy and security notices consistent with applicable CUI rules. Determine if: - [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and - [b] privacy and security notices are displayed. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: A notice at initial logon carries this requirement. Display the notice where human users log on, at or before authentication. A notice on every application and system behind that first logon is a risk-based choice, not a requirement. The underlying discussion says a secondary notification is something you consider, not something you owe. One well-placed banner beats twenty inconsistent ones. Write your own text. Do not copy the DoD banner. The standard DoD banner speaks for U.S. Government information systems and never mentions CUI, the controlled unclassified information your contract requires you to protect. Yours is a private system that handles government information. Cover the essentials: use may be monitored and recorded, use constitutes consent, unauthorized use is prohibited and carries penalties, and the system may contain CUI to be handled per your policy. Have counsel review it, because the banner's function is legal notice, not decoration. A generic CUI statement is enough. Objective [a] ties notices to CUI-specified rules, and few categories impose special notice requirements. Stating that the system may contain CUI and pointing to your handling policy satisfies the association. You do not need to enumerate CUI categories in the banner. The display can take several forms. A logon banner, a desktop background carrying the notice, a Terms of Use acknowledgment enforced at sign-in through conditional access, or printed notices posted where no screen exists all satisfy [b]. Pick what each platform supports, keep a screenshot of each, and note in the system security plan which form covers which system. Edge cases: - Microsoft Entra ID caps the sign-in page text well short of a full banner. Use a shortened notice there and enforce a full Terms of Use document through conditional access, which also produces a per-user acceptance record. - Phones and tablets rarely display logon banners, and nobody reasonably expects them to. Where mobile devices are kept out of the CUI path, say so, and where they are in it, a device management enrollment notice referencing your CUI handling policy fills the gap. Page: https://cmmcpedia.com/requirements/3-1-9/ ### AC.L2-3.1.10 Session Lock Official Source Material: Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. Determine if: - [a] the period of inactivity after which the system initiates a session lock is defined; - [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and - [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define one number and let the operating system do the rest. Objective [a] is the inactivity period, written in policy. Fifteen minutes is a common choice, and the requirement sets no value. Enforce the OS lock at that number through group policy or Intune and [b] follows. Every mainstream lock screen hides the desktop behind an image, a clock, or a blank display, which is all the pattern-hiding [c] asks for. Just confirm the locked screen itself cannot show CUI, the controlled unclassified information your contract requires you to protect. Manage the setting centrally or prove users apply it themselves. Central enforcement removes the question. For any machine outside central management, you need a documented required setting, users told to apply it, and a way to verify they did. That is a harder story to tell than one Intune policy, which is the argument for central management. Web applications reachable from unmanaged devices need their own timeout. OS session lock protects the machine it runs on. If a portal that touches CUI can be reached from a device you do not manage, the application or a gateway in front of it must enforce its own inactivity timeout. You cannot vouch for the lock on a device you do not control. When access only happens from managed endpoints with enforced lock, the OS answer covers the application too. Session lock is not a substitute for logging off. Lock covers the walk-away case. It does not replace ending sessions under AC.L2-3.1.11. Where a platform cannot lock a session, terminating it is the right lever instead, and the two requirements together cover the unattended session from both ends. Edge cases: - A virtual machine used only locally is covered by the host operating system's session lock. Once the VM is remotely accessible the analysis changes: every endpoint that can reach it needs its own enforced lock, or the remote access goes away. - Lock screen notifications need obscuring only if their content can contain CUI. Email subjects and meeting titles from a CUI-bearing tenant justify hiding notification previews, and hiding everything everywhere is effort [c] does not ask for. Page: https://cmmcpedia.com/requirements/3-1-10/ ### AC.L2-3.1.11 Session Termination Official Source Material: Terminate (automatically) a user session after a defined condition. Determine if: - [a] conditions requiring a user session to terminate are defined; and - [b] a user session is automatically terminated after any of the defined conditions occur. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define termination conditions you can actually execute. Objective [a] leaves the conditions to you: user logoff, account disablement, a scheduled restart, a policy violation, a time-of-day cutoff. NIST SP 800-171 Revision 2 mandates no inactivity timeout for this requirement. Choose conditions your systems genuinely enforce and write them in the system security plan, because [b] is assessed against your own definition. Simple definitions are defensible. One complete answer defines two conditions: sessions end when the user logs off and when the account is disabled. A weekly forced restart is another: it terminates every session on a schedule and doubles as update hygiene. The trap is not modesty. It is defining a condition, such as a nightly logoff script, that turns out not to run everywhere you claimed. This is the logical session, not the network connection. SC.L2-3.13.9 handles terminating network connections. A VPN client disconnecting after twelve hours is a network event. This requirement is about ending the user's logical session, the thing that logoff, disablement, and restart end. Keeping the two straight avoids answering the wrong requirement with the right evidence. Do not punish users with aggressive idle logoffs. A short idle logoff on ordinary workstations disrupts work without a compliance payoff, since the requirement names no timeout. Save tight idle termination for virtual desktops (VDI), shared machines, and high-exposure systems where it earns its cost. Edge cases: - NIST SP 800-171 Revision 3 makes the inactivity trigger an organization-defined parameter, and DoD's parameter selections cap it at 24 hours for this requirement. Assessments under Revision 2 do not apply it, but where adopting an inactivity condition costs you nothing, choosing one inside that bound saves rework later. Page: https://cmmcpedia.com/requirements/3-1-11/ ### AC.L2-3.1.12 Control Remote Access Official Source Material: Monitor and control remote access sessions. Determine if: - [a] remote access sessions are permitted; - [b] the types of permitted remote access are identified; - [c] remote access sessions are controlled; and - [d] remote access sessions are monitored. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Answer four questions in one policy. Objective [a] asks whether remote access is permitted. Objective [b] asks which types: VPN, access to cloud services over the internet, vendor support sessions. Objective [c] asks how each is controlled: managed devices only, multifactor authentication, conditional access, device health checks at connection. Objective [d] asks how each is monitored: which logs exist, who reviews them, how often. That document, with the configurations and review records behind it, is the whole requirement. Define what counts as remote in your environment and defend it in writing. Whether an established VPN session from a company-owned laptop is still remote access has no settled answer among assessors. Take the durable position. The tunnel is a type of permitted remote access, so list it under [b], then control and monitor it. If you then treat traffic inside the established tunnel as internal, document that treatment and its rationale. The requirement's own discussion says encrypted VPNs do not make access non-remote. They let you treat the connection like an internal network once controlled. Cloud access is remote access for this requirement. Sessions to Microsoft 365 or any internet-reached service matter when those services hold CUI, the controlled unclassified information your contract requires you to protect. TLS, the standard encryption on web connections, plus conditional access policies requiring compliant devices are your [c]. The identity provider's sign-in logs and their review are your [d]. A fully cloud organization with no office still has types to identify under [b]: name the TLS access paths and the gateway or conditional access layer that fronts them. Monitoring means a person looks at the logs. Collection is not monitoring. Write the review procedure for VPN and sign-in logs. Run it at a frequency matched to your risk. Keep the artifacts: a ticket closing the review, an alert and its disposition, an email summarizing findings. An assessor asks for the procedure and then asks for proof it ran. No CUI over the remote link does not scope this requirement out. Remote access used for system maintenance is still remote access to an in-scope system, and the requirement applies. The only way to scope it out is to prevent remote access entirely and have the policy and configuration that prove it. What falls short: - A system security plan claiming no remote access while staff connect by VPN or reach cloud services from home. The types in [b] go unidentified, and nothing can satisfy [c] or [d] for sessions the plan says do not exist. - Logs collected with no review procedure and no records of review. Collection alone leaves [d] unmet. Edge cases: - A site-to-site VPN between your own offices is an extension of the network, not a remote access session. The on-demand tunnel from a user's laptop is one. - Attended support tools such as Quick Assist are remote access when the operator connects from outside your boundary. Route vendor and managed service provider (MSP) support through an approved, monitored path instead of whatever tool the technician prefers. Page: https://cmmcpedia.com/requirements/3-1-12/ ### AC.L2-3.1.13 Remote Access Confidentiality Official Source Material: Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. Determine if: - [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and - [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Name the mechanism for every remote path, then show it running. Objective [a] is the specific cryptography protecting each type of remote access you permitted under AC.L2-3.1.12: TLS on the VPN, TLS to each cloud service, SSH for administrative sessions. Objective [b] is the configuration evidence. Map each permitted type to its mechanism so no path is left uncovered, and the two objectives fall out of one table. Sessions that carry CUI need a FIPS-validated module, not just an approved algorithm. CUI is the controlled unclassified information your contract requires you to protect. The assessment guide is explicit that an approved algorithm alone is not sufficient. The module implementing it must be validated under FIPS 140, the federal standard for cryptographic modules. The validation requirement itself is SC.L2-3.13.11 territory. What belongs here is the mapping: which validated module protects each remote path over which CUI travels. One validated layer is enough when encryption stacks. A FIPS-mode TLS session riding inside a VPN whose own encryption is not validated still protects the session, because one layer end to end is validated. Decide which layer is your validated layer for each CUI-bearing path and write it down, rather than trying to make every layer validated at once. A FedRAMP-authorized service can be the validated layer. FedRAMP is the federal cloud authorization program. When every CUI flow ends in GCC High, the government cloud version of Microsoft 365, or another service that provides FIPS-validated TLS, that service carries the cryptographic burden for those flows. Your VPN does not need to be FIPS for them. Confirm the coverage against your data flow work from AC.L2-3.1.3 before relying on it, because one overlooked CUI path to a file server changes the answer. A policy forbidding remote CUI access does not remove this requirement. The requirement protects remote access sessions, and sessions used for administration expose credentials and security-relevant configuration even when no CUI crosses them. Encrypt every remote session. Reserve the FIPS-validation question for the sessions that carry CUI. What falls short: - A remote desktop (RDP) session from a personal device directly to an in-scope machine, with no restrictions on the session. Unless the session host confines the client to keyboard, video, and mouse, the personal device enters the assessment scope and the unmanaged path defeats the mechanism claimed under [b]. Edge cases: - An endpoint running a virtual desktop (VDI) client that allows nothing beyond keyboard, video, and mouse is out of scope under the CMMC scoping rule. The cryptographic burden sits on the in-scope side of that connection. - Administrative remote sessions that touch no CUI still need encryption under this requirement, and audit records showing no CUI was accessed are what make that boundary defensible. Page: https://cmmcpedia.com/requirements/3-1-13/ ### AC.L2-3.1.14 Remote Access Routing Official Source Material: Route remote access via managed access control points. Determine if: - [a] managed access control points are identified and implemented; and - [b] remote access is routed through managed network access control points. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Funnel every remote path through a small number of points you manage. Objective [a] asks you to identify and implement the control points. [b] asks you to show that all remote access actually routes through them. A VPN concentrator, the device that terminates every VPN connection, behind the firewall is the classic answer: one auditable door instead of a dozen ad hoc paths. That simplifies both monitoring under AC.L2-3.1.12 and this requirement's evidence. Cloud-only environments already have the control point. Conditional access in Microsoft Entra ID is a gate every session passes through: it decides who connects, from which devices, under which conditions, and it logs the decision. Document it as your managed access control point. You do not need to bolt a VPN onto a cloud-native architecture to satisfy this requirement. A network diagram is the cleanest evidence. Mark each access control point and show that no remote path bypasses them. For a hybrid shop that is the VPN gateway for network access and the conditional access layer for cloud services, on one page. A managed point does more than pass traffic. Managed means the point enforces policy and leaves a record: it authenticates against your identity provider, logs connections into your log tooling, and applies inspection or health checks where feasible. A port forward on an unmanaged router is a hole, not an access control point. Edge cases: - A managed service provider (MSP) remotely managing individual endpoints with an agent-based tool is administering specific machines, not entering your network through a path you route. Document the tool and its controls under AC.L2-3.1.12 and AC.L2-3.1.15, and keep this requirement's evidence focused on the paths into your system. Page: https://cmmcpedia.com/requirements/3-1-14/ ### AC.L2-3.1.15 Privileged Remote Access Official Source Material: Authorize remote execution of privileged commands and remote access to security-relevant information. Determine if: - [a] privileged commands authorized for remote execution are identified; - [b] security-relevant information authorized to be accessed remotely is identified; - [c] the execution of the identified privileged commands via remote access is authorized; and - [d] access to the identified security-relevant information via remote access is authorized. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement governs remote administration, and it is answered with authorization lists. Identify which privileged commands may be executed remotely [a] and which security-relevant information may be reached remotely [b], then show both are authorized [c] and [d]. If administrators can do administrative work from outside the boundary, write down what they may do, from where, and under whose approval. Avoiding remote privilege entirely is the strongest position. Where the business needs it, the documentation is the control. Authorize by role, not by command inventory. Enumerating individual commands produces a list nobody can maintain. State instead that the commands granted by your named administrator roles in Microsoft Entra ID or Active Directory are authorized for remote execution by the people holding those roles. An assessor who wants the command list gets the role definitions that bound it, a better answer than a stale spreadsheet. If privilege requires being inside the boundary first, say exactly that. A clean posture for VPN-centric environments: no privileged commands are authorized for remote execution. Administrators must first establish an approved remote access session under AC.L2-3.1.12 and AC.L2-3.1.14, and administration then happens inside the controlled boundary. Write it that way in the system security plan and enforce it. The statement converts four objectives into one architectural fact. Inventory your remote execution vectors. Intune script deployment, remote monitoring and management (RMM) agents, PowerShell remoting, SSH, and patch management platforms all execute privileged commands on machines the operator is not sitting at. Each belongs under [a] with its authorized operators under [c]. These vectors are easy to forget precisely because they are routine. Security-relevant information is yours to define. Audit log configuration, security tool settings, firewall rule sets, and access control configuration are the core of it. Name what qualifies in your environment and who may reach it remotely, and [b] and [d] are complete. Browsing an admin portal from home is remote access to security-relevant information, so cover it with the same role-based authorization and conditional access controls. Edge cases: - In a fully cloud environment every administrative action crosses the internet, so there is no non-remote administration to retreat to. The role-based authorization statement, enforced by conditional access from managed devices, is the fitting answer for [c] and [d]. - Solve AC.L2-3.1.12 through AC.L2-3.1.15 as one design rather than four documents. They describe the same remote access architecture from four angles, and a system security plan that tells one coherent story assesses better than four disconnected answers. Page: https://cmmcpedia.com/requirements/3-1-15/ ### AC.L2-3.1.16 Wireless Access Authorization Official Source Material: Authorize wireless access prior to allowing such connections. Determine if: - [a] wireless access points are identified; and - [b] wireless access is authorized prior to allowing such connections. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Objective [a] is an inventory and [b] is an approval gate in front of it. List the wireless access points and networks in scope, and require authorization before any user or device connects. Policy names who approves and what qualifies, and configuration enforces it. The pairing to show an assessor is the current access point list next to the mechanism that keeps unapproved devices off. WPA2 with a pre-shared key, one WiFi password shared by everyone, clears this requirement. Authentication and encryption at the access point are what matter here. Certificate-based onboarding and 802.1X, the per-user network logon standard, are stronger and serve IA.L2-3.5.2 well. They are not the bar for AC.L2-3.1.16, and building a RADIUS authentication server solely for this requirement is effort spent past the objective. Provision the key so users never learn it. IT joins devices to the wireless during setup, or the device management platform pushes the WiFi profile. Authorization and connection then become the same controlled event, and the pre-shared key stops circulating on whiteboards. Rotate a shared key whenever someone who knows it leaves, which is also the reason larger teams outgrow shared keys. No wireless does not mean not applicable. If wireless is disabled or was never deployed, write the requirement as met: policy prohibits wireless access and configuration enforces the prohibition. That answer is verifiable. A not-applicable claim invites a scoping argument you do not need. Edge cases: - A guest network with no path into in-scope systems is not a wireless access point to your system. Keep it segmented and say so. - A laptop on hotel or home WiFi is not connecting to your wireless, and is instead using external wireless as transport into your remote access controls. That scenario is governed by AC.L2-3.1.12 through AC.L2-3.1.14, and the tunnel or TLS session carries the protection. Page: https://cmmcpedia.com/requirements/3-1-16/ ### AC.L2-3.1.17 Wireless Access Protection Official Source Material: Protect wireless access using authentication and encryption. Determine if: - [a] wireless access to the system is protected using authentication; and - [b] wireless access to the system is protected using encryption. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: One configuration answers both objectives. WPA2 or WPA3 gives you authentication [a] through the key or enterprise logon and encryption [b] through AES in the same setting. Never run an open network in scope. Open authentication admits anyone and fails [a] outright. Match the authentication mechanism to your size. A pre-shared key works for a small, stable team, with rotation on every departure. WPA2 or WPA3 Enterprise against a RADIUS authentication server authenticates each user or device individually and scales past the point where a shared secret is manageable. Both are acceptable. Pick the one you will operate correctly. Decide which layer protects CUI that crosses the air. CUI is the controlled unclassified information your contract requires you to protect. Wireless traffic leaves your boundary, so CUI crossing it needs FIPS-validated encryption at some layer of the stack. If every CUI flow already rides a validated layer higher up, a FIPS-mode VPN or TLS to a FedRAMP-authorized service, the WiFi is transport and does not carry the CUI burden. If the wireless link is the only encryption between a laptop and a CUI file share, the WiFi inherits the FIPS question, and consumer-grade access points do not answer it. Trace your CUI data flows before deciding which case you are in. SC.L2-3.13.11 governs the validation itself. Enterprise authentication does not answer the encryption question. EAP-TLS, the certificate-based enterprise logon, strengthens how session keys are established, not the validation status of the encryption modules. Treat [a] and [b] as separate accounts: strong authentication on one side, and a deliberate answer on the other for where validated encryption lives. What falls short: - A consumer or small-business access point as the only encryption layer for CUI reaching an internal file server. The wireless link is then responsible for CUI confidentiality without a validated module, which fails [b] as assessed against the guide's FIPS discussion. Edge cases: - An environment with no wireless at all writes this as met by prohibition and configuration, mirroring AC.L2-3.1.16, rather than claiming not applicable. - Remote workers on home WiFi reaching only a FedRAMP-authorized cloud service are covered by that service's validated TLS. Their home access points are outside your boundary and outside this requirement. Page: https://cmmcpedia.com/requirements/3-1-17/ ### AC.L2-3.1.18 Mobile Device Connection Official Source Material: Control connection of mobile devices. Determine if: - [a] mobile devices that process, store, or transmit CUI are identified; - [b] mobile device connections are authorized; and - [c] mobile device connections are monitored and logged. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Settle the definition first: phones and tablets, not laptops. The guide defines a mobile device by small form factor, wireless operation, on-board storage, and a self-contained power source, and its examples are smart phones, e-readers, and tablets. Laptops are mobile computing platforms, addressed by AC.L2-3.1.19. An assessor may still ask about laptops here. Answer from the definition, and show laptops handled under the requirements that do govern them. The three objectives are a list, a gate, and a log. CUI is the controlled unclassified information your contract requires you to protect. Identify which mobile devices process, store, or transmit CUI [a], authorize connections before they happen [b], and monitor and log them [c]. A mobile device management or mobile application management platform delivers all three at once: enrollment is the identification and the authorization gate, and the console provides the monitoring and logging. Assign each device an identifier so the log entries tie back to the inventory. Application-level management works for bring-your-own-device. App protection policies through Intune contain CUI inside managed applications on personal phones. The container is policy-controlled, connections are authorized per app, and the platform logs them. Run the pattern from the tenant that matches your data. It satisfies the objectives from a GCC or GCC High tenant, and the personal device around the container stays out of the CUI boundary. Prohibition is a valid answer written as met, not as not applicable. Blocking mobile devices entirely satisfies the requirement when conditional access, the sign-in rules in your tenant, actually enforces the block. Describe the enforcement in the system security plan. A not-applicable claim asserts the situation cannot arise, which is not true of a policy that a phone can violate. A phone that holds CUI is a CUI asset. Management software does not demote it to a lesser asset category. If the device itself stores or processes CUI, it carries a CUI asset's obligations, which is the argument for containing CUI inside managed apps or keeping it off phones entirely. What falls short: - A written prohibition on mobile access with nothing enforcing it. Conditional access that still permits unmanaged phone connections leaves [b] unmet regardless of the policy. - Marking the requirement not applicable because mobile devices are prohibited. The prohibition is how [b] is met, so describe and evidence it as the authorization decision instead of claiming the requirement away. Edge cases: - Routing CUI-bearing mail to a dedicated address that phones cannot reach can take phones out of scope, but only when the restriction is technically enforced. A rule that relies on everyone following it fails the first time someone does not. Page: https://cmmcpedia.com/requirements/3-1-18/ ### AC.L2-3.1.19 Encrypt CUI on Mobile Official Source Material: Encrypt CUI on mobile devices and mobile computing platforms. Determine if: - [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and - [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The requirement names two device classes. Cover both. Mobile devices are phones and tablets. Mobile computing platforms are laptops. CUI is the controlled unclassified information your contract requires you to protect. Objective [a] is one inventory of everything in either class that processes, stores, or transmits CUI, and [b] is encryption on every entry. The phone-and-tablet list from AC.L2-3.1.18 plus your laptop inventory is the starting point. Laptops get full-disk encryption with escrowed keys. BitLocker or FileVault on every in-scope laptop, with recovery keys escrowed, stored centrally through Intune or your directory, covers [b]. It produces its own evidence, because the escrow report is the encryption status list. Run the platform in FIPS mode where the guide's discussion applies, and leave the module validation details to SC.L2-3.13.11. Linux laptops need full-disk encryption chosen at build time, because retrofitting practically means reinstalling. Plan for it rather than discovering it during remediation. Phones and tablets get container or full-device encryption. App protection policies encrypt CUI inside managed applications, which is the practical answer for personal devices. Full-device encryption enforced by the device management platform is the alternative for corporate-owned devices. Either way the enforcement policy, exported from the console, is the evidence for [b]. A laptop that never leaves the building is still a mobile computing platform. The guide's own example encrypts all laptops with the operating system's full-disk encryption. Arguing that a docked laptop is really a desktop invites a finding and saves nothing, because the encryption it would exempt costs nothing to enable. Devices with no path to CUI are outside this requirement's inventory. When policy keeps CUI off a class of devices and no access path exists, those devices do not belong on the [a] list. No CUI mailbox, no SharePoint access, and no file sync means no path. You do not have to armor those devices against a spillage that is not your fault. Be ready to demonstrate the absence of the path, because the claim is only as good as its enforcement. Edge cases: - Devices excluded from scope by policy alone sit in a gray zone, because an assessor may treat any that connect to the system as risk-managed assets needing documented handling. Add a technical barrier, such as conditional access blocking the class, to make the exclusion hold. Page: https://cmmcpedia.com/requirements/3-1-19/ ### AC.L2-3.1.20 External Connections Official Source Material: Verify and control/limit connections to and use of external systems. Determine if: - [a] connections to external systems are identified; - [b] the use of external systems is identified; - [c] connections to external systems are verified; - [d] the use of external systems is verified; - [e] connections to external systems are controlled/limited; and - [f] the use of external systems is controlled/limited. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement can never sit on a POA&M. A POA&M is the plan of action that buys time for unfinished requirements, and 32 CFR 170.21(a)(2)(iii) excludes AC.L2-3.1.20 from Level 2 plans of action. A Not Met here blocks even a Conditional CMMC Status, regardless of your overall score. Treat it as day-one work, not cleanup. Scope the list to systems that matter, not the whole internet. Read literally, [a] could mean every connection from every system. Do not take the bait. The list that answers [a] and [b] has two parts. The first is the external services that receive your CUI or FCI. CUI is the controlled unclassified information your contract requires you to protect. FCI is the non-public information the government provides, or you generate for it, under your contract. The second is the connections that allow access back into your environment. Your cloud suite, file transfer services, a managed service provider's (MSP) tooling, and government portals are the usual entries. A dozen well-described entries is a normal answer. Hundreds of websites is a wrong turn that makes every later objective unmanageable. Verification is recorded trust, per connection. For [c] and [d], record why each listed system is fit for what you use it for. FedRAMP is the federal cloud authorization program. A cloud service's FedRAMP authorization and package identifier, the contract terms for a partner connection, or the configuration showing only expected devices connect all serve. A policy stating which systems are approved for FCI and CUI, paired against the list, is the verification of use. Control and limit with the firewall and the policy together. Objectives [e] and [f] split along the same line: firewall rules and content filtering control the connections, and a policy naming the approved systems and prohibiting all others limits the use. Remote laptops are the leak in this design, because their traffic can bypass the firewall. An always-on VPN or enforced endpoint firewall rules brings them back inside the controls. Personal devices are external systems. A personal phone or home computer touching company services is exactly what this requirement governs. Either block them or bring them under defined terms and verification. Conditional access that refuses unmanaged devices is the cleanest enforcement, because it makes the limit self-executing. External can mean your own other network. A lab, a commercial business unit, or any system outside the assessment scope is an external system from the enclave's perspective, even though your company owns it. Connections between the enclave and those environments belong on the list with the same verify-and-limit treatment as any vendor. What falls short: - A multifactor authentication product offered as evidence of external connection control. It authenticates access to your own systems and says nothing about connections to external ones, so it answers none of [a] through [f]. - Open egress plus unmanaged personal-device use with no external system list and no policy. Nothing is identified under [a] and [b], so nothing downstream can be verified, controlled, or limited. Edge cases: - Routine business websites such as banks are not the focus, because nothing there reaches back into your system and no CUI flows to them. Note the reasoning once rather than inventorying the web. - Government-operated destinations can be grouped: a single entry covering .mil and .gov services such as DoD SAFE keeps the list honest without itemizing every portal. Page: https://cmmcpedia.com/requirements/3-1-20/ ### AC.L2-3.1.21 Portable Storage Use Official Source Material: Limit use of portable storage devices on external systems. Determine if: - [a] the use of portable storage devices containing CUI on external systems is identified and documented; - [b] limits on the use of portable storage devices containing CUI on external systems are defined; and - [c] the use of portable storage devices containing CUI on external systems is limited as defined. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The scenario is your CUI thumb drive in somebody else's computer. CUI is the controlled unclassified information your contract requires you to protect. External systems are the ones outside your control: hotel kiosks, personal machines, another company's laptops, and even systems inside your own company that sit outside the CUI boundary. The three objectives ask you to decide whether that use happens at all [a], set the limits [b], and keep to them [c]. Policy and training are the accepted mechanism. No technical agent of yours runs on an external system, so administrative control is the honest answer: a written rule, training against it, and a signed acknowledgment. The simplest defensible limit is a prohibition: portable storage devices containing CUI are never used on external systems. If you prohibit, [a] and [b] are one sentence each and [c] is the training record. If you allow it at all, run a check-out process. Issue company-owned encrypted drives from IT for a named purpose, restrict them to named systems, and log them out and back in. The log is the identification and documentation [a] asks for, and the issuance conditions are the limits under [b]. Encryption does not answer this requirement. An encrypted drive protects the data if the drive is lost. It does nothing to limit where the drive is used, and an authorized user can still unlock it on a personal machine. Device encryption lives in the Media Protection family. The limit here is about where, and it is behavioral. Edge cases: - Device-binding tools exist that let a drive unlock only on systems you manage, turning the written limit into a technical one. They strengthen [c] but are not required, because assessments accept the policy-and-training answer. Page: https://cmmcpedia.com/requirements/3-1-21/ ### AC.L2-3.1.22 Control Public Information Official Source Material: Control information posted or processed on publicly accessible information systems. Determine if: - [a] individuals authorized to post or process information on publicly accessible systems are identified; - [b] procedures to ensure FCI is not posted or processed on publicly accessible systems are identified; - [c] a review process is in place prior to posting of any content to publicly accessible systems; - [d] content on publicly accessible systems is reviewed to ensure that it does not include FCI; and - [e] mechanisms are in place to remove and address improper posting of FCI. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement can never sit on a POA&M. A POA&M is the plan of action that buys time for unfinished requirements, and 32 CFR 170.21(a)(2)(iii) excludes AC.L2-3.1.22 from Level 2 plans of action. A missing review process blocks even a Conditional CMMC Status. The good news is that this is among the cheapest requirements in the family to meet. An hour of procedure writing covers four of the five objectives. Name who may post to the website and official social media [a]. Write the procedure that keeps CUI and FCI out of public systems [b]. CUI is the controlled unclassified information your contract requires you to protect. FCI is the non-public information the government provides, or you generate for it, under your contract. Require review before anything is posted [c], and define how improper postings get removed and reported [e]. One page in your media or acceptable use policy is a complete answer, and write it to cover CUI as well as the FCI the objectives name. Objective [d] needs a recurring review of what is already public. Pre-posting review alone does not answer it. Review the live site on a defined schedule, and record who reviewed and when. A dated sign-off in a spreadsheet is adequate. An annual review is a defensible floor for a static site. A change-detection alert that triggers review of modified pages is a sound supplement, not a substitute for the pre-posting step. Company channels are in scope. Personal ones are not. The company website and official social media accounts get the authorization and review process. Employees' personal accounts are not subject to pre-publication review, and no objective requires monitoring them. An employee posting FCI from a personal account is an incident to handle under [e] and a training matter under AT.L2-3.2.1, not a gap in this requirement. What falls short: - Policies and procedures with no recorded review of the live site. Objective [d] wants evidence the public content was actually checked, and the absence of records reads as absence of review. - Post-publication monitoring alone. Objective [c] requires review before posting, so change alerts without a pre-posting step leave [c] unmet. Edge cases: - In a very small company the same person may end up posting and reviewing. Assessors differ on whether that passes, so separate the two roles whenever a second person exists, and where one truly does not, document the compensating check. - A website hosted by a third party is still yours for this requirement. The control is procedural, not technical, so wherever your organization can publish content, the authorization and review process applies. Page: https://cmmcpedia.com/requirements/3-1-22/ ## Awareness and Training (AT) ### AT.L2-3.2.1 Role-Based Risk Awareness Official Source Material: Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems. Determine if: - [a] security risks associated with organizational activities involving CUI are identified; - [b] policies, standards, and procedures related to the security of the system are identified; - [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and - [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Generic government awareness training does not satisfy this requirement on its own. Objectives [b] and [d] are about your policies, standards, and procedures. A stock DoD Cyber Awareness module says nothing about where your CUI (Controlled Unclassified Information) lives, who your security contact is, or which documents govern your system. Use the stock module if you already own it, then add the part that is about your organization. Objectives [a] and [b] are documents, not training. Two of the four objectives are satisfied before anyone sits in a session. Write down the security risks tied to your CUI activities. List the policies, standards, and procedures people must follow, and where each one lives. Skip these and you fail [a] and [b] no matter how good the training is. Attendance records prove delivery, not awareness. A completion report shows a person opened the module. Pair it with the material itself and with an acknowledgment that names what was covered. A signed acceptable use policy, a signed handbook, a terms of use consent recorded by your identity provider, or an email requiring an affirmative reply all work. An assessor who interviews a user and hears them name the policy and where to find it has evidence for [d]. Serve all three audiences the requirement names. Managers, system administrators, and users are called out separately in [c] and [d]. Administrators hold the most risk and get the least tailored material. If one deck serves everyone, say how it addresses each audience, or write a short supplement for administrators. Do not build a learning management system for this. A slide deck, a sign-in sheet, and a dated acknowledgment cover all four objectives. Three slides are enough if they say where the policies live, who the security contact is, and what the reader is signing. Buy a platform when headcount makes tracking hard, not before. Repeat it annually. The objectives say people are made aware. They do not name a frequency. One session at hire is defensible on the text and weak in practice, because policies change and people forget. An annual refresher with a fresh acknowledgment removes the question. What falls short: - The DoD CUI or Cyber Awareness module on its own. It cannot cover your policies, standards, and procedures, so it cannot meet [b] or [d]. - An email that tells people to read the policy, with no acknowledgment. Nothing shows anyone was made aware, so [c] and [d] have no evidence. - A statement signed by the IT department on everyone's behalf. IT cannot direct every employee, so it does not show that each person was made aware under [c] and [d]. The acknowledgment has to come from each person. - Training that never names your security contact or says where the governing documents live. It misses [d]. Edge cases: - Contractors and part-time staff are users if they touch the system, because the requirement says users of organizational systems, not employees. A fractional IT provider who administers your environment is an administrator under [c] and needs the same awareness content, or proof that you reviewed theirs. - Staff who only use government furnished equipment covered by the government's own system security plan get their awareness training from the government, not from you. A person who also holds an account on your system is in scope for your system. - You do not need a separate document called a standard, even though objective [b] names policies, standards, and procedures. Standard-type content can live in your system security plan or in your procedures, as long as you can list which documents govern the system. Page: https://cmmcpedia.com/requirements/3-2-1/ ### AT.L2-3.2.2 Role-Based Training Official Source Material: Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities. Determine if: - [a] information security-related duties, roles, and responsibilities are defined; - [b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and - [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: You define what the training is, and certifications are not required. The requirement leaves the content to you. Vendor courses, conference sessions, a college class, or a written walkthrough of your own procedures all qualify, as long as they match the duty. So do the free modules from CDSE, the Defense Department's Center for Development of Security Excellence. For a small shop with no certified staff, name the vendor course for each system and record when it was completed. The three objectives are a sequence: define, assign, track. Objective [a] asks you to write down the security duties each role carries. Objective [b] asks you to tell named people that those duties are theirs. Objective [c] asks you to show they were trained for them. Do them in that order, because [b] and [c] have nothing to point at until [a] exists. A role list can be three lines. Person A administers the domain, the firewall, the VPN, and the GCC High tenant, the government cloud version of Microsoft 365. Person B reviews logs and manages backups. Both hold the incident response role. Point each line at the policy, the procedure, and the training material for that duty, and have each person sign that they received them. General awareness training does not cover this requirement. AT.L2-3.2.1 covers what every user needs. This requirement covers the duties that only some people hold: administration, log review, incident handling, backup, and physical security. If your only training is the all-hands module, you have no evidence for [c]. Keep the completion evidence simple and dated. A PDF certificate, an email that says the course is done, a spreadsheet with material, person, and date, or an export from a learning system all work. The objectives ask whether people are trained, not whether a certificate exists. A record that ties a person to a duty, to a piece of training, and to a date is still the fastest way to answer [c]. What falls short: - The all-hands awareness module as the only training for the people who administer the system. It shows nothing for [c]. - The DoD mandatory CUI (Controlled Unclassified Information) training alone. It does not say who to report an incident to in your organization, or how CUI is handled in your environment. It trains no one for the duties in [a]. - Hiring practices offered as training evidence. A stack of resumes shows who you hired, not what they were trained to do, and [c] asks for the training. Edge cases: - Janitorial and other facility staff are outside this requirement when your scoping keeps CUI out of their reach through clean desk rules, locked server rooms, and encrypted endpoints in a locked state. Badges, tailgating, and unlocked screens then belong in awareness training under AT.L2-3.2.1. - When unescorted facility staff could come across CUI in trash, printer rooms, or on unlocked screens, treat handling that exposure as an information security duty and train them for it. Page: https://cmmcpedia.com/requirements/3-2-2/ ### AT.L2-3.2.3 Insider Threat Awareness Official Source Material: Provide security awareness training on recognizing and reporting potential indicators of insider threat. Determine if: - [a] potential indicators associated with insider threats are identified; and - [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The free CDSE course carries this requirement. Insider Threat Awareness, course INT101 from the Center for Development of Security Excellence, is built for exactly this requirement. Assign it, keep the completion record, and most of the work is done. Unlike AT.L2-3.2.1, this requirement has no organization-specific policy component, so generic government training can carry it. Train on this annually. The requirement text names no frequency. The CMMC rule at 32 CFR 170.4 defines periodically as at least annually, and assessors apply that reading here. A single session at hire earns a Not Met. Add the reporting path. The course tells people what an indicator looks like. Your training has to tell them who to report it to in your organization. One slide or one paragraph with the name and the channel is enough, and it is the one part the generic course cannot supply. Do not agonize over the list of indicators. The objectives ask that indicators are identified and that people are trained on them. There is no required count. The CDSE list is a fine starting set. What falls short: - A single session with no recurrence. Training that has lapsed no longer provides what [b] asks for. - The DoD Annual Security Refresher on its own. It touches insider threat only in passing, so it neither identifies the indicators for [a] nor trains people to recognize and report them for [b]. Edge cases: - Cleared facilities already run annual insider threat training under NISPOM, the National Industrial Security Program Operating Manual. It can do double duty only if everyone who handles CUI (Controlled Unclassified Information) takes it, including staff without clearances. - Subcontractor staff with accounts on your system need the training too. Whose problem it is under NISPOM does not change whose problem it is under this requirement, because they are users of your system. Page: https://cmmcpedia.com/requirements/3-2-3/ ## Audit and Accountability (AU) ### AU.L2-3.3.1 System Auditing Official Source Material: Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. Determine if: - [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified; - [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined; - [c] audit records are created (generated); - [d] audit records, once created, contain the defined content; - [e] retention requirements for audit records are defined; and - [f] audit records are retained as defined. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Half of this requirement is writing, not configuration. Objectives [a], [b], and [e] ask for decisions: which event types you log, what each record contains, and how long you keep records. Objectives [c], [d], and [f] ask for proof the systems match the decisions. Write the event list, the record content, and the retention period into your audit policy or system security plan, the document that describes how your system meets each requirement. Then configure systems to match, because an assessor checks the configuration against the document. You decide which events are needed, so decide from an established baseline. Objective [a] says the event types to be logged are specified, and you are the one specifying them. Start from a published audit baseline, such as the DISA STIG settings, the Defense Department's published audit configuration for your operating systems. Remove what you cannot use, and record why. A written selection you can defend beats an exhaustive one you cannot maintain. Cloud tenant logging covers the tenant, not your endpoints. If you run Microsoft 365, keep the unified audit log active and retain the Microsoft Entra ID sign-in and audit logs. Together they record account activity across the tenant, your organization's slice of the service. Your laptops and servers still need a Windows audit policy pushed by group policy or your device management tool. The default policy omits event types an investigation will want, such as removable media use. Define retention in months and prove the platform honors it. The assessment guide says the retention period must account for the weeks or months between a compromise and its discovery. A 30 day default is not a defensible answer for [e]. Define a retention period of at least a year, write it down, and capture the retention settings that enforce it as evidence for [f]. Where a platform caps retention below your defined period, export the logs to storage you control. AU.L2-3.3.1 is a five point requirement with no POA&M path. 32 CFR 170.24 assigns it five points. 32 CFR 170.21 keeps a five point requirement off a POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Miss it and you are five points down with no conditional close-out available. Build logging early instead of treating it as cleanup. What falls short: - Logging turned on everywhere with no written list of event types or record content. Objectives [a] and [b] ask for the specification, and a configuration alone does not show one. - An endpoint detection tool's short built-in query window offered as your retention. When the tool holds less than your defined retention period, [f] is not met. - A default audit baseline nobody reviewed, offered as the specification for [a]. Adopting a baseline is fine, but adopting it unread means you cannot explain how it enables monitoring and investigation. Edge cases: - A cloud service logs a fixed event set you cannot change. Specify which of its event types you rely on and cite the vendor's documentation for record content, because the specification is still yours even when the settings are not. - Logging every file access can crush system performance. The requirement lets you decide failed file access on a busy server is not needed to monitor the confidentiality of CUI, controlled unclassified information, if you record the decision. Page: https://cmmcpedia.com/requirements/3-3-1/ ### AU.L2-3.3.2 User Accountability Official Source Material: Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. Determine if: - [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and - [b] audit records, once created, contain the defined content. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Meet this requirement by pointing at work you already did for AU.L2-3.3.1. Objective [a] asks you to define the record content that ties an action to a person, and [b] asks for records that contain it. When your AU.L2-3.3.1 record content already includes a user identifier, a time stamp, a source address, the action, and the outcome, name those fields as your traceability content. Show sample records. There is no separate logging system to build. Shared accounts are how this requirement fails. A record that names admin or scanner traces to no individual. Give every person a named account, and keep privileged accounts personal. Where a service account cannot be eliminated, restrict who can use it and log the use so a person can still be identified. Evidence is a configuration plus a sample. Show how the audit system is configured to capture user identity, then pull a sample record and point to the identity field. A policy that lists the required fields without records demonstrating them leaves [b] unproven. In a cloud tenant the identity is already in every record. The Microsoft 365 unified audit log and the Microsoft Entra ID sign-in log stamp each entry with the acting account. Your work is the mapping from account to person: one account per person, no sharing, and a record of who holds each privileged account. What falls short: - A shared administrator password used by everyone in IT. Actions taken with it cannot be traced to an individual, so the records cannot supply the traceability [a] defines. - A policy that lists required record fields with no sample records behind it. Objective [b] is about the records, not the policy. Edge cases: - Break glass accounts, the emergency credentials kept for when normal access fails, survive this requirement when you document them, seal the credentials, and alert on every use. The alert plus the access record identifies who used the account and when. Page: https://cmmcpedia.com/requirements/3-3-2/ ### AU.L2-3.3.3 Event Review Official Source Material: Review and update logged events. Determine if: - [a] a process for determining when to review logged events is defined; - [b] event types being logged are reviewed in accordance with the defined review process; and - [c] event types being logged are updated based on the review. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement is about the list of events you log, not about reading logs. The assessment guide states that review of the audit records themselves belongs to AU.L2-3.3.5 and AU.L2-3.3.6. Here you review the logging configuration: whether the event types you chose under AU.L2-3.3.1 still cover your needs. Bring log review records to this requirement and you have answered a different question. Define the trigger for the review in writing. Objective [a] asks for a process that says when the review happens. Name a cadence and the events that force an early review: at least annually, after a security incident, and after a major system change. The CMMC rule at 32 CFR 170.4 defines periodically as at least annually, and an open ended cadence gives an assessor nothing to verify. Hold the review and keep the artifact even when nothing changes. Objective [b] wants evidence the process ran. Meeting minutes, a ticket, or a dated one page review all work. A review that concludes the current event set is sufficient still satisfies [b] when the conclusion is recorded. The strongest evidence for [c] is one real change. A change ticket that adds an event type after a review, such as enabling failed logon events or removable media logging once a gap surfaced, shows the loop closes. If an incident revealed activity you were not logging, the update you made afterward is exactly what [c] describes. Fixed cloud logging does not make this requirement not applicable. When a service such as Microsoft 365 controls what its audit log collects, review whether the collected set meets your needs and record the conclusion. Supplement with endpoint or network logging where it does not. Claiming N/A because you cannot change the vendor's event set earns a Not Met, because the review process is yours no matter who owns the settings. What falls short: - Logging configured at system setup and never revisited. There is no process for [a] and no review for [b]. - Log review dashboards and alert triage records offered as evidence. They show you read the logs, not that you reviewed which event types are logged, so [b] is unmet. - N/A asserted because the cloud provider fixes what is collected. The review process in [a] and [b] is yours, so the requirement applies. Page: https://cmmcpedia.com/requirements/3-3-3/ ### AU.L2-3.3.4 Audit Failure Alerting Official Source Material: Alert in the event of an audit logging process failure. Determine if: - [a] personnel or roles to be alerted in the event of an audit logging process failure are identified; - [b] types of audit logging process failures for which alert will be generated are defined; and - [c] identified personnel or roles are alerted in the event of an audit logging process failure. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: An alert is something that arrives without anyone asking. Objective [c] is met by a notification that reaches a named person or role on its own: an email, a text, a ticket. A procedure where someone checks whether logs arrived is monitoring, not alerting, and it fails the moment nobody checks. The requirement has three parts, and the technical alert is only one of them. Name who gets alerted for [a], write down which failure types generate an alert for [b], and prove delivery works for [c]. An alert rule with no documented recipient and no defined failure list covers one objective out of three. Define failure as logs stopping, plus storage filling. A log source that sends nothing for a defined window has failed, whatever the cause. Add capacity alerts as well, because the assessment guide names audit record storage capacity being reached as a failure type. A rule that fires when a source goes quiet and a rule that fires when the log store nears its limit cover the defined types. Match the alert window to the device's duty cycle. A firewall or server that goes silent for an hour is an incident. A laptop that goes silent over a weekend is a weekend. Set per source alerts for systems that run around the clock, and a multi-day reporting threshold for endpoints that power off. Write the distinction into your failure type definitions. For SaaS platforms, the platform's internal logging is the provider's to keep running and yours to verify. The audit logging Microsoft 365 performs inside the service is the provider's responsibility under FedRAMP, the federal cloud authorization program. Do not assume it. Obtain the provider's customer responsibility matrix, the document that splits security duties between the provider and you, and cite where it covers audit process failure. Alert on the parts you still own, such as the connector that pulls tenant logs into your own log store. What falls short: - An alert rule with no documented recipient and no defined failure types. It leaves [a] and [b] unmet even while the alert works. - A standing calendar reminder to check whether logs arrived. Nothing is generated on failure, so [c] has no evidence. Edge cases: - Phones managed with app level management rather than full device management generate no device audit logs. When AU.L2-3.3.1 defines no device level events for phones, there is no audit process on them to fail, so scope your alerting to the sources you actually collect. Page: https://cmmcpedia.com/requirements/3-3-4/ ### AU.L2-3.3.5 Audit Correlation Official Source Material: Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. Determine if: - [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and - [b] defined audit record review, analysis, and reporting processes are correlated. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Correlate means the logs, the review, and the response work as one system. Objective [a] asks you to define review, analysis, and reporting processes aimed at suspicious activity, and [b] asks that they connect instead of running independently. Cover both readings of connect. Collect logs into one place so events from different systems can be compared. Write the procedure that turns a suspicious finding into an incident under your incident response plan. Central collection is what makes correlation demonstrable. When tenant logs, endpoint logs, and firewall logs land in one log workspace, correlation is a query across sources. The assessment guide accepts manual correlation with well defined and managed procedures for small companies. A documented recurring review that compares sources also works. It is just harder to demonstrate than a query. A year of zero findings undermines you. A review process that never escalates anything looks like a process that does not run. Record triage outcomes even when they are benign: the sign-in alert that turned out to be a traveling employee is evidence the pipeline from log to review to decision works. AU.L2-3.3.5 is a five point requirement with no POA&M path. 32 CFR 170.24 assigns it five points. 32 CFR 170.21 keeps a five point requirement off a POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Treat the link between logging and response as day one work. What falls short: - Logs collected and even reviewed, with no defined path from a suspicious finding to incident response. The processes exist but are not correlated, so [b] fails. Edge cases: - The data an endpoint detection tool collects can stand in for operating system event logs. Define it as your endpoint source under AU.L2-3.3.1, let this requirement's processes read from it, and keep the definitions aligned so the assessor sees one coherent logging story. Page: https://cmmcpedia.com/requirements/3-3-5/ ### AU.L2-3.3.6 Reduction & Reporting Official Source Material: Provide audit record reduction and report generation to support on-demand analysis and reporting. Determine if: - [a] an audit record reduction capability that supports on-demand analysis is provided; and - [b] a report generation capability that supports on-demand reporting is provided. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Reduction is filtering, and a query interface is a reduction capability. Objective [a] does not demand an analytics platform. It asks that a person can turn a mass of raw records into a focused view when needed. The search in your cloud audit portal, a log workspace query, or a script over exported logs each qualify when they reach the log sources you defined under AU.L2-3.3.1. A report is a saved, shareable answer. Objective [b] is met when you can produce output someone else can read: exported query results, a scheduled summary, a filtered view saved to a file. Prepare a few canned questions, such as everything one account did in a day, and be ready to run them live, because on demand includes during the assessment. Keep CUI out of the logging pipeline. Logs are metadata: who, what, when, outcome. Configure logging so file contents never land in a record. A log platform that ingests CUI, the controlled unclassified information you protect, pulls itself into your CUI scope. A platform kept clean of CUI protects the environment without expanding it. What falls short: - Raw log files in storage with no way to search or summarize them. Retention without reduction leaves [a] and [b] unmet. Page: https://cmmcpedia.com/requirements/3-3-6/ ### AU.L2-3.3.7 Authoritative Time Source Official Source Material: Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records. Determine if: - [a] internal system clocks are used to generate time stamps for audit records; - [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and - [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Specify one authoritative time source and point everything at it. Objective [b] says an authoritative source, singular. Systems split across unrelated time sources invite the question of whether their logs can be compared. Name the source in your system security plan, the document that describes how your system meets each requirement. Where a device cannot use it, record the deviation and show the clocks still agree. Most of this already works. The job is naming it and proving it. Domain joined Windows machines sync through the domain hierarchy, and cloud platforms sync their own infrastructure. Network gear takes an NTP setting, the standard network time protocol. Objective [c] wants the comparing and synchronizing shown, so capture the time service status from a server and the NTP configuration page from your firewall. You cannot set the clock on a cloud service, so document it instead. A provider's platform clocks are outside your control. Record in the system security plan that the provider synchronizes its own infrastructure. Review logs in UTC, coordinated universal time, so records from different systems line up without time zone arithmetic during an investigation. What falls short: - Workstations synced to one public time service, the firewall to another, and no evidence the two agree. Objective [b] names a source and this setup names several without justification. Edge cases: - An appliance that forces the vendor's own time service cannot follow your specified source. Document the exception and show its timestamps align with your other logs, because alignment is the outcome the requirement protects. Page: https://cmmcpedia.com/requirements/3-3-7/ ### AU.L2-3.3.8 Audit Protection Official Source Material: Protect audit information and audit logging tools from unauthorized access, modification, and deletion. Determine if: - [a] audit information is protected from unauthorized access; - [b] audit information is protected from unauthorized modification; - [c] audit information is protected from unauthorized deletion; - [d] audit logging tools are protected from unauthorized access; - [e] audit logging tools are protected from unauthorized modification; and - [f] audit logging tools are protected from unauthorized deletion. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Access control carries all six objectives. Restrict who can read audit information for [a] and who can open the tools for [d]. Grant nobody modification rights for [b] and [e]. Confine deletion to the few who manage retention for [c] and [f]. The evidence is a role definition plus the list of people who hold the role. Forward logs off the systems that generate them. An administrator whose actions are being logged can clear a local log. A copy that ships to a central store as events occur means clearing the local log destroys nothing, and the clearing itself becomes an event in the central copy. The tools and settings are protected, not just the data. Objectives [d], [e], and [f] cover the audit configuration and tooling. Restrict who can change audit policy, who can reconfigure log collection, and who can administer the log platform. Keep that list aligned with the subset you define under AU.L2-3.3.9. In a cloud tenant this is a role review. List which directory roles can read, export, or purge audit data, and cut the list to the people who need it. Protect exported log archives with the same restraint, because an export anyone can read undoes [a] no matter how tight the portal is. What falls short: - Every administrator holding rights to purge audit data. Deletion is not confined to an authorized few, so [c] and [f] fail. Edge cases: - A three person company can put log platform access in one admin's hands when a second person receives regular log reports for review. Define the arrangement in writing, because the small headcount is not the problem and a missing definition would be. Page: https://cmmcpedia.com/requirements/3-3-8/ ### AU.L2-3.3.9 Audit Management Official Source Material: Limit management of audit logging functionality to a subset of privileged users. Determine if: - [a] a subset of privileged users granted access to manage audit logging functionality is defined; and - [b] management of audit logging functionality is limited to the defined subset of privileged users. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define the subset in writing even when it is everyone in IT. Objective [a] asks for a defined subset of privileged users who manage audit logging. In a two admin shop where both need coverage, both go on the list. What fails is not a small subset. It is the absence of a definition. Separate audit management from general administration where headcount allows. An administrator who is the subject of the logs and also controls them can hide their own tracks. Give routine administrators no rights over audit settings and put log management in fewer hands. In a cloud tenant, use a dedicated role for log management instead of handing out global administration. When the same people must hold both, have them watch each other. With one or two administrators, have them review each other's activity during log review and record that they did. The mutual review compensates for the separation you cannot achieve, and the record shows you saw the risk and addressed it. What falls short: - Audit settings changeable by every privileged account with no defined list. Objective [a] has nothing to point at, and [b] cannot be true. Edge cases: - A managed service provider administers your logging. The provider's technicians are your subset, so define them by role in your documentation and require the provider to notify you when the roster changes. Page: https://cmmcpedia.com/requirements/3-3-9/ ## Configuration Management (CM) ### CM.L2-3.4.1 System Baselining Official Source Material: Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. Determine if: - [a] a baseline configuration is established; - [b] the baseline configuration includes hardware, software, firmware, and documentation; - [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle; - [d] a system inventory is established; - [e] the system inventory includes hardware, software, firmware, and documentation; and - [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: A baseline says what a machine should be, not what it happens to be. Exporting the current configuration of a workstation is a backup, not a baseline. Write down the operating system edition and version, the standard software with version minimums, and the security-relevant settings you have decided on, then compare machines against that document. Objective [a] asks for the decided state, and the comparison is how you maintain it under [c]. This requirement produces two artifacts, and the objectives split evenly between them. Objectives [a] through [c] are the baseline configuration. [d] through [f] are the system inventory. Both must cover hardware, software, firmware, and documentation under [b] and [e]. Software and documentation are the two categories that get skipped: list the software on the machines, not just the machines, and point each hardware and software entry at its vendor documentation. A spreadsheet is a compliant inventory for a small company. Nothing in the objectives asks for an asset management platform. A spreadsheet with manufacturer, model, serial number, location, assigned owner, installed software, and firmware versions satisfies [d] and [e]. Buy tooling when the row count makes manual upkeep fail, not before. Enforce the baseline with whatever pushes settings. The document is what the requirement asks for. Group Policy, Intune, a standard image, or a written build procedure all work as the mechanism, and no tool is required by name. The test is two questions. Are assets of the same type configured the same? Can you produce the document that says how they are supposed to be configured? A tenant full of Intune policies with no written baseline fails the first half of that test. Standardize before you document. Every operating system, hardware brand, and one-off appliance you keep is another baseline to write and maintain. Fewer platforms means fewer baselines, and that is the biggest reduction in effort available under this requirement. Maintained means reviewed on a schedule and updated on change. Objectives [c] and [f] fail when the documents go stale. Update the baseline when your change process approves a change to it. Update the inventory when hardware or software enters or leaves. Put a recurring review on the calendar to catch what slipped through. Finish this before assessment, because it cannot wait on a plan of action and milestones. A plan of action and milestones is the corrective plan that lets certain gaps be closed after assessment. CM.L2-3.4.1 is a five-point basic security requirement under the scoring methodology in 32 CFR 170.24. Under 32 CFR 170.21, a Conditional status plan may only include requirements worth one point, with a single named exception that is not this one. A missing baseline or inventory is a five-point deduction with no deferral path. What falls short: - A configuration export or backup presented as the baseline. It records what is, not what was decided, so it does not establish a baseline under [a]. - A hardware-only asset list. Objective [e] requires the inventory to include software, firmware, and documentation as well. - Intune or Group Policy enforcement with no written baseline document. Enforcement without a documented decided state leaves [a] and [b] with nothing to point at. Edge cases: - Printers, cameras, and similar appliances do not each need their own baseline document. Cover them as a category with the settings that matter, and keep full baselines for assets that process, store, or transmit CUI, controlled unclassified information. - One monster baseline for the whole network technically maps to the objectives but collapses under CM.L2-3.4.2, which puts per-product security settings inside it. Write one baseline per platform type and let the system security plan, the document that describes how your system meets each requirement, tie them together. Page: https://cmmcpedia.com/requirements/3-4-1/ ### CM.L2-3.4.2 Security Configuration Enforcement Official Source Material: Establish and enforce security configuration settings for information technology products employed in organizational systems. Determine if: - [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and - [b] security configuration settings for information technology products employed in the system are enforced. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Start from a published benchmark and remove what you do not need. Do not write settings from scratch. The CIS Benchmarks and the DoD STIGs are published lists of recommended security settings, so you do not have to invent a hardening standard. Define your settings as the benchmark minus approved exceptions, document each exception with its reason, and objective [a] becomes a short document instead of a long one. The tool that enforces the settings is not the document that establishes them. Intune compliance policies, the settings catalog, and Group Policy Objects are enforcement under [b]. Objective [a] still needs a written statement of what the settings are supposed to be. A setting that exists only inside the tool cannot be compared against anything. Keep the written baseline and audit the tenant against it. Every open port and every deviation gets a recorded reason. A config line does not say why it exists or whether it is security relevant. Keep a firewall rules list with the business justification for each rule and the ticket or approval that created it. Record the rationale for each benchmark deviation. When someone asks in two years why a port is open, that comment is the only answer that exists. Prove enforcement on samples, not with promises. Objective [b] is tested against running systems. The Windows Resultant Set of Policy report from sampled machines shows the settings actually applied. Intune compliance reports do the same, and so does a SCAP scan, an automated check of a machine against your chosen benchmark. Pick whichever your stack produces. The requirement does not name a tool, and compliance scanning is not itself required. Do not write baselines for software that cannot be configured. Applications bundled with the operating system inherit its settings, and a suite needs one baseline, not one per app. Spend the effort on products with security settings worth controlling: operating systems, browsers, firewalls, and anything that touches CUI, the controlled unclassified information your contract requires you to protect. What falls short: - A backup of the running configuration offered as the established settings. Backing up what exists does not establish what should exist, so [a] is unmet. - Firewall rules with no recorded justification. The settings exist, but nothing shows they were established deliberately, which leaves [a] without evidence, and deviations from the intended state are invisible. Edge cases: - A benchmark setting that breaks a business function is handled by documenting the deviation with its rationale and approval. A documented exception to your own baseline is a deviation record, not a failure of the requirement. - Switches, cameras, and badge systems that never touch CUI still get a slim baseline covering the settings that help meet requirements and keep CUI off them. Workstation-grade baselines there are wasted effort. - Servers sharing an operating system but holding different roles take one core OS baseline plus a short appendix per role. Page: https://cmmcpedia.com/requirements/3-4-2/ ### CM.L2-3.4.3 System Change Management Official Source Material: Track, review, approve or disapprove, and log changes to organizational systems. Determine if: - [a] changes to the system are tracked; - [b] changes to the system are reviewed; - [c] changes to the system are approved or disapproved; and - [d] changes to the system are logged. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: One change record can carry all four objectives. Tracked [a], reviewed [b], approved or disapproved [c], and logged [d] can all live in one change record: what changed, on which system, who proposed it, who reviewed it, the decision, the date, and the result. A ticket system does this. So does a spreadsheet. Size the process to the headcount. A three-person shop meets this with a standing meeting. The technical person presents proposed changes, the others hear the justification, and the log records date, attendees, decision, and security impact. A change advisory board is one way to do [b] and [c], not the requirement. Tier your changes so the process survives contact with reality. Routine patching and like-for-like replacements can be pre-approved as standard changes and reported in a periodic digest that the approver reviews. Significant changes go through review before implementation. Write the tiers into the procedure so an assessor sees a decision, not an omission. Emergency changes are fixed first and approved after, when the procedure says so. Define what counts as an emergency, who may act, and where the action is logged. A troubleshooting change recorded in the ticket that prompted it satisfies [d]. A fix that lives only in an administrator's memory fails [a] and [d]. The one-admin company still reviews. When the person proposing the change is the only one who can evaluate it technically, the review is about need and impact, not code inspection. Have the owner or a manager hear the justification and record the approval. That satisfies [b] and [c] and creates a second set of eyes the objectives imply. What falls short: - Administrator changes made directly in production with no record anywhere. Nothing satisfies [a] or [d], and the review and approval in [b] and [c] never happened. - A change management policy with no populated records. The process on paper does not show that changes were actually tracked, reviewed, approved, and logged. Edge cases: - Granting a user permissions outside the norm for their role is a change to the system, so run it through the process. Routine grants that match an approved role pattern do not need individual change records when the procedure says so. - You define which change types need change control, because the requirement does not enumerate them. Write the definition down, so that it excludes a desktop wallpaper and includes firewall rules and group memberships that affect access to CUI, controlled unclassified information. Page: https://cmmcpedia.com/requirements/3-4-3/ ### CM.L2-3.4.4 Security Impact Analysis Official Source Material: Analyze the security impact of changes prior to implementation. Determine if: - [a] the security impact of changes to the system is analyzed prior to implementation. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: One field on the change record meets the single objective. Objective [a] asks that security impact is analyzed before implementation. Add a security impact section to the CM.L2-3.4.3 change record that answers three questions. Does the change alter or create security configuration settings? Does it affect how CUI, controlled unclassified information, is protected? Does documentation need updating? A sentence or two per change is a real analysis. The analyst needs enough knowledge to answer, not a title. Whoever can weigh the change against the baseline and the system security plan, the document that describes how your system meets each requirement, performs the analysis. In a small company that is the administrator proposing the change plus whoever approves it. Record the conclusion, even when the conclusion is no impact. Auto-update stays on. Feature updates wait. Security patches remediate flaws and can flow automatically under a pre-approved standard change. Feature updates add functionality that deserves analysis before it lands. Defer feature updates with whatever your stack provides, such as Windows Update rings in Intune or Group Policy. Use the deferral window to read what is changing before it arrives. Do the analysis before, not as archaeology after. An analysis reconstructed at assessment time is visible as such. The dated impact field on the change record, filled in before the implementation date, is the evidence [a] asks for. What falls short: - Change approvals with no recorded security consideration. Approval evidences CM.L2-3.4.3, and it shows nothing for the analysis this requirement asks for. Edge cases: - Vendor patches you cannot inspect are analyzed at the level available to you: what the vendor says the patch fixes, what it touches, and whether your configuration is affected. Testing on one machine before broad deployment is the practical form of the analysis. - Deferring feature updates too long creates its own risk, because a machine far enough behind on feature releases stops receiving security updates. Bound the deferral and check version support status on a schedule. Page: https://cmmcpedia.com/requirements/3-4-4/ ### CM.L2-3.4.5 Access Restrictions for Change Official Source Material: Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. Determine if: - [a] physical access restrictions associated with changes to the system are defined; - [b] physical access restrictions associated with changes to the system are documented; - [c] physical access restrictions associated with changes to the system are approved; - [d] physical access restrictions associated with changes to the system are enforced; - [e] logical access restrictions associated with changes to the system are defined; - [f] logical access restrictions associated with changes to the system are documented; - [g] logical access restrictions associated with changes to the system are approved; and - [h] logical access restrictions associated with changes to the system are enforced. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement restricts who can make changes, not how changes are approved. CM.L2-3.4.3 governs the change process. This one asks who can physically reach the equipment and who holds credentials that can alter it. The eight objectives are a grid: physical restrictions in [a] through [d] and logical restrictions in [e] through [h], each defined, documented, approved, and enforced. Logical restriction is the short list of people with administrative rights. Name the people authorized to change systems, give only them administrative credentials, and keep everyone else a standard user. Put the named list in the system security plan, the document that describes how your system meets each requirement, or in a procedure. That covers [e] and [f]. A manager's sign-off on the list covers [g], and the directory enforcing it covers [h]. Physical restriction is a locked room and a list of key holders. Servers and network gear live behind a locked door, and you can name who holds the key or badge. That covers [a] through [d] for a small office. Badge logs where they exist. A documented key list and a sign-in sheet where they do not. Let the change management process carry this when it names the restrictions. State three things in the system security plan: changes follow the CM.L2-3.4.3 process, systems sit in access-controlled rooms, and only named administrators hold change credentials. That answers all eight objectives without a separate program. Fully remote companies answer the physical half through inheritance and policy. Infrastructure in a FedRAMP-authorized cloud, one the federal government has assessed and approved, inherits the provider's physical controls. Document the inheritance. Home offices are covered by a remote work policy: a locked door, the screen positioned against shoulder surfing, the laptop secured when not in use. What falls short: - Local administrator rights for the general user population. When everyone can change the system, logical restrictions are neither defined nor enforced, which fails [e] and [h]. Edge cases: - You define which changes the restrictions cover. Scope them to baseline and security-relevant changes so a user changing a desktop theme does not violate your own document. - An outside technician making an approved change works under the same restrictions: escorted physical access, a temporary credential scoped to the task, and both removed when the work is verified. Page: https://cmmcpedia.com/requirements/3-4-5/ ### CM.L2-3.4.6 Least Functionality Official Source Material: Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. Determine if: - [a] essential system capabilities are defined based on the principle of least functionality; and - [b] the system is configured to provide only the defined essential capabilities. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define essential first, or nothing else in this requirement works. Objective [a] asks what each system needs to do for its role: workstations edit documents and handle email, the file server serves files. Write those definitions down. Objective [b] is the configuration work of disabling what falls outside them. The justification column turns your software inventory into evidence. Add a column to the CM.L2-3.4.1 inventory stating why each application is present. Software with no reason gets removed. That one artifact answers [a] for software and shows the review behind [b]. Provisioning is where least functionality happens. IT builds the machine from the baseline, strips what the role does not need, and delivers it. State that in the system security plan, the document that describes how your system meets each requirement. Name the tools that enforce it, such as Group Policy, Intune, or AppLocker. Do not paste every setting into the plan. The plan references the baseline, and the baseline holds the detail. Factory defaults are your responsibility the moment the device is yours. Preinstalled vendor utilities, trial software, and default-enabled services do not become acceptable by arriving preinstalled. Keep what has a documented purpose, such as a recovery tool, and remove the rest. Combining roles on one server is allowed. Document what it does and disable what it does not. A small company running DNS and domain services on one box is within the requirement, provided the combined role is defined and the unused capabilities are off. Keep high-exposure roles, especially anything internet-facing, on their own component where feasible. What falls short: - Systems deployed as shipped. A default install enables services and applications no one defined as essential, so neither [a] nor [b] is met. Edge cases: - Preinstalled OEM tools such as recovery utilities and runtime frameworks stay when you write down why they are needed. Keeping them without the justification is the same gap as installing them without approval. Page: https://cmmcpedia.com/requirements/3-4-6/ ### CM.L2-3.4.7 Nonessential Functionality Official Source Material: Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. Determine if: - [a] essential programs are defined; - [b] the use of nonessential programs is defined; - [c] the use of nonessential programs is restricted, disabled, or prevented as defined; - [d] essential functions are defined; - [e] the use of nonessential functions is defined; - [f] the use of nonessential functions is restricted, disabled, or prevented as defined; - [g] essential ports are defined; - [h] the use of nonessential ports is defined; - [i] the use of nonessential ports is restricted, disabled, or prevented as defined; - [j] essential protocols are defined; - [k] the use of nonessential protocols is defined; - [l] the use of nonessential protocols is restricted, disabled, or prevented as defined; - [m] essential services are defined; - [n] the use of nonessential services is defined; and - [o] the use of nonessential services is restricted, disabled, or prevented as defined. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Fifteen objectives collapse into three lists. Programs are [a] through [c], functions are [d] through [f], and ports, protocols, and services are [g] through [o]. Treat ports, protocols, and services as one combined list, because a firewall rule that blocks a port blocks the protocol and the service behind it. Classify in three tiers and the definitions write themselves. Essential is what your requirements and business functions need. Restricted is allowed only through an approved, documented rule where everything else is blocked by default. Prohibited is the known-insecure set blocked outright, such as FTP, Telnet, and SMBv1, so that no future rule allows them by accident. Defining nonessential as everything outside the essential list is a legitimate definition. Objectives [b], [e], [h], [k], and [n] ask that nonessential use is defined. State in the procedure that anything outside the essential definitions is nonessential and is blocked, disabled, or removed on discovery. That sentence satisfies the definition objectives without an impossible enumeration. Do not classify a hundred Windows services one by one. Define essential at the level you control: the roles a machine serves, the applications on the approved list, the ports the firewall permits. Operating system services that support those roles are covered by the baseline, and the ones your CM.L2-3.4.2 benchmark says to disable get disabled there. Functions are capabilities you can switch off, and naming a few is enough. Reading, editing, and saving project documents is essential. Bluetooth file transfer, games, and music streaming are nonessential functions you restrict. The objectives ask for definitions and enforcement, not an exhaustive taxonomy. One rules list serves this requirement and CM.L2-3.4.2. The firewall export with a business justification per rule evidences established configuration settings there and essential port definitions here. Build it once and reference it from both. What falls short: - Firewall rules alone with nothing defined in writing. Enforcement without definitions fails [a], [d], [g], [j], and [m], because nothing shows what was decided to be essential. Edge cases: - An open port with no traffic is still an open port. Define essential by what the role needs and close the rest, and do not rely on the argument that an unused open port is not in use. - The definitions can live in the system security plan or in a referenced document. Either placement works as long as the document exists and you can hand it over. Page: https://cmmcpedia.com/requirements/3-4-7/ ### CM.L2-3.4.8 Application Execution Policy Official Source Material: Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. Determine if: - [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified; - [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and - [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Pick a policy, name it in writing, and the choice itself is objective [a]. The requirement accepts either deny-by-exception or deny-all, permit-by-exception. Objective [a] wants the written policy naming which one you run, [b] wants the list of software it governs, and [c] wants the mechanism enforcing it as specified. Deny-by-exception is compliant under this requirement as written. The requirement text offers it as an option, and a written deny list enforced by your endpoint tooling satisfies all three objectives. Populate the list deliberately: end-of-life software, unapproved remote access and VPN clients, keyloggers, games, alternatives to tools you have standardized, and products prohibited in federal contracting. Then use the CM.L2-3.4.1 software inventory to confirm nothing on the list is installed. Allowlisting is the stronger policy, and the operating system already ships the tooling. AppLocker and App Control for Business enforce permit-by-exception on Windows. Start by allowing digitally signed software from your approved publishers. Run in audit mode until you understand the noise. Then enforce, and extend the policy to scripts and libraries as you mature. The installed-software inventory is not an allowlist. When the list of allowed software is whatever is currently installed, anything anyone installs becomes authorized the moment it lands. The list under [b] is decided in advance. The inventory is what you reconcile against it. This requirement governs execution. CM.L2-3.4.9 governs installation. Blocking a program from running and controlling who installs software are separate requirements with separate evidence. An execution policy covers the first. Installation rights and monitoring cover the second, and the software inventory from CM.L2-3.4.1 feeds both. What falls short: - A policy that names deny-by-exception with no actual list. Objective [b] requires the denied software to be specified, and an implicit list specifies nothing. - An allowlist defined as whatever the inventory tool currently reports. Unauthorized installs self-authorize, which inverts [b]. Edge cases: - A one-line deny list is technically within the requirement text, and it buys almost nothing. Write the list you would actually want enforced, because the assessor reads it as your considered position on unauthorized software. Page: https://cmmcpedia.com/requirements/3-4-8/ ### CM.L2-3.4.9 User-Installed Software Official Source Material: Control and monitor user-installed software. Determine if: - [a] a policy for controlling the installation of software by users is established; - [b] installation of software by users is controlled based on the established policy; and - [c] installation of software by users is monitored. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The three objectives are a policy, a control, and a monitor, and removing admin rights is only the middle one. Objective [a] wants a written policy on software installation by users, [b] wants the control that enforces it, and [c] wants monitoring that would catch what slipped through. Standard users without local administrator rights satisfy [b] and nothing else. Monitoring is required even when installation is impossible. The question to answer is how you know users installed nothing if you never look. A recurring software inventory report compared against the approved software list answers it, and an empty result is itself the evidence of monitoring under [c]. Reconcile discoveries against change control. New software found by the inventory tool is either matched to an approval or investigated. Document what happens when unauthorized software appears: who investigates, how it is removed, and where the outcome is recorded. Developers with local admin are a policy decision, not a violation. Grant the exception in the policy. Source tools from controlled repositories where you can. Commit to tighter monitoring, with retroactive approval through change control for what gets added. Keep that arrangement off general-user machines, because a compromised developer endpoint is the worst place to find surprise software. What falls short: - Removed admin rights presented as the complete answer. It leaves [a] without a policy and [c] without monitoring. - A software inventory tool no one reviews. Collection without comparison against the approved list is not monitoring under [c]. Page: https://cmmcpedia.com/requirements/3-4-9/ ## Identification and Authentication (IA) ### IA.L2-3.5.1 Identification Official Source Material: Identify information system users, processes acting on behalf of users, or devices. Determine if: - [a] system users are identified; - [b] processes acting on behalf of users are identified; and - [c] devices accessing the system are identified. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Three populations need identifiers: people, service accounts, and devices. Objective [a] is every human user, [b] is processes acting on behalf of users, and [c] is devices. Your directory, the account system such as Active Directory or Microsoft Entra ID, covers [a] the day you stand it up. Objectives [b] and [c] are where the deliberate work lives. A process acting on behalf of a user is a service account, not an application a person runs. Word running under a signed-in user is that user's process and needs no identifier of its own. The backup job, the scanner uploading to a document library, and the integration service principal in Microsoft Entra ID are accounts that are not people but act like people. List each one with its purpose and owner, and [b] is met. Ignore the operating system's built-in service identities. SYSTEM, Local Service, Network Service, and TrustedInstaller are internal Windows machinery. If you document them at all, one line calling them native operating system accounts necessary for system function is enough. Devices get identified by whatever your management stack already assigns. Intune assigns each enrolled device its own device identifier. For equipment outside management, define the method in a procedure: MAC address, asset tag, or hostname convention. Objective [c] asks that a method exists and is applied, not that it be sophisticated. Shared accounts survive this requirement only with traceability bolted on. The assessment guide states that management of individual identifiers is not applicable to shared system accounts, but an account no one can trace to a person undermines everything downstream. Where a shared account is unavoidable, put its credential in a vault that logs who checked it out and rotates it after use. What falls short: - Service accounts that exist in the directory but appear in no documentation. Objective [b] asks that they be identified, and an assessor reviewing the account list will find them before you name them. Edge cases: - AC.L2-3.1.1 uses nearly identical wording, but it governs who is authorized while this requirement governs how the system labels users, processes, and devices. The same account list can serve both, but the answers differ. Page: https://cmmcpedia.com/requirements/3-5-1/ ### IA.L2-3.5.2 Authentication Official Source Material: Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems. Determine if: - [a] the identity of each user is authenticated or verified as a prerequisite to system access; - [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and - [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Nothing gets access before proving what it is. Users [a], processes acting on behalf of users [b], and devices [c] each authenticate before the system lets them in. For users and service accounts a modern directory does this by default. Your work is confirming that no path around it exists. Hunt down default credentials before an assessor does. Network gear, printers, cameras, and appliances ship with published usernames and passwords, and those credentials are easily found in a search. Change them at deployment, and put that step in the provisioning procedure so the practice is documented rather than remembered. Devices authenticate through domain join or enrollment. Verification covers the fixed fleet. The requirement says authenticated or verified. Devices joined to the domain or enrolled in Intune attest their identity when they connect, which satisfies [c]. A small office can verify instead, but the verification has to happen before access. Pair a maintained inventory of known devices with a gate that admits only inventoried devices, at fixed locations in a controlled area. Remote devices get real authentication, because no one can walk over and verify them. Service accounts authenticate too, and the record of them is what you show. A script or integration signs in with a credential, a certificate, or a token. Keep the IA.L2-3.5.1 service account list annotated with how each one authenticates. That record answers [b] and pays for itself again during log review and incident response. Cloud-only does not remove the endpoints. CUI (Controlled Unclassified Information) comes down from the cloud onto laptops for editing, printing, and building new documents. Those endpoints and their users authenticate like everything else. Moving the data to the cloud moves none of this requirement away. What falls short: - Anything still reachable with a default password. The identity presented is the manufacturer's, not the device's, so [c] fails on that path. Edge cases: - A machine or instrument that cannot authenticate to anything is handled by documenting it and restricting what it can reach. Cover it in the system security plan rather than pretending it authenticates. Page: https://cmmcpedia.com/requirements/3-5-2/ ### IA.L2-3.5.3 Multifactor Authentication Official Source Material: Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. Determine if: - [a] privileged accounts are identified; - [b] multifactor authentication is implemented for local access to privileged accounts; - [c] multifactor authentication is implemented for network access to privileged accounts; and - [d] multifactor authentication is implemented for network access to non-privileged accounts. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Network access includes your office LAN. Get the definitions right before you scope anything. The assessment guide defines local access as access obtained by direct connection without the use of networks, and network access as access obtained through network connections. A user signing into a domain workstation at a desk is network access. MFA (multifactor authentication) on the VPN and on Microsoft 365 while plain passwords open everything on the internal network is the classic failure of objective [d]. Objective [a] is a list you write before touching any technology. Identify every privileged account: domain and Microsoft Entra ID administrator roles, firewall and switch administration, hypervisor and backup consoles, and your managed service provider's accounts in your environment. Privileged accounts then need MFA everywhere, including local access under [b]. Non-privileged accounts need it for network access under [d]. Factors are something you know, have, or are. Device attributes are not factors. A compliant device, an allowed IP range, a MAC address, or a location is a policy condition, not a second factor. An authenticator app, a FIDO2 key, a smart card, or a time-based code is. Conditional Access policies in Microsoft Entra ID enforce MFA. They are not themselves MFA. Password fallback quietly deletes your MFA. Windows Hello for Business with a TPM (the trusted platform module chip) plus PIN or biometric is a defensible two-factor implementation, but only when enforced. If a user can pick other sign-in options and get in with just the password, the control is optional, and demonstrating your sign-in flow is a standard assessment step. Enforce the strong path and be ready to show both factors in use. Local access to privileged accounts is the objective people forget. Objective [b] covers the administrator at the console. An OS-level MFA agent on servers and admin workstations covers it directly. Vaulted credentials cover it another way. When the local administrator password sits in LAPS, Microsoft's Local Administrator Password Solution, or in a privileged access vault that itself demands MFA, retrieving the credential requires the second factor. Phones do not need MFA to unlock. They need it to reach your systems. The assessment guide states that multifactor authentication is not required for access to mobile devices such as smartphones or tablets. The session the phone opens to your email or files is network access to your system and prompts like any other client. The scoring rule gives partial credit here and removes the deferral path. 32 CFR 170.24 subtracts three points when MFA covers only remote and privileged users, and five when it covers no one. This is one of only two Level 2 requirements scored with partial credit. A plan of action and milestones is the documented list of gaps you commit to close after assessment. Because the value exceeds one point either way, 32 CFR 170.21 keeps IA.L2-3.5.3 off a Conditional status plan. Finish it before assessment. What falls short: - MFA on cloud email and the VPN only. Internal network sign-ins stay single factor, which leaves [d] unmet for every on-premises path. - MFA prompted once at device enrollment or account setup. The objectives ask for MFA on access, not on setup. - Windows Hello for Business configured but not enforced, with password sign-in still allowed. The second factor is optional, so [b], [c], and [d] rest on a control users can decline. Edge cases: - Manufacturing equipment and other specialized assets that cannot do MFA are documented as an enduring exception with mitigations in the system security plan. 32 CFR 170.24 assesses enduring exceptions described that way as MET. - Network gear with no native MFA support is covered by fronting management with an MFA-protected jump host or authentication service, or by vaulting the admin credential behind MFA. - Switching to a second account mid-session is a new access. Signing into a privileged account from an MFA-authenticated standard session still takes the privileged account through its own factor. Page: https://cmmcpedia.com/requirements/3-5-3/ ### IA.L2-3.5.4 Replay-Resistant Authentication Official Source Material: Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. Determine if: - [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: A current Windows and TLS stack already resists replay. Your job is turning off the parts that do not. A replay attack captures sign-in traffic and sends it again to impersonate the original user. Kerberos, the sign-in protocol inside Windows domains, TLS on web applications, and time-based MFA codes all resist replay by design. Set NTLMv2 as the minimum authentication level, disable SMBv1, and retire services that still authenticate over cleartext protocols. The single objective [a] is then covered for privileged and non-privileged accounts alike. Evidence is configuration, not packet captures. Show the Group Policy or directory settings enforcing Kerberos and the NTLMv2 minimum, the TLS configuration on web services, and the MFA solution rejecting reused codes. The configuration itself is the demonstration. A packet capture adds nothing an assessor needs. Your MFA deployment is doing double duty here. The time-synchronous and challenge-response one-time mechanisms deployed for IA.L2-3.5.3 are exactly the replay-resistant techniques the requirement's discussion names. Where MFA covers network access, this requirement rides along with it. What falls short: - Legacy protocols still answering: Telnet, FTP with credentials, HTTP basic authentication without TLS, or NTLMv1. Traffic captured on any of these can be replayed, so [a] fails on that path. Edge cases: - A cloud provider's own compliance documentation may call for stronger authentication, such as smart card certificates, than this requirement does. You are assessed against the requirement, not the provider's customer responsibility matrix, and time-based MFA satisfies [a] in any tenant. Page: https://cmmcpedia.com/requirements/3-5-4/ ### IA.L2-3.5.5 Identifier Reuse Official Source Material: Prevent reuse of identifiers for a defined period. Determine if: - [a] a period within which identifiers cannot be reused is defined; and - [b] reuse of identifiers is prevented within the defined period. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Pick a period, write it down, and the hard half is done. Objective [a] is satisfied by a sentence in your identifier policy: usernames and device identifiers are not reassigned to a different person or device for a defined period. A two-year period is a defensible choice. Objective [b] is whatever mechanism makes that sentence true. Never deleting accounts is the cheapest prevention. Disable departed users and keep the objects: a disabled-users organizational unit on premises, sign-in-blocked accounts in Microsoft Entra ID. While the object exists, the directory itself refuses to issue that identifier again, which enforces [b] with no extra machinery. The same person can come back to the same identifier. The assessment guide's discussion says preventing reuse means preventing previously used identifiers from going to different individuals, groups, roles, or devices. A rehired employee reclaiming their old username is not the risk this requirement targets. Write the allowance into the policy and reactivate the account. Do not invent an obfuscation program. Nothing here requires usernames that differ from email addresses or anonymized account names. Matching the sign-in name, the user principal name, to the mailbox is fine. The requirement is only that identifiers are not recycled onto someone new. What falls short: - Deleting accounts at offboarding with nothing preventing the username from being recreated for someone else. The period under [a] may be defined, but nothing enforces [b]. Edge cases: - Device identifiers are covered by the same discussion, and management platforms handle them without help: a management platform generates a device identifier per device rather than recycling old ones. Scope your manual effort to user identifiers and say so in the policy. Page: https://cmmcpedia.com/requirements/3-5-5/ ### IA.L2-3.5.6 Identifier Handling Official Source Material: Disable identifiers after a defined period of inactivity. Determine if: - [a] a period of inactivity after which an identifier is disabled is defined; and - [b] identifiers are disabled after the defined period of inactivity. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define the inactivity window and make something actually enforce it. Objective [a] is a number in your policy. The assessment guide's worked example uses 45 days. Objective [b] is the mechanism: a scheduled report of last sign-in dates with a documented disable step, or an automation that disables at the threshold. Disabled is not deleted, and this requirement is why. Disabling ends the risk of an unwatched active account while preserving the object, which also carries the identifier reuse prevention in IA.L2-3.5.5. Disable at the inactivity threshold. Delete on your own schedule or never. Scope it to user accounts. Computer objects, key cards, and every other identifier-bearing thing invite scope creep. Define the requirement's reach as user identifiers, and handle service accounts by deliberate review rather than automatic disabling, because an auto-disabled backup account is an outage. Write the definition into the procedure. Plan the leave-of-absence path before it happens. Extended leave trips any inactivity threshold. Suspend the account, keep the device on inventory, and re-enable through a defined step when the person returns. A documented exception process keeps [b] enforced without punishing parental leave. What falls short: - A policy stating the period with no evidence anyone checks. Objective [b] asks that identifiers are actually disabled, and the absence of any report or disable record shows they are not. Page: https://cmmcpedia.com/requirements/3-5-6/ ### IA.L2-3.5.7 Password Complexity Official Source Material: Enforce a minimum password complexity and change of characters when new passwords are created. Determine if: - [a] password complexity requirements are defined; - [b] password change of character requirements are defined; - [c] minimum password complexity requirements as defined are enforced when new passwords are created; and - [d] minimum password change of character requirements as defined are enforced when new passwords are created. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement asks for composition rules, so define composition rules. Current NIST password guidance in SP 800-63B moved away from complexity requirements, but the requirement text and objectives here have not. Objectives [a] and [c] are defined and enforced complexity. [b] and [d] are defined and enforced change of characters. You are assessed against this text, not against the newer guidance, so meet the text in front of you. You set the minimums, so set ones you can defend. The objectives leave the numbers to you. A minimum length of twelve or more characters with three of the four character types is defensible and enforceable in Active Directory and Microsoft Entra ID. Choosing a longer minimum and citing the evolution of password guidance as the reason is equally defensible. Choosing eight characters is enforceable but weak. Change of characters is the pair of objectives that gets missed. Define it even though enforcement is thin. Objectives [b] and [d] want a rule about characters changing when a password changes, and mainstream platforms do not count changed characters natively. Define a minimum of at least one changed character, and enforce it through the platform's password history setting, which blocks the fully identical case. State that implementation in your system security plan, the document that describes how your system meets each requirement. No objective requires password expiration. Nothing in [a] through [d] mentions a maximum password age. Long passwords that never expire, paired with the MFA this family already requires, are consistent with every objective here. If you keep expiration, keep it as your own policy choice, not because this requirement demands it. What falls short: - Platform defaults with nothing defined in writing. Objectives [a] and [b] are definitions, and enforcement of an undefined rule cannot satisfy [c] or [d]. Page: https://cmmcpedia.com/requirements/3-5-7/ ### IA.L2-3.5.8 Password Reuse Official Source Material: Prohibit password reuse for a specified number of generations. Determine if: - [a] the number of generations during which a password cannot be reused is specified; and - [b] reuse of passwords is prohibited during the specified number of generations. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Specify the number of generations and let the directory enforce it. Objective [a] is one number in the password policy. Twenty-four remembered passwords matches the Windows security baseline, and the matching password history setting in Group Policy or your directory satisfies [b] with a single control. Temporary passwords are exempt by the requirement's own discussion. The assessment guide states that password lifetime restrictions do not apply to temporary passwords, so the one-time credential a help desk issues under IA.L2-3.5.9 does not enter the generation count. Document what each platform can enforce. Where a system exposes a configurable history depth, set your specified number there. Where one does not, state the platform's actual reuse behavior in the policy and rely on it. The objectives ask that the number is specified and reuse prohibited, not that every product expose the same setting. Page: https://cmmcpedia.com/requirements/3-5-8/ ### IA.L2-3.5.9 Temporary Passwords Official Source Material: Allow temporary password use for system logons with an immediate change to a permanent password. Determine if: - [a] an immediate change to a permanent password is required when a temporary password is used for system logon. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: One checkbox meets the objective where directories are involved. Requiring a password change at next sign-in is the entire technical implementation of [a] in Active Directory and Microsoft Entra ID. Set it on every account created or reset with a temporary password. Make it a step in the account creation and reset procedures so it is never optional. Where the platform cannot force the change, procedure plus justification carries it. Some local accounts and some virtual desktop first-logon flows cannot enforce a change at first use. Document why the enforcement is unavailable and the instruction users follow instead. An explained gap with a procedure reads as an implementation. An unexplained one reads as a miss. Make the temporary password worthless after first use. Generate it randomly per user instead of a predictable house pattern, deliver it through a separate channel, and expire it if it goes unused. The new permanent password then has to meet the IA.L2-3.5.7 rules, which is the point of forcing the change immediately. Page: https://cmmcpedia.com/requirements/3-5-9/ ### IA.L2-3.5.10 Cryptographically-Protected Passwords Official Source Material: Store and transmit only cryptographically-protected passwords. Determine if: - [a] passwords are cryptographically protected in storage; and - [b] passwords are cryptographically protected in transit. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Storage means hashed or encrypted, transit means encrypted, everywhere a password lives or moves. Hashing converts a password into a one-way code that cannot be turned back into the password. Objective [a] covers everything holding passwords: the directory database, application credential stores, the password vault. Objective [b] covers every path a credential travels: sign-in pages, directory binds, service authentications. A modern Windows domain hashes what it stores and encrypts what Kerberos carries, so the work is finding the exceptions. Kill the cleartext paths by name. LDAP simple binds on port 389, HTTP sign-in forms, FTP and Telnet carrying credentials, and SMTP authentication without TLS all transmit passwords unprotected. Move LDAP integrations to LDAPS, require TLS on every authentication endpoint, and keep reversible encryption disabled in the domain, because that one setting stores passwords recoverably. FIPS validation is not in these objectives. Objectives [a] and [b] ask for cryptographic protection, not FIPS-validated modules. FIPS-validated encryption belongs to SC.L2-3.13.11, which 32 CFR 170.24 ties to protecting the confidentiality of CUI. Do not import that burden into this requirement. A company-deployed password manager is compliant and in scope. A vault that encrypts at rest and serves credentials over TLS satisfies both objectives for the passwords it holds. Reversible encryption inside a vault is its design, not a violation. Deploy one deliberately: it displaces the browser-saved passwords and personal accounts that are the shadow alternative. Because it holds the credentials that unlock your environment, it is a security protection asset you account for in scoping. The passwords spreadsheet fails storage in the plainest way. Shared spreadsheets of credentials, text files on desktops, and passwords saved in unmanaged browsers are unprotected storage under [a]. The fix is the vault from the previous lesson plus a policy line prohibiting the rest. Five points ride on this requirement. 32 CFR 170.24 lists IA.L2-3.5.10 among the five-point derived security requirements. 32 CFR 170.21 keeps requirements worth more than one point off a Conditional status plan of action and milestones, the documented list of gaps you commit to close after assessment. The rule names a single exception, and it is not this one. Cleartext credential paths are cheap to find and expensive to leave. What falls short: - An LDAP integration still binding over port 389. Credentials cross the wire unencrypted, failing [b] regardless of how well they are stored. - A credentials spreadsheet, however convenient. Unencrypted storage fails [a], and full disk encryption underneath it protects the powered-off disk, not the file from anyone signed in. Page: https://cmmcpedia.com/requirements/3-5-10/ ### IA.L2-3.5.11 Obscure Feedback Official Source Material: Obscure feedback of authentication information. Determine if: - [a] authentication information is obscured during the authentication process. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Every mainstream sign-in screen already obscures input. Your work is inventory, not engineering. Masked password fields on the operating system, in browsers, on network gear consoles, and in your single sign-on portal satisfy objective [a] out of the box. Collect a screenshot per system type and pair the set with one policy sentence stating that authentication feedback is obscured. The reveal-password control and brief character display do not fail you. The assessment guide accepts displaying feedback for a very limited time before fully obscuring it, which is what mobile keyboards and the reveal control do. Cover the residue with a procedure line telling users not to reveal passwords within view of others, because a procedure reaches the applications no setting can. Do not build controls to disable what vendors ship enabled. Disabling the reveal button through policy is available if you want it, but it is not needed to meet [a], and it trades a compliance nothing for extra lockouts. Spend the effort on requirements with objectives still unmet. Page: https://cmmcpedia.com/requirements/3-5-11/ ## Incident Response (IR) ### IR.L2-3.6.1 Incident Handling Official Source Material: Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. Determine if: - [a] an operational incident-handling capability is established; - [b] the operational incident-handling capability includes preparation; - [c] the operational incident-handling capability includes detection; - [d] the operational incident-handling capability includes analysis; - [e] the operational incident-handling capability includes containment; - [f] the operational incident-handling capability includes recovery; and - [g] the operational incident-handling capability includes user response activities. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: An incident response plan plus the security tools you already run is the capability. A security operations center is not. Objective [a] asks whether an operational capability exists, not whether anyone watches a screen around the clock. A written incident response plan, an endpoint protection tool that raises alerts, a named reporting channel, and people who know their roles establish the capability. Buy monitoring services when your risk justifies them, not because this requirement demands them. Write the plan around the six activities the objectives name. Objectives [b] through [g] each check one phase: preparation, detection, analysis, containment, recovery, and user response. Give each phase its own section that says who acts and what they do. An assessor walks the letters in order, and a plan organized the same way answers each one directly. Preparation is a short list of concrete artifacts. Preparation needs four things. List the people inside and outside the organization you would call. Name a reporting channel, such as an email address or phone number. Set up a way to track incidents from open to closed, and a place to store evidence. Those four items carry [b], and none of them requires new tooling. Detection and analysis then run on what you already have. Antivirus and endpoint alerts, log entries that raise concern, and user reports are the sources for [c]. Analysis under [d] means someone compares what they see against normal operations and writes down what happened, including the associated log entries. User response means every user knows how to recognize and report an incident, and responders know their parts. Objective [g] is about people. Ordinary users need to know what looks suspicious and who to call. Administrators need the containment and recovery steps for the systems they run. Put the reporting path in your awareness training under AT.L2-3.2.1, and the responder duties in role-based training under AT.L2-3.2.2. Objective [g] then falls out of training you already owe. Build your DFARS reporting duties into preparation without mistaking them for this requirement's objectives. DFARS 252.204-7012, the safeguarding clause in your DoD contracts, sets a 72-hour clock. It covers a cyber incident that affects a covered contractor information system, the covered defense information on it, or your ability to provide operationally critical support. The report goes to DoD within 72 hours of discovery. It also requires preserving images and logs for at least 90 days from submission of the report. None of the seven objectives here measures that clause. Incident reporting has its own requirement, IR.L2-3.6.2, and the 72-hour clock stays a contract obligation either way. Put the DoD reporting steps, the address of DIBNET, DoD's incident reporting portal, and the preservation duty into the plan now. The 72-hour clock is not the time to learn them. A stolen laptop with CUI on it is an incident. The capability covers physical loss and theft of equipment holding CUI, Controlled Unclassified Information, not just network intrusions. Cover it in the same plan or in a separate physical loss procedure. Either way, both paths exist and name their owners. What falls short: - A purchased incident response plan template with the blanks unfilled. It names no contacts, no reporting channel, and no systems, so it establishes nothing for [a]. - A plan that stops at containment. Objective [f] asks for recovery, so the plan must say how systems are restored and how the underlying cause is addressed. - A capability that gives ordinary users no way to report what they see. User reports are a named detection source, and without a reporting path the capability has nothing for [g]. Edge cases: - An MSP or MSSP, a managed service provider or managed security service provider, that handles incidents for you is part of the capability. The plan says what they do, where your people take over, and how to reach them, their duties appear in the responsibility matrix, and the requirement stays yours to demonstrate. - Separate physical and cyber incident plans are workable, with a facility security officer owning loss and theft and the security lead owning the cyber plan. Expect overlap, and make sure neither plan assumes the other covers a stolen CUI device. Page: https://cmmcpedia.com/requirements/3-6-1/ ### IR.L2-3.6.2 Incident Reporting Official Source Material: Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. Determine if: - [a] incidents are tracked; - [b] incidents are documented; - [c] authorities to whom incidents are to be reported are identified; - [d] organizational officials to whom incidents are to be reported are identified; - [e] identified authorities are notified of incidents; and - [f] identified organizational officials are notified of incidents. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The six objectives are three pairs: record, identify, notify. Objectives [a] and [b] ask for a record of incidents. Objectives [c] and [d] ask you to name the external authorities and internal officials who get told. Objectives [e] and [f] ask for evidence that the identified parties actually hear about incidents when they occur. Build the requirement in that order. Tracking is a log. Documentation is the story of each incident. A ticket system or a spreadsheet with an entry per incident, its status, and its dates satisfies [a] at any size. Documentation under [b] is the fuller record: what was observed, which systems were involved, what was done, and when it closed. Keep both, because the log across time is how you spot a repeat problem. Define what you report externally before an incident forces the question. Write a reportable incident definition into your plan: which events require notification outside the organization and which stay internal. Anchor the external threshold to DFARS 252.204-7012, the safeguarding clause in your DoD contracts. It covers a cyber incident that affects a covered contractor information system, the covered defense information on it, or your ability to provide operationally critical support. Reports go to DoD within 72 hours of discovery. A definition on paper turns a 2 a.m. judgement call into a lookup. Not every malware detection is a reportable cyber incident. Malware that your endpoint protection blocked and quarantined before it touched CUI, the Controlled Unclassified Information you protect, did not adversely affect the system. Record the detection, judge it against your written definition, and keep the determination with the ticket. The record of a considered decision is [a] and [b] working as intended. Name the authorities and the officials now, and secure the access to reach them. For DoD work the external report goes through DIBNET, DoD's incident reporting portal at dibnet.dod.mil. Submitting one requires a DoD-approved medium assurance certificate, a purchased identity credential that takes longer to obtain than the 72 hours you would have. Get the certificate before you need it. Internally, name the roles that hear about an incident: the owner, the program lead, whoever calls the prime contractor above you. Put names against the roles in the plan. That covers [c] and [d]. A clean history is documented, not assumed. When no incident has met your reporting threshold, keep the tracking log anyway. Record a dated statement that no incidents have required external notification since your system security plan, the document that says how each requirement is met, took effect. Keep the thresholds themselves alongside it. Objectives [e] and [f] are then evidenced by the working procedure and the empty log, and an assessor can follow the path a real incident would take. What falls short: - A policy that says incidents will be reported to the appropriate authorities without naming them. Objectives [c] and [d] ask for identified authorities and officials, and appropriate is not a name. - An incident that was handled well but never written down. A verbal account leaves nothing for [b]. - Waiting for an incident to sort out DIBNET access. A report due within 72 hours cannot wait on a certificate application, so the notification duty behind [e] goes unmet when it matters. Edge cases: - Subcontractors report their own cyber incidents to DoD under DFARS 252.204-7012 and pass the incident report number to the prime. Check the contract for additional notification duties the prime added, and write both paths into the plan. - Suspicious email that looks like targeted phishing belongs in the tracking log even when nothing was compromised. Let the written threshold decide whether anyone outside the organization needs to hear about it. Page: https://cmmcpedia.com/requirements/3-6-2/ ### IR.L2-3.6.3 Incident Response Testing Official Source Material: Test the organizational incident response capability. Determine if: - [a] the incident response capability is tested. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: A tabletop exercise once a year carries this requirement. Gather the people named in the incident response plan, walk a realistic scenario end to end, and take notes. The requirement text sets no frequency, but a test with no recurrence goes stale as systems and people change. A plan that exists only on paper is exactly what this requirement exists to catch. An annual exercise keeps the evidence current and the muscle memory real. Test the plan you actually wrote. Drive the scenario through your own procedures. Cover how the incident is discovered, who is called, which forms get filled in, how containment is decided, and who talks to the prime contractor and to DoD. Fill out your real incident forms during the exercise. Walk the reporting steps for DIBNET, DoD's incident reporting portal, without submitting. Check whether your logs would have caught the scenario's activity. Every gap you find is the test working. A real incident does not replace a deliberate test. The requirement's discussion names checklists, walk-through and tabletop exercises, simulations, and comprehensive exercises as testing. Fold what a real response taught you into the plan, and still run the exercise, because a live incident exercises only the path it happened to take. No special people or tools are needed. Your own administrators are the ones who will respond to a real incident, so they are the right people to test with. A conference room, a scenario, and two hours does it. CISA, the federal cybersecurity agency, publishes free tabletop exercise packages with ready-made scenarios if you do not want to write your own. The output documents are the evidence. Keep the scenario, the date, the attendee list, notes on what worked and what did not, and the changes made to the plan afterward. A lessons-learned item that produced an actual change is the strongest answer to [a], because it shows the test changed something. What falls short: - An incident response plan with no test on record. A reviewed and signed plan shows the plan exists, not that the capability was tested, so [a] has no evidence. - A write-up of a real incident offered as the test. It supplements testing without replacing the deliberate exercise the requirement's discussion describes, so [a] is not evidenced. Edge cases: - When an MSP or MSSP, a managed service provider or managed security service provider, performs your incident response, they belong in the exercise. A test that never engages the people who would actually respond does not test the capability. Page: https://cmmcpedia.com/requirements/3-6-3/ ## Maintenance (MA) ### MA.L2-3.7.1 Perform Maintenance Official Source Material: Perform maintenance on organizational systems. Determine if: - [a] system maintenance is performed. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: You already perform maintenance. The work here is showing it. Patching operating systems and applications, fixing what breaks, replacing failing hardware, and updating firmware are all system maintenance. Objective [a] asks whether it happens. Patch reports from your management tooling and a trail of closed tickets are the evidence, so keep both where you can produce them. Write down a cadence and follow it. Write a short statement in the maintenance policy: endpoints and servers receive updates monthly, network devices and firmware follow the vendor's releases, and defects are fixed as tickets arrive. That statement turns scattered activity into a program an assessor can check against reality. Manufacturer recommendations are a defensible default where you have no reason to differ. In a cloud environment, the provider maintains the service and you maintain everything that touches it. Microsoft maintains the infrastructure of GCC High, its government cloud, and that split belongs in your responsibility documentation. Your side is the endpoints, the network equipment, and their firmware. Provider maintenance never patches your laptop. Maintenance covers more than computers. The requirement's discussion pulls in components not directly associated with information processing: scanners, copiers, and printers. Firmware on a firewall or a copier is exactly the kind of thing that goes untouched for years, so put those devices on the same cadence. What falls short: - A patching policy with no record that patching happens. Objective [a] asks whether maintenance is performed, and a policy is intent, not performance. Page: https://cmmcpedia.com/requirements/3-7-1/ ### MA.L2-3.7.2 System Maintenance Control Official Source Material: Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance. Determine if: - [a] tools used to conduct system maintenance are controlled; - [b] techniques used to conduct system maintenance are controlled; - [c] mechanisms used to conduct system maintenance are controlled; and - [d] personnel used to conduct system maintenance are controlled. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Answer four questions in the maintenance policy: which tools, which procedures, which automated jobs, which people. Objective [a] is a list of approved maintenance tools. Objective [b] covers techniques, the documented procedures for how maintenance is done. Objective [c] covers mechanisms, the scripts, scheduled jobs, and remote management platforms that perform maintenance automatically. Objective [d] names the people authorized to do any of it. A page that answers all four is the core of this requirement. The scope is tools brought in for diagnosis and repair, not the operating system's own commands. The requirement's discussion aims at maintenance tools brought in from outside the system boundary for diagnostic and repair actions. Hardware and software test equipment, packet sniffers that capture network traffic, and vendor utilities are the kind it means. Built-in commands such as ping and ipconfig are part of the system and are governed by your access controls, so they need no inventory here. Control means limiting who can reach the tools and watching their use. Approve tools before they are used. Restrict maintenance consoles and administrative portals to the authorized people from [d]. Keep automated jobs where only administrators can edit them, and log what runs. Physical or logical access control on each of the four fronts is what the objectives look for. Your MSP's remote management platform is the maintenance tool to control most carefully. An MSP is a managed service provider, the outside firm that runs IT for you. Name its platform in your system security plan, the document that says how each requirement is met, and approve it deliberately. Put in the service agreement which of the MSP's staff may use the platform against your systems and what it is allowed to do. An agent on every endpoint with an unnamed operator pool is the opposite of controlled personnel under [d]. Keep it proportional in a small shop. One administrator, a documented toolset, and administrative credentials nobody else holds satisfy all four objectives. The requirement asks for control, not a maintenance department. What falls short: - A policy that authorizes IT staff to perform maintenance without naming who that is. Objective [d] controls personnel, and an undefined group controls nobody. Edge cases: - An MSP whose management tooling is documented inside your system boundary is operating part of the system, not visiting it. Its tools and operators still get the [a] through [d] treatment: named, restricted, and logged. Page: https://cmmcpedia.com/requirements/3-7-2/ ### MA.L2-3.7.3 Equipment Sanitization Official Source Material: Ensure equipment removed for off-site maintenance is sanitized of any CUI. Determine if: - [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The laptop sent out for repair is the scenario this requirement exists for. Before any device that has held CUI, Controlled Unclassified Information, leaves your control for repair, the CUI comes off. Whoever works on it has the whole drive regardless of account passwords, so sanitize first or the device does not ship. Sanitize means the data is gone, not locked. Account passwords, multifactor authentication, and a login screen are access controls, and they do not satisfy [a]. Follow NIST SP 800-88: overwrite the media, purge it, cryptographically erase it by destroying the encryption keys, or destroy the media outright. Disk encryption with the keys intact is protection, not sanitization. When you cannot wipe it, remove or destroy the storage. A dead drive cannot be overwritten. Pull the drive and ship the chassis, destroy the failed drive and forfeit the warranty return, or buy the warranty terms that let you keep failed media. Decide which before the failure, because the vendor's return label does not wait on a policy discussion. Cloud-managed devices have a one-step answer. For a laptop enrolled in Microsoft Intune, the cloud service that manages your devices, a remote wipe or Autopilot reset before it ships removes the data. Capture the wipe confirmation as the record. Keep a sanitization record per device. Record the date, device, serial number, method, and who did it. The record turns a claim of sanitizing into evidence for [a], and the assessment guide's examine list names equipment sanitization records outright. What falls short: - Shipping a laptop to the manufacturer with CUI on the disk and pointing at the login password. The repair bench reads the drive directly, so the CUI left your control unsanitized and [a] is not met. Edge cases: - A technician repairing a device on site is not off-site maintenance. Supervise them under MA.L2-3.7.6 and skip the wipe. - A device mailed from a remote employee's home to a repair depot is the same scenario as one leaving the office. The wipe happens before it goes in the box, and the remote worker needs a way to do it or IT does it remotely first. Page: https://cmmcpedia.com/requirements/3-7-3/ ### MA.L2-3.7.4 Media Inspection Official Source Material: Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems. Determine if: - [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Your endpoint protection already does most of this. Write down that you rely on it. Real-time protection scans a diagnostic utility when it lands on disk and scans removable media on access. State in the maintenance policy that diagnostic and test tools are scanned on download or insertion before they run, and that real-time protection enforces it. This requirement extends the malicious code protection of SI.L2-3.14.2 to the tools maintenance brings in. The scenario is the vendor's diagnostic utility. Support sends a tool to collect data from a misbehaving server. Download it, scan it, and verify the hash, the file fingerprint the vendor provides, before it runs on anything in scope. That habit is the whole requirement in practice. Scan before use, not during. A scan that runs while the USB drive is already in use on an in-scope system arrives too late for the word before in [a]. Scan on insertion, before files are opened. If removable media arrives from outside regularly, check it on a separate machine before it ever touches an in-scope system. A finding is an incident. When a scan flags malicious code on maintenance media, the requirement's discussion routes you to incident handling under IR.L2-3.6.1. Quarantine the media, keep it for analysis, and follow the plan. What falls short: - Relying on the vendor's reputation instead of a scan. Objective [a] asks that the media are checked, and trust is not a check. Edge cases: - A maintenance technician's own laptop is diagnostic equipment entering your environment. Confirm it runs current antivirus before it connects, or keep it off your network and have the technician work through your machines. Page: https://cmmcpedia.com/requirements/3-7-4/ ### MA.L2-3.7.5 Nonlocal Maintenance Official Source Material: Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete. Determine if: - [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and - [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Nonlocal maintenance is someone fixing your systems across an external network connection. Your MSP, the managed service provider that runs IT for you, remoting into a server is nonlocal maintenance. So is a firewall vendor connecting to the management interface, and so are you administering the environment from home. The two objectives are simple: the session starts with multifactor authentication, a second proof of identity beyond the password [a], and ends when the work does [b]. Put the multifactor challenge on the path the maintenance rides. A VPN, an encrypted connection into your network, satisfies [a] when it requires multifactor authentication. So does a remote access tool that enforces it, or an administrative portal behind conditional access in Microsoft Entra ID, sign-in rules that check the user and device. What fails is a management port reachable from the internet with a password alone. Get the MSP's multifactor story in writing. When an external provider maintains your systems through its own tooling, its technicians' authentication into that tooling is your [a] evidence. Require it in the service agreement. Capture it in the provider's responsibility matrix, the document that splits security duties between you, so the assessor sees whose control it is and how it is met. Terminate means the session closes when the work is finished. Log out and disconnect at the end of each session, and back the habit with idle timeouts in the remote access tool so an abandoned session closes itself. The termination settings plus a sampled session log answer [b]. A persistent management connection needs a deliberate answer. Remote monitoring and management platforms hold a standing connection that is never complete in the requirement's sense. Document the platform as part of the system, put multifactor authentication on its console, and terminate operator sessions rather than the agent connection. Write that reading into your system security plan, the document that says how each requirement is met, so the assessor is not left to invent one. What falls short: - Remote maintenance over a shared administrator password with no second factor. Objective [a] names multifactor authentication, and a password is one factor. Edge cases: - A screen-sharing session an employee starts and watches, where the technician directs but the employee's own authenticated session does the work, keeps control on your side of the connection. Describe it in the system security plan, because the inbound path a vendor opens on their own is the case this requirement exists for. - Your own administrators working from outside the boundary are performing nonlocal maintenance, and the same VPN and multifactor authentication that satisfy [a] for a vendor satisfy it for them. Page: https://cmmcpedia.com/requirements/3-7-5/ ### MA.L2-3.7.6 Maintenance Personnel Official Source Material: Supervise the maintenance activities of maintenance personnel without required access authorization. Determine if: - [a] maintenance personnel without required access authorization are supervised during maintenance activities. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement covers the outsider fixing your systems, not your own administrators. Maintenance personnel with required access authorization, your IT staff and the vetted provider technicians documented in your program, are not the subject. Objective [a] is about the one-off vendor engineer, the copier technician, and anyone else who works on systems without authorization for the CUI, Controlled Unclassified Information, that they could touch. Supervise those people while they work. Supervision is a person watching, start to finish. Assign an employee who knows what the work should look like to stay with the technician for the duration. Sign the visitor in under your PE.L2-3.10.3 procedure, watch the work, and sign them out. A maintenance log entry naming the technician, the supervisor, and the work performed is the evidence. Temporary credentials beat borrowed ones. When the technician needs to log in, issue a temporary account that expires in hours, scoped to the systems under repair, and remove it when the job closes. Never hand over an administrator's own credentials. A borrowed credential defeats both the supervision and your audit trail. Decide in advance who counts as authorized. Write down which maintenance personnel hold required access authorization: your administrators and the named provider staff. Everyone outside that list gets the supervised treatment, and the list is what lets you answer [a] without improvising at the door. Edge cases: - The HVAC or electrical contractor working in a closet that houses network switches is doing facility work inside your operating environment. Escort them under PE.L2-3.10.3, because the supervision here and the escorting there overlap, and the switch in the HVAC closet is the reason both exist. - When a remote employee's machine is repaired at home by a hired technician, the employee is the supervisor. Lock or sanitize CUI out of reach first so the supervision is workable, and if the device instead leaves for a shop, MA.L2-3.7.3 governs. Page: https://cmmcpedia.com/requirements/3-7-6/ ## Media Protection (MP) ### MP.L2-3.8.1 Media Protection Official Source Material: Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital. Determine if: - [a] paper media containing CUI is physically controlled; - [b] digital media containing CUI is physically controlled; - [c] paper media containing CUI is securely stored; and - [d] digital media containing CUI is securely stored. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement is about media you can pick up, not the drives fixed inside your computers. The assessment guide's examples are paper, microfilm, flash drives, external and removable hard drives, tapes, and optical disks. A drive that takes a screwdriver to remove is still system media, but SC.L2-3.13.16 and your physical protection requirements cover its everyday protection. Aim the controls this requirement adds at what moves: inventory the paper and the portable media that hold CUI, the controlled unclassified information your contract requires you to protect. The four objectives cover two actions across two media types. You control and store, for paper and for digital. Physically controlled means you know what media exist, where each item is, and who has it, which is an inventory plus a check-out habit. Securely stored means a locked drawer, cabinet, or room that only authorized people can open. Satisfy all four combinations. A locked cabinet with no inventory fails [a] and [b]. An inventory of media left on desks fails [c] and [d]. A locked cabinet and a short inventory carry this requirement for a small shop. List each item of media that holds CUI, keep the media in a locked drawer or cabinet, and record when something is taken out and returned. A controlled media library with check-out software does the same thing at a larger organization. You do not need one to meet this requirement. The cheapest approach is to hold less media. Every USB drive you do not issue and every page you do not print is media you do not inventory, store, or track. If your CUI lives in a cloud environment and you prohibit printing and removable media, say so and enforce it. Write the prohibition into your system security plan, the document that describes how your system meets each requirement. The requirement then rests on the few exceptions you actually allow. Know where MP.L2-3.8.1 ends and MP.L2-3.8.2 begins. This requirement is about controlling and storing the physical items. MP.L2-3.8.2 asks whether the people accessing the CUI on those items are authorized to see it. A single procedure that issues encrypted drives to named people from locked storage produces evidence for both. What falls short: - A policy that says media must be secured, with no locked storage location and no inventory behind it. Words alone show nothing for [c] and [d]. - Full-disk encryption offered as the whole answer. Encryption protects a lost drive's confidentiality but physically controls nothing and securely stores nothing, so [a] through [d] still need the inventory and the locked storage. Edge cases: - Internal fixed drives in workstations and servers are not the media this requirement targets. Protect the CUI on them through encryption at rest under SC.L2-3.13.16 and through physical protection of the machines, and keep this requirement focused on paper and portable media. - If you issue encrypted thumb drives as the only authorized removable media, the issuance record is your inventory and the issuance procedure is your physical control. The same evidence serves MP.L2-3.8.2. Page: https://cmmcpedia.com/requirements/3-8-1/ ### MP.L2-3.8.2 Media Access Official Source Material: Limit access to CUI on system media to authorized users. Determine if: - [a] access to CUI on system media is limited to authorized users. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Authorization here is about who may see the CUI, not who may touch the container. A technician can carry a box of backup drives to a storage room without being authorized to read what is on them. The objective asks whether access to the CUI itself, the controlled unclassified information on the media, is limited to authorized users. Your evidence has to name who is authorized and show how everyone else is kept out. Maintain a named list of who is authorized, and put someone in charge of it. The assessment guide's example designates a data owner who approves access and keeps the list of authorized users. A one-page list tied to a contract or project, with the owner's name at the top, answers the assessor's first question. Without it you are arguing that access is limited while unable to say to whom. A written rule with nothing behind it does not limit anything. A policy that says only authorized users may access CUI media, sitting alongside an unlocked drawer, leaves [a] with no mechanism. Pair the rule with the physical controls: locked storage, a check-out log, and racks or server rooms that lock. Racks and server rooms are media storage too. The drives in your servers and the tapes in your backup unit are system media. Locking the server room and limiting who holds the key limits access to the CUI on everything inside it, and the key list doubles as evidence for this objective. What falls short: - A policy stating that unauthorized users must not access CUI media, with no authorized-user list and no locked storage. It gives [a] neither a definition of who is authorized nor a mechanism that limits anyone. Edge cases: - IT staff who handle media as part of their duties do not automatically belong on the authorized-user list for the CUI itself. Decide deliberately: either authorize them and record it, or store the CUI encrypted so that handling the media never exposes the content. Page: https://cmmcpedia.com/requirements/3-8-2/ ### MP.L2-3.8.3 Media Disposal Official Source Material: Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse. Determine if: - [a] system media containing FCI is sanitized or destroyed before disposal; and - [b] system media containing FCI is sanitized before it is released for reuse. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Sanitize everything that held FCI or CUI, and do not parse the wording for an exemption. Federal Contract Information is the information provided by or generated for the government under a contract and not intended for public release. The requirement text says Federal Contract Information because MP.L2-3.8.3 carries the Level 1 practice forward into Level 2. The CUI on your media, the controlled unclassified information you must protect, is contract information too. The practical scope is every item of media that held either. This is also a five-point requirement under 32 CFR 170.24. Under 32 CFR 170.21, its point value bars it from any POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Have the process working before the assessment rather than promising it after. Anchor your methods to NIST SP 800-88 and pick by destination. The assessment guide points to NIST SP 800-88, Guidelines for Media Sanitization, and its techniques of clearing, purging, cryptographic erase, and destruction. Use clear-level sanitization for media reused inside the organization, and purge or destroy anything leaving your control. Write the chosen method for each media type into your procedure so nobody improvises at the recycling bin. You do not need government-grade destruction services for CUI. A method that makes the information unrecoverable is what the requirement asks for. Understand what your erase button actually does before you rely on it. A factory reset or a vendor wipe utility qualifies only if it sanitizes all user-addressable storage. Cryptographic erase works only if the encryption key on the drive itself is destroyed. Deleting recovery keys from where you store them does not touch the key on the drive. For each device type you dispose of, keep the vendor documentation that says what the sanitization function does, or destroy the media instead. Keep a destruction log. The process is invisible without it. Record the date, the media or asset identifier, the method, and who performed or witnessed it. A certificate of destruction from a shredding vendor is a ready-made entry. When an assessor asks how you meet [a], a log with entries is the difference between a described process and a demonstrated one. Paper is in scope, and shredding is the answer. The requirement covers non-digital media, and the guide names removal, redaction, and destruction as sanitization for paper. Cross-cut shredding before disposal or recycling, with the habit written into your procedure, closes [a] for paper. Boxes of intact CUI paper handed to a recycler close nothing. What falls short: - Drives, phones, or disks dropped in the trash or handed to a recycler unsanitized. That is precisely the disposal [a] exists to prevent. - A factory reset you have not verified. If you cannot show what the reset sanitizes, you cannot show the media was sanitized before reuse, and [b] is unmet. - Deleting BitLocker recovery keys from your management console as a claimed cryptographic erase. The media encryption key still lives on the drive, so the data remains recoverable and [a] and [b] are unmet. - A vendor's verbal assurance that a leased device was wiped. Without documentation of the method, there is no evidence for [a]. Edge cases: - Copiers, printers, and scanners with internal storage are system media. At end of lease or life, get the vendor's written confirmation that its wipe meets NIST SP 800-88, or have the storage removed and destroyed. - A drive whose contents you cannot reconstruct gets sanitized as if it held CUI. A purge-level method such as the drive's built-in sanitize command settles the question regardless of what was on it or whether it was encrypted. Page: https://cmmcpedia.com/requirements/3-8-3/ ### MP.L2-3.8.4 Media Markings Official Source Material: Mark media with necessary CUI markings and distribution limitations. Determine if: - [a] media containing CUI is marked with applicable CUI markings; and - [b] media containing CUI is marked with distribution limitations. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Mark the removable media and the paper, not the fleet of laptops. The media in this family is paper, USB drives, external drives, and optical disks. A drive fixed inside a laptop is part of the system. A sticker labeling the lid CUI, controlled unclassified information, marks nothing the requirement covers and advertises the machine as a target. Put labels on the things that detach and circulate. Carry markings forward. Do not invent them. You are an authorized holder of CUI, not the designating agency that marked it in the first place. Documents and drawings arrive from the government or your prime contractor already carrying their banner and distribution statement. Print and copy them with the markings intact, and write that carry-forward rule into your policy. A DoD distribution statement on an incoming drawing is a distribution limitation on its face, which is exactly what [b] asks for. Mark your own output as CUI only where the contract directs it. Small media get the minimum marking. A USB drive has no room for a full banner. Label it CUI or CONTROLLED plus the designating agency, and keep the detailed category and dissemination markings on the documents inside. That minimum comes from the marking guidance of NARA, the federal agency that runs the CUI program, and satisfies both objectives for space-limited media. Objectives [a] and [b] are two different marks. The CUI banner tells a reader the information is controlled. The distribution limitation tells them who may receive it. A drive labeled CUI with no indication of distribution meets [a] and leaves [b] open. Pair the control marking with the distribution statement or a named program restriction. What falls short: - A logon banner offered as the marking for media. It marks a login session on a system, not the paper or the drive, so it shows nothing for [a] or [b]. - Encrypted but unmarked USB drives. Encryption protects the content and marks nothing, so the drive still needs its CUI label for [a]. Edge cases: - CUI arrives from your prime contractor unmarked. You cannot fix the sender's marking failure, so protect the information as CUI, ask the sender to correct the marking, and keep the request as evidence. - One drive holds several categories of CUI. Mark the drive CUI or CONTROLLED with the designating agency, and let the files inside carry their own category markings, because small media need not list every category. - When shipping media, mark the media itself, not the outer package. An envelope or box announcing CUI contents defeats the purpose, because the marking rules put the banner on the item inside. Page: https://cmmcpedia.com/requirements/3-8-4/ ### MP.L2-3.8.5 Media Accountability Official Source Material: Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas. Determine if: - [a] access to media containing CUI is controlled; and - [b] accountability for media containing CUI is maintained during transport outside of controlled areas. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define your controlled areas before you argue about transport. Objective [b] only applies outside of controlled areas, so the boundary has to exist on paper first. Say in your system security plan, the document that describes how your system meets each requirement, which rooms, floors, or buildings are controlled and by what mechanism. Inside that line, MP.L2-3.8.1 and MP.L2-3.8.2 govern. The moment media crosses it, [b] wants a record of who has the media and where it is going. Accountability is a record, and a transport log is the simplest one. The log records who took which item, when, to where, and when it came back. A sign-out sheet next to the media cabinet or a ticket in your help desk system both work. The guide's accountability language is about restricting transport to authorized people and keeping explicit records of the movement, which is a log by any name. Encrypt what travels, and the loss becomes an inconvenience instead of an incident. The guide names locked containers and cryptography as the transport controls. FIPS validation is the federal program that certifies encryption modules. A FIPS-validated encrypted drive that goes missing in a taxi is a recoverable event. Encryption does not replace the accountability record, but it is the control that matters most when the record says the media is gone. Shipped media gets packaging, a named recipient, and a tracking number. The assessment guide's example is exactly this: tamper-evident packaging, a specific addressee, a reputable carrier, and the tracking number shared with the recipient. That paper trail is [b] for anything you cannot hand-carry. Hand-carried media stays in your personal possession. A drive or a tube of drawings you carry is under direct control only while it is actually with you. Do not check it as luggage. Do not leave it in a car. Log it out and back in like any other transport. Edge cases: - Hybrid workers who carry laptops or drives home cross the controlled-area boundary twice a day. Issue encrypted devices, cover the movement in policy rather than logging every commute, and handle the home work site itself under PE.L2-3.10.6. - Backup tapes rotated to offsite storage are transport outside controlled areas every cycle. Encrypt the tapes, log each rotation, and the same evidence also serves MP.L2-3.8.6 and MP.L2-3.8.9. Page: https://cmmcpedia.com/requirements/3-8-5/ ### MP.L2-3.8.6 Portable Storage Encryption Official Source Material: Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards. Determine if: - [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement gives you two ways to meet its one objective, and encryption is the better one. CUI, controlled unclassified information, on digital media in transport is either encrypted or wrapped in physical safeguards such as a locked container under authorized custody. Encryption is cheaper, does not depend on anyone's vigilance, and keeps protecting the data after the physical safeguard fails. Reserve the physical route for media that genuinely cannot be encrypted. Use FIPS-validated cryptography, because the assessor will ask. The assessment guide's considerations ask whether the cryptographic mechanisms comply with FIPS 140-2, the federal standard for encryption modules. SC.L2-3.13.11 requires FIPS-validated cryptography wherever encryption is what protects CUI confidentiality. A hardware-encrypted drive with a FIPS 140 validation certificate is the clean answer: buy it, record the certificate number, and issue it through your MP.L2-3.8.1 inventory. This requirement is the backstop for MP.L2-3.8.5. Accountability tells you a drive is missing. Encryption decides whether that matters. The guide states the intent directly: protect against the situation where control of the media fails through loss. Treat the two as one procedure: sign out the encrypted drive and log the transport. Backups leaving the building count as transport. Tapes or drives couriered to offsite storage carry CUI outside your controlled areas. Enable your backup software's encryption for anything sent offsite, and confirm the mechanism is FIPS-validated rather than assuming it. What falls short: - Encryption that is not FIPS-validated, with no physical safeguard in place. The confidentiality of CUI rests on validated cryptography under SC.L2-3.13.11, so an unvalidated mechanism alone leaves [a] exposed. Edge cases: - Media moved between rooms inside your own controlled facility is not in transport outside controlled areas, so the requirement does not bite there. Encrypt it anyway, because the drive that never leaves the building eventually does. Page: https://cmmcpedia.com/requirements/3-8-6/ ### MP.L2-3.8.7 Removable Media Official Source Material: Control the use of removable media on system components. Determine if: - [a] the use of removable media on system components is controlled. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This requirement restricts what plugs into your systems. MP.L2-3.8.1 restricts who touches your media. The assessment guide draws the contrast itself. Here the question is whether a flash drive or external disk can be used on a workstation at all, and under what rules. Answer it with a deliberate stance: which device types are allowed, on which systems, for whom. Default deny, allow by exception, enforce with software. A policy is a control, but a policy plus enforcement is a control an assessor can test. Block removable storage through your endpoint management or endpoint protection tooling, then allow specific issued devices by exception for people with a business need. The exception list doubles as your MP.L2-3.8.8 ownership record. Nontechnical controls are legitimate where technical ones do not fit. The guide accepts policies, procedures, and rules of behavior as controls, and physical measures like port blockers on machines that cannot run device-control software. A shop floor machine with a policy sign-off and a physical port lock is controlled. A network with no stance on USB drives is not. This is a five-point requirement, so settle it before assessment. 32 CFR 170.24 lists MP.L2-3.8.7 among the five-point derived requirements. Under 32 CFR 170.21, its point value keeps it off any POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Device control in a modern endpoint suite is hours of work, not a project. Do it early. What falls short: - A policy forbidding personal USB drives on a network where every port accepts every device and nothing is logged. With neither enforcement nor auditing, there is no way to show the use of removable media is actually controlled under [a]. Edge cases: - Hot-swappable server drives come out without tools, so treat them as removable media. A locking bezel over the drive bays is a clean control: the drives stay usable for maintenance and their removal is physically gated. Page: https://cmmcpedia.com/requirements/3-8-7/ ### MP.L2-3.8.8 Shared Media Official Source Material: Prohibit the use of portable storage devices when such devices have no identifiable owner. Determine if: - [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The owner can be the organization, a team, or a person. Every device must trace to someone accountable. The guide names individuals, organizations, and projects as acceptable owners. The common pattern is company-owned drives issued to named people, with the issuance recorded. A device inventory with an owner column is the evidence for [a]. The found USB drive is the scenario this requirement exists for. A drive in the parking lot has no identifiable owner and never gets plugged in. Say so in policy, cover it in awareness training, and tell people to hand any drive they find to IT. The assessment guide's own example is exactly this drill. Back the prohibition with a technical default. A rule the computer enforces works better than a rule people must remember. Configure device control so unknown storage devices are blocked or read-only and only issued, inventoried drives can be written to. This is the same mechanism that MP.L2-3.8.7 uses, so one configuration serves both requirements. MP.L2-3.8.8 tightens MP.L2-3.8.7 rather than repeating it. MP.L2-3.8.7 decides which kinds of media are allowed at all. This requirement adds that even an allowed kind is prohibited when the specific device cannot be traced to an owner. Your MP.L2-3.8.7 exception list satisfies it automatically as long as every excepted device has an owner on record. What falls short: - A device-control allowlist keyed to device models rather than issued devices. Allowing any drive of an approved model says nothing about who owns the one plugged in, so [a] is unmet for unowned devices of that model. Page: https://cmmcpedia.com/requirements/3-8-8/ ### MP.L2-3.8.9 Protect Backups Official Source Material: Protect the confidentiality of backup CUI at storage locations. Determine if: - [a] the confidentiality of backup CUI is protected at storage locations. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Start by listing every place a backup of CUI lands. The list includes server images, file share snapshots, cloud tenant retention, the network storage box in the closet, the external drive someone rotates, and a line-of-business vendor's own backup. The requirement covers the confidentiality of backup CUI, the controlled unclassified information you protect, at each storage location. The location you forgot is the finding. If CUI is in a system, its backups hold CUI. Encryption, access control, and physical security are all valid. Use encryption as the default. The guide accepts cryptographic mechanisms or physical controls at the storage location. Encrypting backup data with a FIPS-validated mechanism, encryption the government has certified, answers the assessor's follow-up question before it is asked. A locked room plus tightly limited access is the alternative for on-premises media you cannot encrypt. Cloud backup inheritance is real, but only as complete as your backup inventory. If every backup of CUI lives inside your FedRAMP-authorized cloud environment, one the federal government has assessed and approved, the provider's protections can carry this requirement. The claim collapses the moment CUI is also backed up somewhere you did not account for. The inventory from the first lesson is what makes the inheritance defensible. Inheritance is documented, not declared. Get the provider's customer responsibility matrix, the document that splits security duties between the provider and you. Find the rows covering backup storage protection. Cite them in your system security plan, the document that describes how your system meets each requirement, next to what remains yours to do. A bare statement that the cloud handles everything is not evidence and invites the questions it cannot answer. What falls short: - Unencrypted backup drives or tapes on an office shelf. Nothing protects the confidentiality of the backup CUI at that storage location, so [a] is unmet. - A claim of full inheritance from a cloud provider while a local NAS also receives backups. The unaccounted location leaves [a] unmet regardless of how good the cloud story is. Edge cases: - Backup media in transit to an offsite location is covered by MP.L2-3.8.5 and MP.L2-3.8.6, and this requirement picks up when the media arrives. Encrypting the backups once satisfies all three without separate mechanisms. - In a Microsoft 365 tenant, platform retention and recycle mechanisms may be the only backup you have. If you add a third-party backup tool, its storage location becomes a CUI location that needs the same FedRAMP scrutiny as the tenant itself. Page: https://cmmcpedia.com/requirements/3-8-9/ ## Personnel Security (PS) ### PS.L2-3.9.1 Screen Individuals Official Source Material: Screen individuals prior to authorizing access to organizational systems containing CUI. Determine if: - [a] individuals are screened prior to authorizing access to organizational systems containing CUI. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The requirement fixes when screening happens, not what it is. The requirement prescribes no particular background check. Define the screening for each role that touches CUI, the controlled unclassified information your contract requires you to protect. Ground it in the position's risk, and apply it before the person can reach systems containing CUI. A criminal background check plus employment verification is a defensible baseline for general CUI access. Your existing hiring process is most of the control. Write down what already happens before an offer: background check, reference checks, verification of eligibility to work. Then add the one connection this requirement cares about: CUI system access is not authorized until the screening is complete. HR runs the screening. The control lives in the handoff to IT. Sequence is the evidence. Objective [a] turns on the words prior to. For each person with CUI access, keep records showing the screening finished before the account was authorized. Make account creation wait on an explicit all-clear from HR, and the evidence generates itself. Handle existing employees by policy, not by re-running their hiring. Apply the documented screening to everyone authorized after the policy exists. For staff who already hold access, record what screening they received at hire and state in the policy that it satisfies your standard. Re-screening a twenty year employee is a choice you can make, not one the requirement forces. Export controlled CUI raises the screening floor. Some CUI carries export control markings such as ITAR, the regulation covering defense articles and technical data. Export control law restricts access by nationality. For that CUI, screening also verifies the person is a U.S. person or holds the required authorization. Fold that verification into the same pre-access gate. What falls short: - System access granted on day one while the background check is still pending. The screening did not happen prior to authorization, so [a] fails on sequence alone. Edge cases: - Contractors and staffing agency personnel with accounts on your systems are individuals under [a]. Screen them through your process, or obtain and keep evidence that their employer's documented screening meets your standard. Page: https://cmmcpedia.com/requirements/3-9-1/ ### PS.L2-3.9.2 Personnel Actions Official Source Material: Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers. Determine if: - [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established; - [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and - [c] the system is protected during and after personnel transfer actions. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Write the offboarding procedure first. It is objective [a] verbatim. A one page procedure naming who tells whom, what gets disabled, what gets collected, and by when satisfies [a] and drives everything else. PS.L2-3.9.2 is a five point requirement under 32 CFR 170.24. Under 32 CFR 170.21, a five point requirement can never sit on a POA&M, the plan of action that buys time for unfinished requirements. A missing procedure is therefore expensive. Disable access the day employment ends, and earlier when the termination is for cause. Disable the account in your identity provider, the service that checks user sign-ins. Revoke active sessions so open logins die with the account. Collect devices and badges, and change any shared credentials the person knew. The assessment guide allows accounts to be disabled before the individual is notified when the termination is for cause. Coordinate the disable time with HR instead of acting after the fact. Transfers are the half of this requirement that fails quietly. Objective [c] covers the employee who stays but changes roles. Remove the old role's access on the transfer date instead of stacking new access on top. CUI is the controlled unclassified information your contract requires you to protect. A move into a role without CUI contact means CUI access ends, including physical access to spaces where CUI lives. The control is the HR to IT signal, so build the trigger and the backstop. Access that outlives employment is what happens when IT learns of a departure late. Make the HR action open an IT ticket, by automation or by checklist. Compare active accounts against the current roster on a schedule, so anything the trigger missed gets caught. The exit conversation is part of protecting CUI. Remind the departing person that nondisclosure obligations cover CUI after employment, and record that the reminder happened. When no exit interview is possible, as with job abandonment, run the access and property steps anyway and document why the interview did not occur. What falls short: - HR paperwork completed while the account stays active until someone remembers to call IT. Objective [b] asks that access termination is consistent with the personnel action, and an open ended lag is not. - Disabling the named account while shared passwords the person knew stay unchanged. Credentials include everything the person could still use, so [b] is only partly met. Edge cases: - A short temporary reassignment does not demand the full treatment. The assessment guide applies this requirement to personnel actions that are permanent or of extended duration, so document the threshold your process uses. - Extended leave is not a termination, but a long absence with live access is a risk you can close the same way. Disable the account for the duration and restore it on return. Page: https://cmmcpedia.com/requirements/3-9-2/ ## Physical Protection (PE) ### PE.L2-3.10.1 Limit Physical Access Official Source Material: Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals. Determine if: - [a] authorized individuals allowed physical access are identified; - [b] physical access to organizational systems is limited to authorized individuals; - [c] physical access to equipment is limited to authorized individuals; and - [d] physical access to operating environments is limited to authorized individuals. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Objective [a] is a list. Write it before you buy a lock. Name the people authorized for physical access to each controlled area: the building, the office, the server closet. The rest of the requirement limits access to the people on that list, so the list has to exist, stay current, and match who actually holds keys and badges. Layer the physical controls to match your facility. A locked exterior door, a lockable office, and a locked closet or rack for network equipment cover [b] and [c] in a small office. Badge readers and electronic locks do the same job with better records. They are worth buying when headcount makes keys unmanageable, not before. The operating environment is anywhere CUI can be seen or heard. CUI is Controlled Unclassified Information, the government information your contract obliges you to protect. Objective [d] extends the requirement past the server room. It covers the offices, work areas, and print stations where CUI shows on screens, sits on desks, or comes up in conversation. Define those areas and limit access to them the same way. Put printers where output is not exposed, or prohibit printing CUI outright. An output tray in a shared hallway hands CUI to anyone walking past, which fails [c] for that device. Move the printer inside the controlled area. Or write and train a policy that CUI is never printed, and post a sign at the printer saying so. A shop floor does not need floor-to-ceiling walls. Fence and lock an enclosure for the equipment inside an access-controlled building. Lock the CUI drawings in a cabinet at the end of the shift. Those layers limit access in a way you can demonstrate. Each layer needs a lock and a defined set of key holders. The material of the barrier matters less than who can pass it. Policy plus trained people is a real control where hard barriers fail. A manufacturing bay with doors open for ventilation still passes when signage marks the boundary, visitors sign in and are escorted, and employees are trained to challenge strangers. Write the reasoning down so the assessor sees a decision, not an oversight. What falls short: - An authorized access list that exists only as common knowledge. Objective [a] asks for identified individuals, and identification you cannot produce is not identification. - Key issuance with no record of who holds what. Without the record you cannot show access is limited to the authorized list, which undercuts [b] through [d]. Edge cases: - Employees working from home are governed by PE.L2-3.10.6, which covers alternate work sites. This requirement covers your own facilities. - Employees with no CUI role who sit inside the controlled area either join the in-scope population, with the same screening and training as everyone else, or are treated like escorted visitors. Pick one and document it. - Manufactured parts are not CUI, because CUI is information. The drawings, travelers, and specifications on the floor are what need the locked cabinet. Page: https://cmmcpedia.com/requirements/3-10-1/ ### PE.L2-3.10.2 Monitor Facility Official Source Material: Protect and monitor the physical facility and support infrastructure for organizational systems. Determine if: - [a] the physical facility where organizational systems reside is protected; - [b] the support infrastructure for organizational systems is protected; - [c] the physical facility where organizational systems reside is monitored; and - [d] the support infrastructure for organizational systems is monitored. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Protect and monitor are two duties across two subjects. Objectives [a] and [b] ask that the facility and the support infrastructure are protected: locks, barriers, controlled entry. Objectives [c] and [d] ask that both are monitored: some way of knowing who came near and when. Cover each pairing deliberately, because a locked closet nobody can account for fails the second half. Support infrastructure means the cabling, closets, and panels your systems depend on. Lock the wiring closet, run cable through conduit or trays where it crosses uncontrolled space, and keep spare network jacks disconnected or locked down. The requirement's discussion names exactly these measures, and they are cheap. Monitoring does not mean cameras watched around the clock. Badge logs with alerting on unauthorized attempts count as monitoring. So do an alarm system armed after hours, a reception desk during business hours, and a key sign-out log for the wiring closet. Cameras add coverage and timestamps, and a small office can meet [c] and [d] without them. Scope stops at what you control. The requirement does not extend to the power utility or the guards at a substation. It is also not about uptime: NIST SP 800-171 protects confidentiality, so redundant power and fire suppression are risk decisions, not obligations here. Ask of any proposed measure whether losing it would expose CUI, the Controlled Unclassified Information you protect, and spend accordingly. Multi-tenant buildings are where this requirement fails. A network closet shared with the landlord or other tenants, with your firewall in it and no way to tell who enters, is the recurring gap. Put your equipment in a locked cabinet inside the shared space, control that key, and get notification of building staff access written into the lease terms. What falls short: - Pointing at network controls, such as 802.1x port authentication, as facility protection. Logical controls do not keep hands off hardware, so they answer nothing under [a] through [d]. Edge cases: - A home office that houses in-scope servers or network equipment is a facility for this requirement. A locked room, a locked cabinet inside it, and household alarm or camera coverage scale the controls down without waiving them. - When the demarcation point, the carrier's handoff to your wiring, sits in a landlord-controlled room, document what you control, what the building controls, and how you would learn of access. Showing you addressed the space beats pretending it is out of scope. Page: https://cmmcpedia.com/requirements/3-10-2/ ### PE.L2-3.10.3 Escort Visitors Official Source Material: Escort visitors and monitor visitor activity. Determine if: - [a] visitors are escorted; and - [b] visitor activity is monitored. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: A visitor is anyone without permanent access authorization, and every visitor gets an escort. Objective [a] means an authorized person accompanies visitors through the controlled area. [b] means their activity is watched. The escort satisfies both when they stay with the visitor from sign-in to sign-out, because escorting is monitoring. This requirement can never sit on a POA&M. A POA&M, a plan of action and milestones, is the document that defers a few unmet requirements past the assessment. 32 CFR 170.21(a)(2)(iii) lists PE.L2-3.10.3, PE.L2-3.10.4, and PE.L2-3.10.5 among the six Level 2 requirements barred from one. A Not Met on any of them denies even a conditional CMMC status. Escorting visitors is also one of the cheapest requirements in the rule to meet, which makes it a bad place to lose an assessment. Regular vetted outsiders are not visitors. Define them as authorized personnel. The cleaning crew, a badged subtenant, and contractors with standing access can be vetted, trained as needed, added to the facility access list as third-party personnel, and issued credentials. The escort duty then applies to actual visitors. What you cannot do is wave regulars through without either vetting or escort. Make visitors identifiable at a glance. A visitor badge or a distinct lanyard tells every employee who should have an escort. Pair it with a trained norm that employees stop and redirect an unescorted stranger. In a small office where everyone knows everyone, the written procedure still exists even when a badge adds little. The friend in the hallway is the test. An employee's friend walking unescorted toward the lunchroom is exactly the situation this requirement addresses. The procedure that passes: walk them back to reception, sign them in, and assign an escort. Then treat the door that let them in as the finding it is. What falls short: - A sign-in sheet with no escort. Logging a visitor feeds PE.L2-3.10.4 and leaves [a] here unmet, because nobody accompanied them. Edge cases: - Cleared personnel arriving under a visit authorization request, the notice their security office sends ahead to vouch for them, can be defined in your policy as authorized personnel rather than visitors. Word it as a definition of authorized personnel, not as an exemption from the escort policy, so the objective still reads as met. - An after-hours cleaning crew with nobody present works only when the crew is vetted as third-party personnel and CUI, Controlled Unclassified Information, is locked away: screens locked, media and papers in cabinets. If CUI stays out overnight, someone stays with them. Page: https://cmmcpedia.com/requirements/3-10-3/ ### PE.L2-3.10.4 Physical Access Logs Official Source Material: Maintain audit logs of physical access. Determine if: - [a] audit logs of physical access are maintained. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: A paper sign-in sheet is a compliant audit log. The requirement's discussion accepts procedural logs, automated logs, or a combination. A visitor logbook at the door plus badge system records for employees covers a typical office, and neither requires new spending. Log the controlled areas, not just the front door. Physical access points include interior areas with supplemental controls, such as a server room. Where the room has its own badge reader, its log answers this. Where it has a key, a key sign-out sheet does. Cameras can be the log. Motion-triggered footage where every clip carries a timestamp is a chronological record of access. For a facility with several entrances and no badge readers, timestamped camera coverage of the entry points is a workable log that asks nothing of anyone day to day. Define a retention period and honor it. The requirement says maintain and leaves the period to you. Pick a number, write it into the procedure, and keep the logs that long, because the assessor checks your practice against your own stated period. Maintained means reviewable, not reviewed. No objective requires a routine review of these logs. Keep them retrievable so an investigation can reconstruct who was where. A folder of sign-in sheets meets that bar. This is another of the six requirements 32 CFR 170.21 keeps off any POA&M. A POA&M, a plan of action and milestones, defers an unmet requirement past the assessment, and a missing log cannot be deferred that way. Have the log running before the assessment, not after it. A sheet of paper and a pen start the evidence today. What falls short: - System logon records offered as physical access logs. Logging into a laptop shows where the account was used, not who entered the facility, so [a] is unanswered. Edge cases: - Sign-out is not required by the objective, because entry records alone are an audit log of access. Add exit tracking when it is useful to you, not because the requirement demands it. - A one-person home office can keep a simple log: entries for days when others were present, plus a statement of how nobody could enter otherwise. Describe the key control that backs the statement. Page: https://cmmcpedia.com/requirements/3-10-4/ ### PE.L2-3.10.5 Manage Physical Access Official Source Material: Control and manage physical access devices. Determine if: - [a] physical access devices are identified; - [b] physical access devices are controlled; and - [c] physical access devices are managed. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Inventory the keys, badges, fobs, and combinations first. Objective [a] asks that physical access devices are identified: what devices exist, which doors they open, and who holds each one. A spreadsheet with device, area, holder, and issue date answers it. Control is who gets one. Manage is what happens after. Issue devices only to people on the authorized access list. Keep spares locked up, and record every issuance for [b]. Then keep the system true over time for [c]. Collect devices at departure, and deactivate lost badges. Change combinations when someone who knows them leaves, and re-key when a perimeter key goes unreturned. Hand out as few perimeter keys as possible. Every key to the outer door is a future re-keying decision when it fails to come back. Fewer holders makes departures cheap, and a badge system makes them free, since revocation is a click instead of a locksmith. An unreturned key is a decision point, not a shrug. When a departing employee does not return a key, either re-key the affected locks or record the accepted risk with a reason. What fails is an inventory that says twelve keys and a drawer that holds nine with no explanation. This requirement is barred from any POA&M. A POA&M, a plan of action and milestones, defers an unmet requirement past the assessment. 32 CFR 170.21(a)(2)(iii) puts PE.L2-3.10.5 on the same barred list as PE.L2-3.10.3 and PE.L2-3.10.4. The device inventory and issuance records have to exist on assessment day, and they are an afternoon of work in a small facility. What falls short: - A badge system with no matching inventory of mechanical keys. The badge log covers badge holders, and the master key in a manager's drawer is a physical access device under [a] too. Edge cases: - Landlord-held master keys are devices you do not control. Document them, put your sensitive areas behind locks the landlord does not hold where the lease allows, and cover building staff access in the lease terms. Page: https://cmmcpedia.com/requirements/3-10-5/ ### PE.L2-3.10.6 Alternative Work Sites Official Source Material: Enforce safeguarding measures for CUI at alternate work sites. Determine if: - [a] safeguarding measures for CUI are defined for alternate work sites; and - [b] safeguarding measures for CUI are enforced for alternate work sites. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: A remote work policy is the backbone of both objectives. CUI is Controlled Unclassified Information, the government information your contract obliges you to protect. Objective [a] asks that safeguarding measures for it are defined for alternate work sites. A policy naming the approved site types and the required protections defines them. Objective [b] asks that they are enforced. Training with a signed acknowledgment plus the technical controls that travel with the laptop enforce them. The measures that matter travel with the device and the habits. Encrypt the whole disk, and require a screen lock. Reach your environment through a VPN, an encrypted connection into your network, or through conditional access, sign-in rules that admit only trusted users and devices. Bar household use of the device, and lock up any printed CUI. Enforce the technical half through management tooling such as Microsoft Intune, so the control does not depend on the user remembering. Calibrate to CUI, not to classified. CUI at an alternate work site needs a controlled environment: walls, a door that closes, and screens positioned away from casual view. It does not need a windowless room or defenses against surveillance. Rules imported from classified handling produce a policy nobody follows, and an unenforced rule fails [b]. Decide the coffee shop question by policy. Working with CUI in public spaces is easiest to prohibit outright: homes and hotel rooms with a lockable door qualify as work sites. The airport lounge does not. A written line enforced through training does the job. A geolocation project does the same job at many times the cost. Cloud-native and fully remote organizations own this requirement outright. A provider's data center controls can cover much of the rest of this family, but no provider controls your employee's kitchen table. For a fully remote organization every work location is an alternate work site, which makes this small requirement most of your physical protection story. Give it the corresponding weight. What falls short: - A policy that tells remote workers to use good judgement. Objective [a] asks for defined measures, and judgement is not a definition. - Defined measures with nothing making them happen. Without enforced device controls or a training and acknowledgment trail, [b] has no evidence. Edge cases: - Printing CUI at home is either prohibited in the policy or comes with the full paper lifecycle: locked storage while the paper exists, and approved destruction when it should not. Decide which, and write it down. - A government facility used as a work site brings the government's own controls. Note the arrangement in your system security plan, the document that says how each requirement is met, instead of inventing home-office rules for it. Page: https://cmmcpedia.com/requirements/3-10-6/ ## Risk Assessment (RA) ### RA.L2-3.11.1 Risk Assessments Official Source Material: Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI. Determine if: - [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and - [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Objective [a] is one sentence in a policy: write down the frequency. An undefined frequency fails [a] before anyone looks at the assessment itself. The CMMC rule at 32 CFR 170.4 defines periodically as at least annually, so annual is the floor. State the frequency, then show assessments dated to match it for [b]. Assess the risks that come from operating a system that handles CUI, not every risk your company has. CUI is the controlled unclassified information your contract requires you to protect. The requirement scopes itself: risk resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI. The risks in scope are unauthorized access, disclosure, spills, compromised credentials, and a vendor with access it should not have. A disaster recovery annex about earthquakes is a different exercise, and padding the assessment with it does not answer [b]. A dated document is the deliverable, not a platform. The guide's method is threats, vulnerabilities, likelihood, and impact, with NIST SP 800-30, the government's risk assessment guide, as the reference. A few pages that walk your CUI environment through that lens, signed and dated, repeated on your defined frequency, meets the requirement. Buy a risk register tool when the volume of findings demands one, not to have something to show. Reuse the company-wide risk assessment where the infrastructure is shared. If your CUI environment runs in the same building, on the same network, with the same staff as everything else, one assessment can serve both. Extend it with the CUI-specific risks rather than duplicating the whole exercise for the CUI environment. This assessment is what the rest of the family points back to. RA.L2-3.11.3 remediates vulnerabilities in accordance with risk assessments, and the plans of action under CA.L2-3.12.2 flow from what the assessment finds. Skip it and those requirements lose the document they depend on. Do it and prioritization decisions elsewhere become defensible instead of arbitrary. What falls short: - A generic corporate risk register that never mentions CUI or the system that handles it. It does not assess the risk the requirement names, so [b] is unmet. - A policy that says risk is assessed periodically without a number. Objective [a] asks for a defined frequency, and periodically is not one. Edge cases: - Clearly defined system boundaries come first, and the guide calls them a prerequisite. If your CMMC scope is still moving, settle it before assessing risk, or the assessment describes a system that no longer exists by the time an assessor reads it. Page: https://cmmcpedia.com/requirements/3-11-1/ ### RA.L2-3.11.2 Vulnerability Scan Official Source Material: Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. Determine if: - [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined; - [b] vulnerability scans are performed on organizational systems with the defined frequency; - [c] vulnerability scans are performed on applications with the defined frequency; - [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and - [e] vulnerability scans are performed on applications when new vulnerabilities are identified. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define a frequency you will never miss, then scan more often than it. Objective [a] wants a number and [b] and [c] want scans dated to match it. Write the frequency you can hold through vacations, outages, and the laptop that stayed in a trunk for a month. Then run your actual scans more often. A quarterly commitment executed weekly never produces a gap between policy and record. Scan the whole environment the CUI lives in, not just the machines that touch CUI. CUI is the controlled unclassified information your contract requires you to protect. The guide sweeps in servers, workstations, laptops, virtual machines, network gear, and printers. It says directly that everything in the CMMC assessment scope gets scanned, including laptops that rarely see the office network. A scanner installed on each machine as an agent reaches the remote machines a network scanner never will. Have a plan for one hundred percent of assets, wherever they sit. Applications hold their own objective letters, so scan them on purpose. Objectives [c] and [e] exist because an operating-system scan does not see the web application or the database running on the box. A credentialed scan, one that logs in to the machine it examines, reaches the installed software. A web application needs a scan aimed at it. If you build custom software, the guide expects analysis of it, with source code scanning as the accessible starting point. A scanner you triage beats a platform you ignore. A free or modest tool run on schedule, with findings reviewed and fed into remediation, is a working vulnerability management program. A subscription generating reports nobody opens is a shelf ornament that fails [b] through [e] the first time an assessor asks what you did about a finding. Pick the tool you will actually operate. This is a five-point requirement under 32 CFR 170.24. Under 32 CFR 170.21, its point value keeps it off any POA&M, the plan of action that buys time for unfinished requirements. A modest working program now outranks a grand plan for later. Objectives [d] and [e] ask what happens when the world changes between scans. Two mechanisms cover it: a scanner that updates its vulnerability feed before every scan, and the demonstrated ability to run an off-cycle scan when a severe vulnerability breaks. Keep the report from the last time a headline vulnerability sent you scanning. It is the cleanest evidence [d] and [e] can have. What falls short: - A patching cadence offered instead of scan results. Patching is SI.L2-3.14.1, and without scan reports there is no evidence for [b] through [e], because updating software is not the same as verifying what remains vulnerable. - Scans that cover the office subnet while remote laptops are never scanned. In-scope assets went unscanned, so [b] is unmet. - Operating-system scans with no application coverage. Objectives [c] and [e] are separate letters, and they are the ones left open. Edge cases: - A device that cannot accept credentialed scanning, like a firewall whose FIPS mode blocks the access, gets an uncredentialed scan, a manual firmware check against vendor advisories, and a documented limitation. State what you do everywhere it is supported rather than listing what one device cannot do. - Phones and tablets under mobile device management are not what scanners scan in practice. Enforce minimum OS versions and rapid updates through management policy, and document that treatment so the exclusion from scanning is a decision rather than an oversight. Page: https://cmmcpedia.com/requirements/3-11-2/ ### RA.L2-3.11.3 Vulnerability Remediation Official Source Material: Remediate vulnerabilities in accordance with risk assessments. Determine if: - [a] vulnerabilities are identified; and - [b] vulnerabilities are remediated in accordance with risk assessments. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: In accordance with risk assessments means you choose priorities, in writing. The requirement does not demand that every finding be fixed. It demands that what you fix, defer, and accept follows your assessment of risk. Write the rule down: which severity levels get remediated and on what timeline, which can be accepted, and who signs the acceptance. One defensible rule remediates everything high and critical on a set timeline, drives mediums to a recorded fix-or-accept decision, and risk-accepts documented lows. The same behavior with no written rule is just a backlog. Show the full life of a finding, twice. The convincing evidence for this requirement is a pair of examples end to end: a vulnerability appearing in a scan, tracked in a ticket, fixed, and absent from the next scan. Two before-and-after report pairs demonstrate [a] and [b] together better than any process description. Track what you decided not to fix, or the decision looks like neglect. A finding you evaluated and accepted, with the reasoning and an owner recorded, is a met requirement. The same finding sitting unexplained in every quarterly report is an unaddressed vulnerability. Severity ratings from the scanner are the input. Your documented disposition is the evidence. Use the scoring rule for gaps you cannot close on demand. Under 32 CFR 170.24(b)(1), two kinds of gap are still assessed as MET. An enduring exception is MET when your system security plan, the document that describes how your system meets each requirement, describes the exception and its mitigations. A temporary deficiency is MET when an operational plan of action appropriately addresses it. The machine controller that cannot be patched without breaking the machine belongs in the first category, with its isolation described. The fix awaiting a vendor patch belongs in the second. The regulation gives you both paths, so use them instead of hiding the finding. A finding whose exploit conditions do not exist in your environment can be reclassified, after an investigation you write down. When a vulnerability requires a port you have closed, a module you have not installed, or a configuration you do not run, investigate. Record what you checked, and mark the finding not applicable. The documentation is the difference between a risk decision and wishful dismissal. What falls short: - A spreadsheet of scan findings with no policy stating remediation and acceptance criteria. It shows vulnerabilities were identified for [a], but nothing connects what happened next to a risk assessment, so [b] is unmet. - Remediating criticals while medium findings accumulate for years without a recorded decision. Unaddressed is not the same as accepted, and [b] requires the disposition to trace back to risk. Edge cases: - For manufacturing equipment whose operating system cannot be upgraded without breaking the machine, isolate it on a restricted network segment with no internet access. Document it in the system security plan as a specialized asset with an enduring exception whose compensating controls carry the risk argument. Page: https://cmmcpedia.com/requirements/3-11-3/ ## Security Assessment (CA) ### CA.L2-3.12.1 Security Control Assessment Official Source Material: Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. Determine if: - [a] the frequency of security control assessments is defined; and - [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define the frequency in writing, and treat annual as the floor. Objective [a] is a stated frequency, and the CMMC rule at 32 CFR 170.4 defines periodically as at least annually. An annual self-assessment of your implemented controls, documented and dated, satisfies the letter of both objectives. This is a five-point requirement under 32 CFR 170.24. Its point value keeps it off any POA&M, the plan of action and milestones that defers unmet requirements, under 32 CFR 170.21. Build the habit before the assessment year. Assess effectiveness, not existence. The requirement says determine if the controls are effective in their application. That is a harder question than whether you are doing what your system security plan, the document that says how each requirement is met, claims. For each control, ask whether the implementation actually mitigates the risk it is there for. The log review that never finds anything may be looking at the wrong logs. The visitor badge process nobody follows is a control on paper only. Record the judgment, not just a met checkbox. The outputs are documents that feed other requirements. The guide lists them: documented assessment results, proposed new or updated controls, remediation plans, and newly identified risks. The deficiencies you find become the CA.L2-3.12.2 plan of action, and the risks feed RA.L2-3.11.1. An assessment that produces findings and follow-up work is self-evidently real. One that produces a clean sheet every year invites the question of how hard anyone looked. Keep CA.L2-3.12.1 and CA.L2-3.12.3 distinct in your program. This requirement is the scheduled, deliberate look at whether controls are effective as designed. CA.L2-3.12.3 is the ongoing monitoring between those looks. One annual assessment plus a recurring monitoring rhythm covers both. A single activity labeled with both identifiers covers neither, because the evidence for a periodic deep review and for continuous monitoring look different. An exercise can be a control assessment. Testing the incident response plan, restoring from backup, or failing over a system assesses those controls in their application. Fold the results into your assessment record. Planning to evaluate the plan only when a real incident arrives is not an assessment method. It is the absence of one. What falls short: - A system security plan review that asks only whether each control is still being done. It never determines effectiveness, so [b] is unmet. - Assessments that happen when someone remembers. Without a defined frequency, [a] is unmet no matter how good the individual assessments are. Page: https://cmmcpedia.com/requirements/3-12-1/ ### CA.L2-3.12.2 Plan of Action Official Source Material: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. Determine if: - [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified; - [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and - [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This is your operational plan of action, not the assessment POA&M, and confusing the two costs you. The assessment POA&M is the plan of action and milestones defined in 32 CFR 170.4 and constrained by 32 CFR 170.21, and it exists only around a CMMC assessment. It is limited to select low-weight requirements and must close out within 180 days of the conditional status date. The plan this requirement asks for is the standing document you run all year to track deficiencies and vulnerabilities to closure. Keep them as separate artifacts with separate names, because they answer different questions under different rules. The operational plan of action is also how a temporary deficiency scores as MET. 32 CFR 170.24(b)(1)(ii) states that temporary deficiencies appropriately addressed in operational plans of action, meaning the plan includes deficiency reviews and shows progress toward correction, are assessed as MET. Take the common encryption gap: a required patch moves you off the FIPS-validated module version, the exact build the government certified, while revalidation is pending. That gap does not have to fail the affected requirement if this document exists and shows the deficiency being worked. That makes CA.L2-3.12.2 one of the highest-leverage requirements in the whole set. Every entry gets an owner, steps, and dates. The guide's checklist is ownership, clear actionable steps or milestones, responsibility for each step, milestones to measure progress, and completion dates. Format is irrelevant: a spreadsheet tab, a ticket type in your tracker, or a document all work. Content and follow-through are what the objectives test. Objective [c] is the one that fails: the plan must be worked, not just written. Entries that sit unchanged through four quarterly reviews show a plan that was developed for [b] and never implemented for [c]. Review the plan on a schedule. Update milestones as they pass, and close entries with evidence. Have someone other than the fixer verify the fix where it matters. Feed it from everything that finds problems. Scan findings from RA.L2-3.11.2, deficiencies from CA.L2-3.12.1 assessments, incident lessons, and audit findings all identify the items [a] asks about. One intake and one document beats a scatter of lists. Not every flaw earns an entry. Fix the one-off misconfiguration on the spot. Reserve the plan for deficiencies that take time, resources, or coordination, plus the recurring problem that needs a root-cause task. What falls short: - A plan of action written once for a gap assessment and never touched again. Static entries with expired dates show [c] was never done. - Findings tracked only inside the vulnerability scanner console. The scanner shows detections, not decisions, and nothing demonstrates a developed plan with owners and milestones for [b]. Edge cases: - A permanent gap that will never close, such as a machine that cannot run endpoint protection without breaking, does not belong on a plan of action at all. That is an enduring exception: describe it and its mitigations in your system security plan, the document that says how each requirement is met, where 32 CFR 170.24(b)(1)(i) assesses it as MET. Page: https://cmmcpedia.com/requirements/3-12-2/ ### CA.L2-3.12.3 Security Control Monitoring Official Source Material: Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. Determine if: - [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Ongoing means a defined rhythm faster than your annual assessment. CA.L2-3.12.1 is the scheduled full assessment. This requirement is the ongoing monitoring between those assessments. Define which controls get checked monthly or quarterly and which ride the annual assessment, and write the rhythm down. You define the frequencies, but a monitoring plan whose every interval is annual has collapsed into CA.L2-3.12.1 and covers neither well. This is also a five-point requirement under 32 CFR 170.24. Its point value bars it from any POA&M, the plan of action and milestones that defers unmet requirements, under 32 CFR 170.21. Manual monitoring is fine. Undocumented monitoring is invisible. A recurring ticket that comes due each month is a working continuous monitoring program for a small shop. So is a spreadsheet with the control, the result, the date, and the reviewer's name. The completed records are the entire evidence base for [a]. A dashboard nobody exports and a policy that says monitoring happens both evaporate under the question of when you last did it. Spend the frequent checks on the volatile controls. Patching status, vulnerability findings, asset inventory accuracy, account and access reviews, and document drift change weekly. A locked server room does not. Weight the rhythm toward what moves, and let stable controls surface through the annual assessment. Make sure every control appears somewhere in the combined cycle so nothing is monitored by assumption. Reuse the activities other requirements already force. Log review, risk assessment under RA.L2-3.11.1, plan of action reviews under CA.L2-3.12.2, and incident response follow-ups are monitoring activities. Reference them in your monitoring plan and route their outputs into it rather than building a parallel program. The guide's chain is direct: monitoring output informs management's risk decisions and keeps the system security plan, the document that says how each requirement is met, honest between assessments. What falls short: - A policy asserting continuous monitoring with no dated records of any check. Without completed evidence there is nothing showing controls are monitored on an ongoing basis, so [a] is unmet. Page: https://cmmcpedia.com/requirements/3-12-3/ ### CA.L2-3.12.4 System Security Plan Official Source Material: Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. Determine if: - [a] a system security plan is developed; - [b] the system boundary is described and documented in the system security plan; - [c] the system environment of operation is described and documented in the system security plan; - [d] the security requirements identified and approved by the designated authority as non-applicable are identified; - [e] the method of security requirement implementation is described and documented in the system security plan; - [f] the relationship with or connection to other systems is described and documented in the system security plan; - [g] the frequency to update the system security plan is defined; and - [h] system security plan is updated with the defined frequency. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The system security plan is the one document a CMMC assessment cannot proceed without. The plan is the document that describes your system and how it meets each requirement. 32 CFR 170.24(c)(2)(i)(5) requires one in place at the time of assessment, describing each information system in the CMMC assessment scope. The absence of an up to date plan results in a finding that an assessment could not be completed, due to incomplete information and noncompliance with 48 CFR 252.204-7012. Every other requirement failure costs points. This one stops the assessment itself. Out of date carries the same consequence as missing, so a plan written for the environment you had two migrations ago does not protect you. There is no POA&M escape for this requirement. 32 CFR 170.21(a)(2)(iii) names CA.L2-3.12.4 among the requirements that may never appear on a POA&M, the plan of action and milestones that defers unmet requirements. There is no conditional status to fall back on if the plan is not ready. Finish the system security plan before you schedule the assessment, and treat every review between now and then as a chance to find what it fails to describe. Objectives [a] through [h] are the table of contents. Write to the letters. Describe the boundary for [b] and the environment of operation for [c]. Identify the non-applicable requirements for [d]. Describe the implementation method for each security requirement for [e] and the relationships and connections to other systems for [f]. Define an update frequency for [g], and demonstrably honor it for [h]. An assessor walks these letters in order, so a plan organized around them assesses smoothly and a plan organized around a marketing template does not. Objective [e] wants a narrative per requirement: what you do, not what the requirement says. For each security requirement, write a brief description of how your organization implements it, addressing the objectives, and reference the policy or procedure that carries the detail. Avoid two failure modes. The shell plan only points elsewhere for every answer. The kitchen-sink plan buries implementation statements in hundreds of pages of pasted boilerplate. Both force the reader to hunt, and the reader is scoring you. The guide is explicit that the plan may be a collection of documents. The narrative is the map that makes the collection usable. The environment of operation is people, facilities, and workflow, not an operating system inventory. Objective [c] asks where and how the system operates. Cover what the business does, where CUI, the Controlled Unclassified Information you handle, enters and moves, who touches it, and in what physical surroundings. A few honest paragraphs covering the people, the technology, and the facilities give the assessor the context every later answer hangs on. Objective [d] is the commonly missed letter: not applicable is a ruling, not a self-assessment. Requirements you treat as non-applicable must be identified and approved by the designated authority. Under 32 CFR 170.24(c)(2)(i)(8), the ruling comes from the DoD CIO: an adjudication that a requirement is not applicable, or that an alternative security measure is equally effective. That adjudication must be included in the system security plan to receive consideration during an assessment. Claiming adjudicated non-applicability on your own authority and documenting nothing invites the assessor to score the requirement as unmet. The boundary description in [b] is what makes every scoping argument stick. Say which assets are inside, which are outside, and what separates them, with a diagram. The enduring exceptions that 32 CFR 170.24(b)(1)(i) assesses as MET also live here, described with their mitigations. When an assessor questions whether a device is in scope or a gap is acceptable, the answer either sits in the system security plan already or turns into a finding. Update on a defined cycle, and prove it. Objective [g] wants the frequency defined, and [h] wants it honored. The guide's stated norm is at least annually, and 32 CFR 170.4 caps any periodic interval at one year anyway. Keep a revision history with dates and what changed, and update off-cycle when the environment shifts: a new cloud service, a dropped connection to a partner, a moved office. The revision log is the cheapest evidence in the whole plan, and it is the first place an assessor looks to test whether the document is alive. What falls short: - A plan that restates each requirement's text with met written beside it. It never describes the method of implementation, so [e] is unmet. - A plan with no boundary description or diagram separating in-scope from out-of-scope assets. Objective [b] is unmet and every scoping decision in the assessment becomes an argument. - A plan last revised years ago with no defined update frequency. Objectives [g] and [h] are unmet, and under 32 CFR 170.24 the missing up-to-date plan risks the assessment being recorded as unable to be completed. - Requirements claimed as adjudicated non-applicable with no identification of who approved the determination. Objective [d] asks for the designated authority's approval of that kind of claim, not your own conclusion. Edge cases: - More than one system handles CUI: 32 CFR 170.24 expects the plan to describe each information system within the CMMC assessment scope. Either write one plan per system or one plan with a clearly separated description of each, and what fails is a single narrative that blurs two environments into one. - External services confuse objective [f]: the cloud tenant, the managed service provider connection, and the prime contractor's portal are relationships and connections to other systems. Describe each one, what data flows across it, and what protects it, and keep the list synchronized with your actual vendor set at every update. Page: https://cmmcpedia.com/requirements/3-12-4/ ## System and Communications Protection (SC) ### SC.L2-3.13.1 Boundary Protection Official Source Material: Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems. Determine if: - [a] the external system boundary is defined; - [b] key internal system boundaries are defined; - [c] communications are monitored at the external system boundary; - [d] communications are monitored at key internal boundaries; - [e] communications are controlled at the external system boundary; - [f] communications are controlled at key internal boundaries; - [g] communications are protected at the external system boundary; and - [h] communications are protected at key internal boundaries. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Define the boundaries before you defend them. Objectives [a] and [b] ask for definitions, not equipment. Draw the external boundary where your system meets the internet and anything else you do not control. Then name the components that sit on it: the firewall, the VPN (virtual private network) gateway, and the cloud services where your traffic lands. Then decide whether any key internal boundaries exist. A network diagram that names these boundaries answers [a] and [b] and gives the other six objectives something to attach to. A small, deliberate boundary makes the rest of this family cheaper. Every boundary you define must then be monitored, controlled, and protected. An enclave isolates the systems touching CUI (Controlled Unclassified Information) behind one firewall and one set of rules. That gives you two boundaries to defend instead of a sprawling network's dozen. The segmentation that carves the enclave out of the rest of your network is itself a key internal boundary under [b], so monitor and control it like the perimeter. Having no key internal boundaries is an acceptable answer when it is true. A small flat network with nothing separating one part of the system from another has no key internal boundaries to name. Write that determination down under [b] and the internal halves of [d], [f], and [h] follow it. What fails is silence: an assessor who finds a segmented development network or a separate WiFi you never declared will ask why your definition missed it. Cover three verbs at each boundary: monitor, control, protect. Objectives [c] through [h] pair monitoring, control, and protection with each boundary class. Monitoring means the traffic is logged, reviewable, and alerting on the suspicious [c, d]. Control means connections are denied by default and allowed by exception [e, f], which SC.L2-3.13.6 sharpens into its own requirement. Protection means encryption or tunneling where the traffic warrants it [g, h]. Walk each named boundary through all three verbs. Record the mechanism in your system security plan, the document that describes how your system meets each requirement. A cloud-first company still has boundaries to declare. When your CUI lives in a cloud tenant and your staff work from anywhere, the external boundary changes shape. It becomes the host-based firewall on each managed endpoint plus the cloud service's own managed perimeter. Declare both, show the endpoint firewall denying unsolicited inbound traffic, and point at the provider's boundary responsibilities in its shared responsibility documentation. What falls short: - File and folder permissions offered as boundary protection. Access control lists govern who reads data, not the boundary-crossing communications [c] through [h] cover, so you still need a firewall, even if it is the one on each endpoint. - A firewall whose logs nobody can produce. Rules alone show control under [e], and monitoring under [c] needs the logging turned on and reviewable. - Badge readers and locked doors. Physical protections belong to the Physical Protection family and say nothing about network traffic. Edge cases: - Guest WiFi separated from the CUI environment so it cannot carry CUI or FCI (Federal Contract Information) sits outside the boundary, so document the separation that makes that true. WiFi inside the CUI environment is a key internal boundary, because wireless presents a different attack surface than the wired segment it joins. - Remote workers do not force a VPN. A VPN is one way to control the out-of-office connection, and an endpoint firewall plus TLS to your cloud services is another. Whichever you choose, account for the remote connection explicitly in your boundary definition. Page: https://cmmcpedia.com/requirements/3-13-1/ ### SC.L2-3.13.2 Security Engineering Official Source Material: Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. Determine if: - [a] architectural designs that promote effective information security are identified; - [b] software development techniques that promote effective information security are identified; - [c] systems engineering principles that promote effective information security are identified; - [d] identified architectural designs that promote effective information security are employed; - [e] identified software development techniques that promote effective information security are employed; and - [f] identified systems engineering principles that promote effective information security are employed. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The six objectives are one structure: identify three things, then employ them. Objectives [a], [b], and [c] ask you to name the architectural designs, software development techniques, and systems engineering principles you follow. Objectives [d], [e], and [f] ask for proof that each named item shows up in the system. Write the identification document first. Without it the employment evidence has nothing to point at. Not developing software answers [b] and [e], and nothing else. Buying commercial software instead of building your own is a legitimate software development technique: state it under [b], and your procurement practice covers [e]. The other four objectives still stand. Architectural designs and systems engineering principles apply to any IT footprint, including a company that has never written a line of code. Adopt principles from a published source instead of inventing them. The security design principles in NIST SP 800-160 give you a menu. Pick the ones that fit and cite them. CIS Benchmarks or STIGs, both published hardening guides, serve as engineering principles and do double duty as the configuration settings CM.L2-3.4.2 asks for. Layered protection, least functionality, and deny by default are principles you already practice. The work is writing down which ones you chose. Show employment through decisions you already made. The cloud tenant you selected, the baseline that hardens your endpoints, the segmentation that isolates CUI (Controlled Unclassified Information): each is a design decision. For [d], [e], and [f], connect each adopted principle to the decision it drove. The evidence is a page in your system security plan tracing each principle to its implementation. That plan is the document describing how your system meets each requirement. Edge cases: - Software you deliver to the government as a product is the CUI, not the information system. This requirement governs the system that processes CUI. A contract that requires secure development or source code analysis of the deliverable is a separate obligation, and meeting it also answers the software development objectives. - Legacy systems predating your compliance effort are not automatic findings. The requirement's discussion applies the principles to upgrades and modifications where feasible, so record each decision and its reasoning when the legacy system changes. Page: https://cmmcpedia.com/requirements/3-13-2/ ### SC.L2-3.13.3 Role Separation Official Source Material: Separate user functionality from system management functionality. Determine if: - [a] user functionality is identified; - [b] system management functionality is identified; and - [c] user functionality is separated from system management functionality. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: You define what counts as user functionality and what counts as system management. Objectives [a] and [b] are definitions you write, and the definitions frame the assessment. Defining system management functionality as domain and tenant administration and user functionality as what a standard account can do is a workable framing. A least-privilege paragraph that never says what either term means gives the assessor nothing to test [c] against. Separate accounts enforce the separation. Separate networks are optional. The requirement allows physical or logical separation, and logical separation through access control is the ordinary implementation. Administrators hold a standard account for daily work and a privileged account for administration, and standard accounts cannot reach the administrative functions. This is the same account discipline AC.L2-3.1.6 requires, evidenced from the other side. Prove [c] by showing what a standard user cannot do. A demonstration that a normal account cannot open the admin center, install software, or reach management interfaces is direct evidence. Pair it with the definitions and the account inventory, and the requirement is covered without new infrastructure. Jump servers and privileged access management platforms are upgrades, not requirements. A dedicated administration host confines privileged sessions, and a privileged access management tool adds checkout and recording. Both earn roadmap space in a larger environment. Neither is needed to meet the objectives when account separation is clean. What falls short: - A policy stating that least privilege is employed on all accounts, with no definition of user or system management functionality. It leaves [a] and [b] unanswered and gives [c] nothing to demonstrate against. Edge cases: - Developers who need local administrator rights can keep them without breaking this requirement. Define privileged functionality at the domain or tenant level, grant local administrator through a documented risk exception, and alert on the actions you prohibited. The separate privileged account for domain work still applies. - In a three-person company the same person holds both roles. The separation is between accounts, not people: one everyday account, one administrative account, and the everyday one cannot administer. Page: https://cmmcpedia.com/requirements/3-13-3/ ### SC.L2-3.13.4 Shared Resource Control Official Source Material: Prevent unauthorized and unintended information transfer via shared system resources. Determine if: - [a] unauthorized and unintended information transfer via shared system resources is prevented. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This is an operating system property, not a file share setting. The requirement targets leftover information in shared resources: memory, cache, and disk space reclaimed from one user and handed to another. A current, supported operating system provides the protection. Your work is proving you run current systems configured to keep it. Evidence is the inventory plus the baseline. Show supported operating system versions across the fleet, and users without administrative rights so they cannot read other users' profiles. Add the platform memory protections enabled in your baseline, such as kernel DMA protection and core isolation. A configuration report tying those settings to your endpoints answers [a]. Do not chase processor-level scenarios. Side-channel and processor cache attacks are handled by the patching and flaw remediation you already run under SI.L2-3.14.1. The cases that matter here are shared computers and terminal servers where users can save files outside their own profile. Lock the public locations down. What falls short: - A system security plan paragraph about least privilege and folder permissions. Access control governs authorized reads. Objective [a] is about information left behind in resources the system reuses, and the answer lives in the operating system and its configuration. Edge cases: - Terminal servers and shared workstations are where this requirement becomes visible. Redirect profiles, restrict public folders, and keep users out of each other's directories, because a shared host is one misconfigured folder away from unintended transfer. Page: https://cmmcpedia.com/requirements/3-13-4/ ### SC.L2-3.13.5 Public-Access System Separation Official Source Material: Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. Determine if: - [a] publicly accessible system components are identified; and - [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: List what the public can reach before deciding how it is separated. Objective [a] is an inventory: the public website, the VPN (virtual private network) portal, and the mail gateway. Add anything else with a login page or a service listening for connections from the internet. Publicly accessible means reachable without credentials, so a portal that demands a password still belongs on the list, because its login page is the reachable part. Separation is a subnetwork with default deny toward the inside. The classic answer is a DMZ, a buffer network for public-facing components. Put those components on their own subnet or firewall zone. Deny traffic from that zone into the internal network by default, and allow it only by specific rule. Virtual LANs, firewall zones, and cloud network segmentation all qualify as logical separation. Hosting public components outside your network is separation by construction. A marketing website run by a third party on the third party's infrastructure never touches your internal network. Identify it under [a], record where it lives, and the separation for [b] is the fact that it shares nothing with the systems holding CUI. Edge cases: - The VPN gateway is publicly accessible and necessarily reaches inward. Put its interface in its own firewall zone and allow traffic into internal segments only by explicit rule, so the one component that must bridge the boundary runs under default deny. - A cloud-only environment is separated from an internal network you may barely have. Still answer [a]: name the tenant sign-in page and any public endpoints, and describe the authentication layer standing between them and your resources. Page: https://cmmcpedia.com/requirements/3-13-5/ ### SC.L2-3.13.6 Network Communication by Exception Official Source Material: Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). Determine if: - [a] network communications traffic is denied by default; and - [b] network communications traffic is allowed by exception. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Deny by default is a posture, not a long list of deny rules. Objective [a] wants an implicit deny that catches everything you did not explicitly allow. A ruleset that blocks a list of ports and permits the rest is allow by default with deny exceptions, the opposite of the requirement. It fails the moment you forget a protocol: deny every TCP port, and UDP and ICMP still flow. Outbound traffic is included, and it is the half that gets missed. The requirement does not exempt outgoing connections. Set the default outbound action to block, then allow what the business needs: web on 80 and 443, DNS, DHCP, NTP, and the directory service ports if you run one. Build the outbound exception list by observing what the environment actually uses, then close the door. Filtering by port is sufficient. Allow rules keyed to ports and protocols meet both objectives. Per-destination address allowlists and per-application rules are tighter than the requirement asks and cost more to maintain than they return. Adopt them for your own reasons, not for this requirement. Host firewalls managed centrally satisfy this at the endpoint. Windows Defender Firewall with default deny pushed through Intune or Group Policy carries the requirement to laptops that never sit behind your perimeter. Rules delivered by mobile device management do not appear in the local firewall console. When you need evidence, export them from the management plane or query the MDM policy store with PowerShell. What falls short: - Inbound blocked and outbound open. [a] asks for traffic denied by default in both directions, and unrestricted outbound is where exfiltration lives. - Web content filtering that blocks known-bad categories. Blocking listed sites is deny by exception, and the requirement wants the opposite. Edge cases: - Ephemeral ports, the temporary source ports the operating system picks for outbound connections, must stay open on the local side or those connections break. Allow the dynamic range on the local side of outbound rules while keeping destination ports on the exception list. - The macOS application firewall is a blocklist and cannot express deny by default. Use the built-in packet filter for port-level default deny on Macs in scope. Page: https://cmmcpedia.com/requirements/3-13-6/ ### SC.L2-3.13.7 Split Tunneling Official Source Material: Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling). Determine if: - [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: With a VPN, this is one setting plus proof users cannot change it. Disable split tunneling on the VPN (virtual private network) concentrator or client profile, so every packet from a connected device rides the tunnel. Lock the client configuration so users cannot re-enable it. Test one device, then keep the configuration export and the test note as evidence for [a]. Expect the printer problem and solve it deliberately. Full tunneling breaks printing to home printers, because the local subnet disappears. Decide the answer up front: block device redirection, allow USB-attached printers, or accept no remote printing. Quietly re-enabling split tunneling to stop the complaints defeats the objective. A cloud-only environment answers this at the endpoint. With no on-premises system to tunnel into, the requirement does not vanish. The remote device itself becomes the boundary to defend. A host firewall denying unsolicited inbound connections, endpoint detection and response, and DNS or web filtering give the endpoint the controls a perimeter would. Each connection to your cloud tenant is then an individually secured TLS session rather than a bridge between networks. Write that architecture into your system security plan, the document that describes how your system meets each requirement, rather than claiming the requirement is not applicable. Edge cases: - No remote access to on-premises resources at all is a complete answer. Prohibit it technically, state the prohibition, and document how you would meet the requirement if remote access were ever introduced. - A VPN that tunnels everything except traffic to your own Microsoft 365 tenant sends trusted cloud traffic direct while the tunnel carries the rest. It is split tunneling by the literal definition, so it needs a written rationale explaining that the exempted traffic is TLS to a service you control. Page: https://cmmcpedia.com/requirements/3-13-7/ ### SC.L2-3.13.8 Data in Transit Official Source Material: Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. Determine if: - [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified; - [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and - [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Inventory the paths CUI travels, then name the mechanism on each. Objective [a] is a list of the ways CUI (Controlled Unclassified Information) moves: email, file transfer, cloud sync, remote access, site-to-site links, scanner-to-server traffic. Give every path a cryptographic mechanism. TLS, the standard encryption protocol for internet connections, at version 1.2 or newer covers nearly all of them, and [c] becomes the configuration evidence per path. The path you never identified is the one the assessor finds. The module must be validated, not just the algorithm. CUI in transit outside your protected environment needs FIPS-validated cryptography: encryption tested and certified under the government's FIPS 140 program. Validation attaches to the cryptographic module, the software or hardware running the algorithm, not to the algorithm itself. On Windows, enable FIPS mode so TLS rides the operating system's validated modules, and verify each module's certificate on the NIST Cryptographic Module Validation Program list. SC.L2-3.13.11 carries the full validation story. This requirement is where transmission inherits it. Email is the path that fails quietly. Ordinary email negotiates opportunistic TLS, encryption used only when the receiving server supports it, and delivers anyway when the far end cannot. So you cannot show [c] for CUI sent to arbitrary recipients. Force TLS to the partner domains you exchange CUI with. Or encrypt the file itself with a FIPS-validated tool before attaching it. Or move the exchange to a controlled channel such as a secure file transfer service. Pick one answer per counterparty and write it down. Physical safeguards are the narrow alternative, and radio is never one. Objective [b] exists for the protected distribution system case: cabling protected against interception inside a controlled facility. It shelters unencrypted traffic on a wired segment inside your physical boundary. It never covers wireless, because the signal leaves the building no matter what the walls do. What falls short: - Opportunistic TLS on email offered as the mechanism for CUI sent to arbitrary recipients. Delivery falls back to unprotected transmission when the receiving server fails the handshake, so implementation under [c] cannot be shown for that path. - Office WiFi carrying CUI without FIPS-validated wireless encryption, justified as being inside the building. Wireless transmission is not protected by physical safeguards, and access points running unvalidated encryption leave the path uncovered. Edge cases: - The assessment guide allows compensating safeguards or an explicit acceptance of risk where commodity carrier links, such as carrier-separated MPLS, cannot offer cryptographic assurance. Encrypt the link anyway when you can: the exception is narrow, software-defined WAN products do not inherit it, and an encrypted tunnel ends the argument. - Legacy equipment that cannot speak modern protocols, such as older CNC machines, belongs on an isolated wired segment inside your physical boundary, where the alternative physical safeguard genuinely applies. Move CUI to and from that equipment under controlled procedures. Page: https://cmmcpedia.com/requirements/3-13-8/ ### SC.L2-3.13.9 Connections Termination Official Source Material: Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity. Determine if: - [a] a period of inactivity to terminate network connections associated with communications sessions is defined; - [b] network connections associated with communications sessions are terminated at the end of the sessions; and - [c] network connections associated with communications sessions are terminated after the defined period of inactivity. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This is network session termination. User sessions belong to AC.L2-3.1.11. The objectives here are about connections: TCP sessions, VPN (virtual private network) tunnels, remote access links. Locking screens and ending user sessions is a different requirement. Keep the two separate in your system security plan, the document that describes how your system meets each requirement, so each points at its own mechanism. Define the inactivity period, then show the configuration that enforces it. Objective [a] is a number you choose and write down. [c] is the timeout configured to match. The idle connection timeout on your firewall and the session timeout on your VPN are the ordinary mechanisms. A vendor default counts once you document it as your defined period. Termination at session end is mostly protocol behavior. Your job is the catch-all. Connections close when a user disconnects or an application finishes, which covers [b]. The inactivity timeout under [c] is the backstop for sessions that never end cleanly, including the dangling connections browsers leave behind. Defining which network sessions require managed termination is within your power, and remote access sessions are the ones that matter. Edge cases: - Work-from-home devices with no always-on tunnel have no corporate network session to terminate until they connect. Define the managed sessions as the VPN and remote access connections, and let the VPN's timeout carry the requirement. Page: https://cmmcpedia.com/requirements/3-13-9/ ### SC.L2-3.13.10 Key Management Official Source Material: Establish and manage cryptographic keys for cryptography employed in organizational systems. Determine if: - [a] cryptographic keys are established whenever cryptography is employed; and - [b] cryptographic keys are managed whenever cryptography is employed. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: List every place cryptography is employed. Each entry needs a key story. Full-disk encryption recovery keys, TLS certificates, VPN secrets, backup encryption keys, and signing keys all belong on the list. Each needs an answer for how the key is created [a] and how it is stored, renewed, revoked, and destroyed [b]. The inventory is short in a small environment, and writing it is most of the work. Never store a key where the data it protects lives. A backup encryption key kept in the same repository as the backups means one compromised account yields both. Store recovery keys for full-disk encryption away from the device. Escrowing BitLocker keys to Microsoft Entra ID or Intune is the ordinary case. Keep backup keys in a separate access-controlled store. Check that no single account reaches both a key and the data it unlocks. Cloud providers manage the keys for their services. Cite it, do not duplicate it. For a service like Microsoft 365, the provider generates and manages the keys behind its encryption, and its shared responsibility documentation says so. Your side of [a] and [b] is the keys you hold: device encryption, certificates you issue or buy, and anything you generate yourself. Certificates are keys with expiration dates. Assign the renewal. Track certificates from an internal certificate authority in that system, and give externally purchased certificates an owner and a renewal reminder. An expired certificate is a key management failure that announces itself to every visitor. What falls short: - Encryption keys or recovery keys backed up alongside the data they encrypt. It collapses the protection to a single point of failure and shows the keys are not managed under [b]. Page: https://cmmcpedia.com/requirements/3-13-10/ ### SC.L2-3.13.11 CUI Encryption Official Source Material: Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. Determine if: - [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Validated means a certificate for the module, not an approved algorithm. AES is a FIPS-approved algorithm. Running it inside a module nobody validated does not satisfy [a]. Validation is a property of the cryptographic module, the software or hardware implementing the algorithm. The module is tested under FIPS 140 and listed with a certificate number by NIST's Cryptographic Module Validation Program (CMVP). For every product protecting the confidentiality of CUI (Controlled Unclassified Information), your evidence is that certificate number. A data sheet that says FIPS compliant is a marketing phrase, not a certificate. The word when scopes the requirement. Find your encryption points first. FIPS-validated cryptography is required where cryptography is the thing protecting CUI confidentiality: transmission beyond your protected environment, storage on devices that leave it, wireless and remote access. Inside the protected environment, physical safeguards can carry confidentiality, and encryption used for other purposes there does not need validation. Map the CUI flow, mark where encryption is the protection, and spend your validation effort exactly there. On Windows, FIPS mode puts the operating system's validated modules to work. Enable the FIPS policy setting through Group Policy or Intune so TLS and BitLocker use the validated modules, then record the module certificates for your Windows versions. Applications that call the operating system's cryptographic modules inherit that validation. Applications that ship their own cryptography do not, so check each product touching CUI for which case it is. Encryption without validation is the one large gap the rules let you carry. A Plan of Action and Milestones is the documented list of gaps you commit to close after assessment. 32 CFR 170.21(a)(2)(ii) permits SC.L2-3.13.11 on that plan only when encryption is employed but is not FIPS-validated. 32 CFR 170.24 scores that state as a three-point deduction, while every other requirement on a plan must be worth one point. Encryption not employed at all is a five-point deduction and cannot ride a plan. Encrypt now with what you have, then close the validation gap inside the 180-day conditional window. One validated layer per CUI path is enough. A FIPS-mode TLS session inside a VPN whose own module is unvalidated is still protected, because one end-to-end layer is validated. Decide which layer carries the validation for each path and record it, rather than trying to validate every layer at once. AC.L2-3.1.13 applies the same logic to remote access sessions. Do not validate what is not protecting CUI. Switches passing already-encrypted traffic, printers inside the physical boundary, and hashing inside an application are not employing cryptography to protect CUI confidentiality, so they carry no validation requirement. Money spent putting FIPS-validated firewalls in front of traffic that is already validated end to end buys nothing. What falls short: - A vendor claim of FIPS compliant with no CMVP certificate number. [a] asks for validated cryptography, and validation is the certificate. - The right algorithm in an unvalidated module. AES-256 in software that never went through FIPS 140 testing does not meet [a]. - BitLocker on machines never placed in FIPS mode. The module's security policy conditions validated operation on the FIPS setting, so enable and enforce it before counting BitLocker as validated. Edge cases: - Wireless access points with validated modules are rare and expensive. Carry CUI over a validated layer above the WiFi, a FIPS-mode TLS session or VPN, or keep the CUI systems wired, instead of shopping for validated access points. - Print jobs resist validated encryption. A print station wired directly to the printer inside the physical boundary sidesteps the problem: CUI reaches the station over a validated path, and physical safeguards cover the last hop. - Running a software version newer than the one on the certificate is the normal state of a patched fleet. Treat it as a temporary deficiency in an operational plan of action, tracking the vendor's revalidation, rather than freezing at the validated build and losing its security patches. Page: https://cmmcpedia.com/requirements/3-13-11/ ### SC.L2-3.13.12 Collaborative Device Control Official Source Material: Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. Determine if: - [a] collaborative computing devices are identified; - [b] collaborative computing devices provide indication to users of devices in use; and - [c] remote activation of collaborative computing devices is prohibited. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Laptop cameras and microphones are collaborative computing devices. The requirement's discussion names networked whiteboards, cameras, and microphones, and excludes only dedicated video conferencing systems that activate when a participant connects the call. Inventory the built-in cameras and microphones across the fleet along with any room systems, and [a] is done. An organization with no conference room gear does not get to answer not applicable. Indication of use is mostly built in. Write down what you rely on. The hardware light beside the camera, the operating system's on-screen microphone indicator, and the meeting client's in-call display each signal a device in use, which answers [b]. A room device with no indicator gets a manual substitute: a posted notice or a locked door while in use. Prohibit remote activation with configuration, and use camera covers where configuration cannot reach. Disable auto-answer on room video units so nothing activates until someone accepts the call, and keep remote control of endpoint cameras away from standard users. Physical camera covers are a zero-cost supplement for [c]. Edge cases: - Remote support tools that can open a camera during a session are remote access, not collaborative computing devices. Configure them to require the user to accept the session, which keeps activation in the hands of the person at the device. - A dedicated video conferencing system that activates only when a participant connects the call sits inside the requirement's own exclusion. Verify auto-answer is off, because that setting is the boundary of the exclusion. Page: https://cmmcpedia.com/requirements/3-13-12/ ### SC.L2-3.13.13 Mobile Code Official Source Material: Control and monitor the use of mobile code. Determine if: - [a] use of mobile code is controlled; and - [b] use of mobile code is monitored. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Mobile code is code that arrives over the network and runs without installation. JavaScript in every web page, active content in PDF files, browser plug-ins, and script attachments are the subject: the assessment guide names Java, JavaScript, ActiveX, Postscript, PDF, Flash, and VBScript. It has nothing to do with applications on mobile phones, and a policy about installing unauthorized software misses it entirely. Allowing is controlling, when the decision is written down. Control under [a] means deliberate, documented decisions about which mobile code runs. Permitting JavaScript in managed browsers while prohibiting legacy plug-ins and unsigned macros is control. Enforce the decisions through browser management and the Office macro settings in your configuration baseline, with an exception path for the business need that arrives later. Monitoring rides your existing malware protection. Objective [b] is satisfied by the tooling you run under SI.L2-3.14.2. State which mobile code technologies your endpoint protection and web filtering inspect, and keep the alerts and their review as the record. A blocked script in the detection history is monitoring evidence. What falls short: - A policy that users may not download or install unauthorized software. Mobile code executes without installation, so the policy does not control it and shows nothing for [a] or [b]. Edge cases: - Developers who write and run scripts are using mobile code technologies legitimately. Authorize the languages for the named role, prohibit the rest, and let the anti-malware monitoring cover what executes. Page: https://cmmcpedia.com/requirements/3-13-13/ ### SC.L2-3.13.14 Voice over Internet Protocol Official Source Material: Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. Determine if: - [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and - [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: This covers voice as network traffic, not the copper phone line. Plain telephone service is outside this requirement. VoIP is data on a network and gets treated like any other protocol. A true no-VoIP environment can assess this requirement as not applicable. But Teams, Zoom, and softphones are VoIP technologies, so no VoIP at all is rarely true. State what you run and how it is controlled. Control is naming the approved service. Monitoring is watching its traffic. Authorize the VoIP solution in policy and configuration, and restrict use to the approved product [a]. Monitor through its logs, and watch your network monitoring for voice traffic that is not the approved service [b]. Patching the VoIP software with the rest of the fleet under SI.L2-3.14.1 is part of controlling it. Keep CUI out of the phone system rather than pulling the phone system into scope. Segment VoIP from the environment holding CUI (Controlled Unclassified Information), and prohibit CUI discussion over it in policy and training. When a voice conversation about CUI must happen, use a service authorized to carry CUI, such as Teams in GCC High. State compliance through separation in your system security plan, the document that describes how your system meets each requirement, instead of arguing the requirement away. Page: https://cmmcpedia.com/requirements/3-13-14/ ### SC.L2-3.13.15 Communications Authenticity Official Source Material: Protect the authenticity of communications sessions. Determine if: - [a] the authenticity of communications sessions is protected. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Session authenticity is confidence that each end is who it claims, for the whole session. The threats are interception in the middle, session hijacking, and injected traffic. A current version of TLS, the standard encryption protocol for internet connections, with valid certificates provides the protection. The handshake authenticates the endpoint, and the session keys defend the exchange against takeover. Enforce current TLS and keep certificates from expiring. Configure servers, the VPN, and management interfaces to current TLS with weak protocol versions disabled, and renew certificates before expiry so the trust chain never lapses. This is largely the same configuration work as SC.L2-3.13.8, evidenced from the authenticity side. Sweep for the sessions that are not browser traffic. VPN tunnels, SFTP transfers, and application integrations each ride a protocol with its own authentication story. List the session types in your environment, and confirm each uses a protocol that authenticates the endpoints. Keep a policy naming the approved protocols, so a new one does not arrive unexamined. Page: https://cmmcpedia.com/requirements/3-13-15/ ### SC.L2-3.13.16 Data at Rest Official Source Material: Protect the confidentiality of CUI at rest. Determine if: - [a] the confidentiality of CUI at rest is protected. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Encryption and physical protection both satisfy this requirement. Objective [a] asks that the confidentiality of CUI (Controlled Unclassified Information) at rest is protected, not that it is encrypted. A server that never leaves an access-controlled room can rest on physical protection. The assessment guide's own example accepts a sign-out and locked-closet procedure for devices that cannot be encrypted. Encrypt anyway. The argument is worth less than the checkbox. Full-disk encryption is built into the operating systems you already run and removes the burden of proving the physical story asset by asset. Reserve the physical justification for equipment that genuinely cannot encrypt. Anything that leaves the protected area is encrypted, not argued. Laptops, phones, portable drives, and backup media are outside your physical safeguards the moment they move. AC.L2-3.1.19 and MP.L2-3.8.6 make encryption explicit for mobile devices and transported media, and the validation question for that encryption belongs to SC.L2-3.13.11. Components that never store CUI meet this by keeping it that way. A device that only processes or relays CUI, with administrative controls keeping CUI from being written to it, has no CUI at rest to protect. Document the control that keeps storage off the asset. If CUI lands on it anyway, it is a storage asset and needs the protection. Edge cases: - Equipment that cannot support encryption gets a custody procedure: signed out when needed, kept in the borrower's possession, locked away on return, and audited. The assessment guide's example describes exactly this. Page: https://cmmcpedia.com/requirements/3-13-16/ ## System and Information Integrity (SI) ### SI.L2-3.14.1 Flaw Remediation Official Source Material: Identify, report, and correct system flaws in a timely manner. Determine if: - [a] the time within which to identify system flaws is specified; - [b] system flaws are identified within the specified time frame; - [c] the time within which to report system flaws is specified; - [d] system flaws are reported within the specified time frame; - [e] the time within which to correct system flaws is specified; and - [f] system flaws are corrected within the specified time frame. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Write three timeframes before you touch a patch. Objectives [a], [c], and [e] each demand a specified time: how quickly flaws are identified, how quickly they are reported, and how quickly they are corrected. The remaining objectives, [b], [d], and [f], are proof you meet those times. Numbers come first: a scan cadence, a reporting cadence, and remediation windows by severity, written into policy. Reporting is the step that fails organizations that patch well. Scanning and fixing without a documented reporting step leaves [c] and [d] with no evidence. Reporting means the identified flaws land somewhere reviewable on a schedule: a generated report, a ticket, an email to the responsible person. When one person runs the whole loop, the report is still written: the dated list of flaws produced before patching begins is the reporting evidence. Flaws are more than missing patches. Configuration weaknesses found by scans, findings from the security assessments CA.L2-3.12.1 requires, and weaknesses surfaced during incident response are all system flaws in this requirement's sense. Route them through the same identify, report, and correct loop with the same timeframes. Evidence is the loop running end to end. A vulnerability report dated inside your identification window covers [b]. The ticket or emailed report with its timestamp covers [d]. Patch deployment history showing correction inside the window covers [f]. A tracking spreadsheet with an open tab and a closed tab is a complete system for a small environment. Do not put a review board in front of routine patches. A monthly approval gate for operating system updates slows correction and returns no security. You own your change process. Classify routine patches as standard changes that deploy automatically to a test group and then to production on defined days. Save the approvals for changes that warrant them. What falls short: - Patch management tooling with no specified timeframes. However fast the patching, [a], [c], and [e] ask for defined times, and undefined times cannot be met. - Scan results that are generated and never reported to anyone on a defined cadence. Identification without reporting leaves [c] and [d] unanswered. Edge cases: - A system that breaks when patched is a documented risk decision, not a silent gap. Record the exception, isolate and mitigate the system, and revisit it on a schedule, because an undocumented unpatched system is a plain [f] failure. - Software the customer directs you not to update leaves the flaw open through no fault of yours. Keep the customer's written direction, record the affected flaws, and mitigate around them, because the direction is your evidence when the correction timeframe cannot be met. Page: https://cmmcpedia.com/requirements/3-14-1/ ### SI.L2-3.14.2 Malicious Code Protection Official Source Material: Provide protection from malicious code at designated locations within organizational systems. Determine if: - [a] designated locations for malicious code protection are identified; and - [b] protection from malicious code at designated locations is provided. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Objective [a] is a list of locations, so write the list. Designated locations are where malicious code can enter or take hold: workstations, servers, the email service, the web gateway or boundary firewall. Name them in your system security plan, the document that says how each requirement is met. The standard footprint is protection on every workstation and server operating system plus scanning where mail and web traffic enter. Objective [b] is coverage at every location on the list. Deploy the anti-malware or endpoint detection agent to each named endpoint and server, and turn on the mail and web scanning your platform provides. Reconcile the protection console against the asset inventory: a machine in the inventory with no agent is the finding waiting to be written. Modern endpoint detection and response satisfies the requirement. The objective asks for protection from malicious code, not for a signature-based product category. Endpoint detection and response, the tooling that watches program behavior instead of only matching known malware, meets it with real-time protection on. Reputation and behavior engines count. What matters is that every designated location has it and that it reports centrally. Email and web are the delivery paths. Designate them. Malicious code arrives through mail attachments, links, and downloads far more than through inbound network exploits. A designation list that stops at endpoints leaves the entry points unnamed under [a]. Include the mail filtering and web protection you already have. What falls short: - Antivirus on workstations alone when servers and the email path are in scope. [a] asks where protection must be provided, and a list that omits the servers and entry points is incomplete. Page: https://cmmcpedia.com/requirements/3-14-2/ ### SI.L2-3.14.3 Security Alerts & Advisories Official Source Material: Monitor system security alerts and advisories and take action in response. Determine if: - [a] response actions to system security alerts and advisories are identified; - [b] system security alerts and advisories are monitored; and - [c] actions in response to system security alerts and advisories are taken. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Subscribe to the sources that match your stack, and name them. Alerts from CISA, the federal cybersecurity agency, plus the security bulletins for the products you actually run are the working set. Objective [b] is met by receiving and reviewing them on a cadence tied to how often they arrive. The named source list in your procedure is the first thing an assessor asks for. Decide response actions before the advisory arrives. Objective [a] wants the playbook in advance: assess applicability, check exposure, patch or reconfigure under your SI.L2-3.14.1 timeframes, and notify the people affected. Three sentences in the procedure cover it. Keep receipts that action followed. Objective [c] is the record: the advisory reviewed, the applicability call, and the ticket or change that followed when it applied. An advisory judged not applicable is also a record. A one-line log entry shows the process ran. What falls short: - Subscriptions with no review. Alert emails accumulating unread in a mailbox show monitoring under [b] is not happening, and nothing can follow for [c]. Page: https://cmmcpedia.com/requirements/3-14-3/ ### SI.L2-3.14.4 Update Malicious Code Protection Official Source Material: Update malicious code protection mechanisms when new releases are available. Determine if: - [a] malicious code protection mechanisms are updated when new releases are available. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Automatic updates are the implementation. Anything manual is a liability. Malware changes daily or faster, and [a] asks that protection mechanisms update when new releases are available. Turn on automatic definition and engine updates in the platform's policy and let the vendor's release cadence be your cadence. The work is proving that automatic updates happen. An auto-updating platform leaves no manual trail, so build one. Keep the policy export showing updates enabled and the vendor's documentation describing its release behavior. Add a console report showing agent and definition versions current across the fleet. Those three artifacts answer [a]. Watch for the agents that stop updating. A machine with a stale definition version is this requirement failing quietly on one asset. Review the console's outdated-agent view on a schedule and chase the stragglers. The review record doubles as evidence the mechanism works. Page: https://cmmcpedia.com/requirements/3-14-4/ ### SI.L2-3.14.5 System & File Scanning Official Source Material: Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed. Determine if: - [a] the frequency for malicious code scans is defined; - [b] malicious code scans are performed with the defined frequency; and - [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: The requirement contains two duties, and real-time scanning alone fails one of them. Periodic scans of the system under [a] and [b] and real-time scans of external files under [c] are independent clauses. Define a scan frequency, run the scans on it, and keep real-time protection on. Continuous protection with no defined periodic scan leaves [a] with no number and [b] with no proof. You choose the scan type and the frequency. Then match the configuration. The requirement never says full scans. A weekly quick scan is a defensible definition when real-time protection covers file activity. What fails is a configuration that does not match your written frequency. Say what you do, do what you say, and export the schedule as evidence. Real-time means on download, open, or execute, and a USB stick is an external source. Endpoint real-time protection covers files as they arrive and run, and the email service's attachment scanning covers the main delivery path before files reach the endpoint [c]. Confirm scanning fires on removable media, because files copied from a USB drive are files from an external source. Endpoint products without a scheduled scan feature need a documented equivalence. Some platforms are designed for continuous scanning and offer no periodic scan to schedule. Collect the vendor's documentation of how every file is examined regardless, and define your frequency in those terms. Put the rationale in your system security plan, the document that says how each requirement is met, before an assessor asks. What falls short: - Real-time protection with no defined scan frequency. [a] asks for a frequency and [b] for scans performed on it, and continuous protection does not answer either on its own. Edge cases: - Repositories too large to scan wholesale get a defined approach, not silence: scan the ingestion points and designated locations, use quick scans, and document why that coverage is complete. - Phones and tablets under mobile device management are handled through enrollment, app protection, patching, and jailbreak detection, which flags a phone stripped of its built-in protections. Document that mobile stack instead of forcing a traditional antivirus product onto iOS. Page: https://cmmcpedia.com/requirements/3-14-5/ ### SI.L2-3.14.6 Monitor Communications for Attacks Official Source Material: Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. Determine if: - [a] the system is monitored to detect attacks and indicators of potential attacks; - [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and - [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Blocking is not monitoring. A firewall that drops traffic by rule is control. Monitoring is detection plus review. The intrusion prevention and gateway inspection features of the firewall you already own, turned on and alerting, create the detection. A person reviewing the alerts is what makes it monitoring. Cover the system and both traffic directions. Objective [a] is the systems themselves, covered by endpoint detection and log review. Objectives [b] and [c] are inbound and outbound traffic. Outbound is the half that catches real attacks: beaconing, the steady call home that malware makes, unauthorized data leaving, and connections to known-bad infrastructure. Enable inspection in both directions and alert on both. Alerts need a named reader and a cadence. Route detections to a mailbox or channel someone owns. Put the review on a schedule with a checklist: firewall alerts, endpoint detections, and the logs of the systems holding CUI, the Controlled Unclassified Information you protect. The review record is the evidence for all three objectives, and the records AU.L2-3.3.1 retains are what the review reads. Scale the tooling to the environment, not to a security operations center ideal. A small environment meets this with the firewall's security services alerting by email, endpoint detection and response, and a weekly review. A SIEM, the platform that collects and correlates alerts and logs in one place, earns its cost when alert volume outgrows a mailbox. Buying one does not satisfy the objectives. Reviewing what it raises does. What falls short: - Detection features enabled with nobody assigned to read the alerts. Unreviewed alerts show detection exists and monitoring does not, which fails [a], [b], and [c] alike. Page: https://cmmcpedia.com/requirements/3-14-6/ ### SI.L2-3.14.7 Identify Unauthorized Use Official Source Material: Identify unauthorized use of organizational systems. Determine if: - [a] authorized use of the system is defined; and - [b] unauthorized use of the system is identified. Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024 (https://dodcio.defense.gov/CMMC/Resources-Documentation/) Practitioner Guidance. How to meet it: Objective [a] is your acceptable use policy doing double duty. Define authorized use of the system: who may use it, for what, with which software and services. The acceptable use policy people sign under your awareness program is the definition. Keep it specific enough that unauthorized has a meaning. Not every prohibition needs a technical detector. Objective [b] asks that unauthorized use is identified, not that every policy line has a sensor. Technical items get technical detection: alerts on unauthorized software from your inventory tooling, connections refused for unenrolled devices, log review flagging odd hours or odd volume. Non-technical prohibitions, such as photographing a screen, are covered by policy, training, and the duty to report that you place on everyone. The mechanisms are ones you already run. Endpoint detections, the log review from AU.L2-3.3.1, application inventory reports, and the network monitoring from SI.L2-3.14.6 all surface use outside the definition. Name them as the identification mechanisms in your system security plan, the document that says how each requirement is met. Objective [b] then points at running machinery instead of intent. Page: https://cmmcpedia.com/requirements/3-14-7/