The person most likely to put your CUI somewhere it does not belong already has a badge, a login, and a parking spot. That is not a dramatic claim. It is just what “insider” means.
If you run a machine shop in Mesa or an engineering firm in Chandler, you have probably read enough CMMC articles to last a lifetime, and most of them tell you the same thing: this is hard, the clock is ticking, call someone. This one is going to do something different. It is going to tell you which specific requirements deal with insider risk, quote them so you can check the wording yourself, and give you work you can start this week.
Two different problems that get the same name
CISA splits insider threats into unintentional and intentional. Unintentional breaks down further into negligence, where someone knows the policy and ignores it, and accidents, where someone simply makes a mistake. Intentional insiders are the ones acting on a grievance or for personal gain. There are also collusive insiders, who are recruited by an outside actor, and third-party insiders, meaning contractors and vendors who were given access to get their work done.
That taxonomy matters, because the two categories fail in completely different ways.
The negligent or accidental insider emails a drawing to the wrong address, copies a job folder onto a personal flash drive to work on at home, or leaves an account active for a machinist who left in March. Nobody meant harm. The CUI left the boundary anyway.
The malicious insider is rarer and behaves differently. They go looking for things they do not need. They copy in volume. They act right around a termination or a bad review.
Controls that catch one often do not catch the other. Training reduces accidents and does very little against someone deliberate. Logging and least privilege constrain the deliberate insider and do not stop a well-meaning employee from using a thumb drive nobody told them not to use. You need both, and knowing which is which tells you where to spend a limited budget.
What the standard actually says
CMMC Level 2 is built on NIST SP 800-171 Revision 2. That is worth saying plainly because Revision 3 exists and people mix them up. Under 32 CFR 170.14, the CMMC Model incorporates NIST SP 800-171 R2, and Level 2 security requirements are identical to the requirements in R2. Revision 3 is not the CMMC Level 2 standard today. Practice identifiers still use the familiar format, so AC.L2-3.1.5 is still AC.L2-3.1.5.
Here are the requirements that bear directly on insider risk, quoted from Revision 2.
Limit the reach of an account. 3.1.1 requires you to “Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).” 3.1.2 requires you to “Limit system access to the types of transactions and functions that authorized users are permitted to execute.” 3.1.5 requires you to “Employ the principle of least privilege, including for specific security functions and privileged accounts.”
Split the jobs that could be abused. 3.1.4 requires you to “Separate the duties of individuals to reduce the risk of malevolent activity without collusion.”
Keep ordinary users out of administrative functions. 3.1.7 requires you to “Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.”
Be able to reconstruct what happened. 3.3.1 requires audit logs “to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.” 3.3.2 requires that “the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.” 3.3.8 requires you to protect audit information and logging tools “from unauthorized access, modification, and deletion,” and 3.3.9 limits management of audit logging to a subset of privileged users. Those last two exist precisely because the insider you are worried about may be the one with the keys.
Teach people what to look for. 3.2.3 requires security awareness training “on recognizing and reporting potential indicators of insider threat.”
Close out stale accounts. 3.5.6 requires you to “Disable identifiers after a defined period of inactivity.”
Control removable media. 3.8.7 requires you to “Control the use of removable media on system components.”
Vet people before you let them in. 3.9.1 requires you to “Screen individuals prior to authorizing access to organizational systems containing CUI.”
The one most small shops miss
Requirement 3.9.2 reads, in full:
“Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.”
That is the whole requirement. The Revision 2 discussion text is where it gets useful. It names returning system-related property and conducting exit interviews, and defines system-related property as hardware authentication tokens, identification cards, system administration technical manuals, keys, and building passes. It notes that for terminations for cause, “timely execution is essential,” and that organizations may consider disabling accounts before the person is notified. It also extends to reassignments and transfers when the change is permanent or long enough to require protection.
Read that last part again, because it is the part shops skip. A transfer counts. The machinist who moves from a defense job to a commercial one still has access to the defense job’s folders unless somebody removes it. In small firms, access almost always accumulates and almost never gets taken away.
What to actually do
Write an offboarding runbook and time it. One page. Who gets called, in what order, and how fast. Disable the account, recover the badge, the token, the keys, the laptop, and any printed drawings. Assign it an owner by name, not by department. Then run it on your next departure and write down how long each step took. That record is your evidence.
Treat transfers as offboarding events. Same runbook, different trigger. When someone changes roles, remove the access the old role needed before you add the access the new one needs.
Do a quarterly access review you can finish in an hour. Print the list of who can reach CUI. Have the supervisor who actually knows the work sign off line by line. Remove anything nobody can justify. This is the cheapest thing on this list and it satisfies part of 3.1.1, 3.1.5, and 3.5.6 at once.
Separate the administrator from the auditor. If the same person can grant access, use it, and edit the logs, you cannot satisfy 3.1.4, 3.3.8, or 3.3.9 no matter what tooling you buy. In a 20 person shop this usually means the log review goes to someone outside IT, or to an outside party.
Make the insider threat training specific. Generic phishing training does not meet 3.2.3. The training has to cover recognizing indicators and, just as importantly, how to report them. Tell people exactly who to tell. If there is no answer to “who do I tell,” nobody tells anybody.
Decide your removable media position and write it down. Blocked entirely, or allowed on specific approved devices. Either answer is defensible. No answer is not.
Where the CMMC program stands right now
This part changed recently and is still unsettled, so here is what is actually documented rather than what people are saying.
On July 13, 2026, the Department of War CIO issued a memorandum suspending the phased implementation schedule, including the November 2026 transition to Phase 2. Under its Attachment 1, program managers and requiring activities “must only include the need for CMMC Level 1 (Self) or Level 2 (Self) assessments” and “may not designate CMMC Level 2 (C3PAO) or Level 3 (DIBCAC) assessments during this period.” Existing solicitations and contracts carrying those requirements are to be amended or modified to remove them. No waivers are granted during the review.
The same document is explicit about what did not change. During the suspension the Department “will enforce baseline compliance with NIST SP 800-171 Rev 2 through CMMC Level 1 and CMMC Level 2 self-assessment and select Government-led assessments,” and the requirements in DFARS 252.204-7012 “remain in effect.”
Further guidance was promised at the conclusion of a 60 day CIO review. As of today, that guidance has not been published. So the honest summary is this: the third-party assessment deadline you may have been planning around is not currently live, your obligation to implement all 110 Revision 2 requirements is, and your self-assessment score and DFARS obligations are still real. Treat the pause as time, not as relief.
If you want help
Asteroid IT is based in Gilbert and works with Arizona defense contractors on CMMC Level 2, led by a Cyber AB Registered Practitioner (RP). If you want a second set of eyes on your offboarding process or your access review, ask. If reading this was enough and you go fix it yourself this afternoon, that is a good outcome too. We would rather you be protected than be a customer.