CMMC Level 2 Practice 3.2.3: Provide security awareness training on recognizing and reporting potential indicators of insider

To meet cmmc level 2 practice 3.2.3: provide security awareness training on recognizing and reporting potential indicators of insider requirement, you must train all users with access to CUI environments to spot insider-threat indicators and to report them through a defined, tested channel, then keep proof the training occurred and is repeated. This is a training-and-evidence control tied to NIST SP 800-171 Rev. 2. ¹

Key takeaways:

• Train for behavior: what “insider indicators” look like in your environment and what to do next. ¹
• Make reporting real: named reporting paths, response ownership, and no-retaliation expectations. ¹
• Preserve assessor-ready evidence: curriculum, attendance/completions, and periodic refresh cadence proof. ¹

CMMC Level 2 Practice 3.2.3 is narrow but easy to fail in an assessment because teams treat it as generic security awareness. The requirement is specific: your workforce must be trained to recognize potential indicators of insider threat and report them. That means your content needs insider-focused examples (not only phishing) and your operations need a reporting mechanism employees actually know and trust. ¹

For a CCO or GRC lead, the fastest path is to operationalize this as a short, role-aware training module plus an internal procedure that defines: (1) what to report, (2) how to report, (3) what happens after a report, and (4) what evidence you retain. You do not need a full “insider threat program” to satisfy 3.2.3, but you do need repeatable training delivery and durable records. ¹

This page gives you implementation steps, an evidence checklist aligned to common CMMC assessment expectations, and a practical execution plan you can run with HR, Security, and IT. It also flags the most common hangups: scope (who must take it), content specificity (what counts as “indicators”), and proof (what assessors ask for). ¹

Regulatory text

Requirement (mapped): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.2.3 (Provide security awareness training on recognizing and reporting potential indicators of insider).” ¹

What the operator must do:

1. Deliver security awareness training that explicitly covers insider-threat indicators relevant to your organization, and 2) teach personnel how to report suspected indicators using your internal reporting process. Then 3) maintain evidence that training is assigned, completed, and refreshed as part of your awareness program for the CUI environment. ¹

CMMC context: CMMC Level 2 assessments evaluate implementation of NIST SP 800-171 Rev. 2 practices for organizations handling CUI in support of DoD. Program framing and assessment expectations flow from the CMMC Program rule and DoD guidance. ^{2 3}

Plain-English interpretation (what “good” looks like)

You pass 3.2.3 when a typical employee (or contractor) with access to your CUI environment can answer, without coaching:

• “What are insider threat warning signs here?”
• “Where do I report it?”
• “What happens after I report?” (triage, confidentiality, no retaliation expectations)

This is not a requirement to accuse coworkers or perform investigations. It is a requirement to educate users on recognition and reporting so the organization can respond early (security, HR, legal, and management involvement as appropriate). ¹

Who it applies to (entity + operational context)

Entities: Defense contractors and other federal contractors handling CUI and targeting CMMC Level 2. ^{2 3}

People in scope (practical):

• Employees and long-term contractors with access to CUI or to systems that store/process/transmit CUI.
• Privileged users (admins, developers, engineers) because insider indicators often appear in access patterns and system changes.
• HR and managers need an adapted view of “reporting channels” and escalation, even if they do not access CUI daily.

Environments in scope:

• The CUI enclave or boundary (where you apply CMMC Level 2 controls).
• Adjacent systems that provide identity, endpoint management, logging, ticketing, or remote access to the CUI environment.

What you actually need to do (step-by-step)

Step 1: Define “insider indicators” for your environment

Create a short list of indicators that fit your operating reality. Keep it concrete and observable. Examples you can tailor:

• Attempts to access CUI repositories outside job role or outside normal hours
• Repeated access denials followed by privilege requests
• Bulk downloads, unusual transfers, or copying CUI to unapproved locations
• Disabling security tools, tampering with logs, or bypassing change control
• Sharing credentials, using another person’s account, or “borrowed” badges
• Behavioral red flags that intersect with security (coercion, unusual requests for data, pressure to skip controls)

Deliverable: Insider Indicators Reference (one page) with examples and “report if you see this.” Tie it back to your acceptable use and access control policies. ¹

Step 2: Publish a simple reporting procedure (one page)

Write an “Insider Indicator Reporting Procedure” that answers:

• How to report: named email alias, hotline, web form, ticket category, or chat channel; include after-hours path.
• What to include: who/what/when/where, system names, screenshots if safe, and “do not investigate” guidance.
• Where reports go: role-based inbox ownership (Security/IR), with HR involvement triggers if your policy requires it.
• Non-retaliation and confidentiality: plain language expectations; keep it realistic (no absolute confidentiality promises).
• Escalation triggers: confirmed CUI exposure, threats, violence, extortion, or privileged misuse.

Make sure the reporting path works for contractors and remote staff. ¹

Step 3: Build the training module (insider-specific)

Your annual security awareness library is rarely enough by itself. Add an insider-focused module with:

• Definition of “insider” in your context (employee, contractor, trusted third party with access)
• The indicator list (from Step 1) with short scenarios
• Reporting steps (from Step 2), including screenshots of where to click and who receives it
• Do’s and don’ts: “Do report; don’t confront; don’t collect evidence outside your role; don’t tip off the subject”
• A knowledge check (short quiz) that tests reporting, not trivia

Keep the language consistent with your incident response and HR processes so employees do not get conflicting directions. ¹

Step 4: Assign training to the correct population

Common assignment model:

• Baseline: everyone with network access
• CUI population: anyone with CUI access must complete the insider module as part of CUI onboarding and refresh
• Privileged: add a short admin addendum about logging, change control, and privileged abuse reporting

Operational tip: map assignments to identity groups (IdP groups, HRIS job codes, or LMS audiences). Manual assignment fails during turnover. ¹

Step 5: Prove it happened (evidence capture built in)

Your assessment success depends on recordkeeping:

• LMS completion reports by audience
• Training content version and last-updated date
• New-hire training completion workflow
• Exceptions and remediation actions (who was late, how you handled it)

This is where teams benefit from tooling. Daydream can track control operation, store artifacts, and set recurring evidence requests so you do not rebuild proof at assessment time. ³

Step 6: Test the reporting channel and close the loop

Run a tabletop or simple internal test:

• Submit a test insider indicator report (clearly labeled) through the real channel
• Validate who receives it, time to acknowledge, and how it’s triaged
• Document the outcome and any fixes (routing rules, mailbox ownership, ticket categories)

Assessors like to see that reporting is more than a slide deck. ¹

Required evidence and artifacts to retain (assessor-ready)

Keep these in a single “3.2.3 Evidence” folder for fast retrieval:

Training content

• Insider threat training deck/video/module content (current version)
• “Insider Indicators Reference” one-pager
• Knowledge check questions and passing criteria

Training operations

• Training policy/standard that states insider indicators + reporting are covered
• LMS assignment rules or audience mapping
• Completion reports (by name, role/group, date)
• New hire onboarding checklist showing assignment and completion tracking
• Records of refresh/retraining when content changes

Reporting operations

• Insider indicator reporting procedure (one page)
• Reporting channel proof (mailbox settings, ticket form, hotline/web form configuration)
• Escalation/triage runbook excerpt showing who reviews and how it’s handled
• Test report artifact (ticket/email) and documented results

CMMC assessors typically want to see that training is delivered, required, and tracked, and that personnel can describe the reporting path. ³

Common exam/audit questions and hangups

Expect these questions in interviews and evidence review:

• “Show me the training content specific to insider indicators.” (generic awareness often fails this)
• “Who is required to take it? Show the population logic.”
• “How do contractors get trained and how do you retain their completion proof?”
• “Where does a report go? Who monitors it if the primary owner is out?”
• “What would you do if the report involves a manager or privileged admin?” (needs alternate escalation path)
• “How do you handle anonymous reports, if allowed?” (process clarity matters)

Hangup: If your only “reporting mechanism” is “tell your manager,” you may be exposed if the manager is the subject of the report. Provide at least one alternate route. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Training is only phishing + passwords	Doesn’t address insider indicators	Add insider-specific scenarios and indicator list tied to your environment 1
No defined reporting channel	Users can’t demonstrate “reporting”	Publish a one-page procedure with named channels and ownership 1
Evidence is ad hoc screenshots	Hard to prove operation over time	Use LMS exports and a recurring evidence capture cadence 3
Contractors excluded	They often access CUI or systems in boundary	Include them in LMS or collect attestations + proof from staffing firms 1
Reporting goes to a single person	Creates single point of failure	Use a monitored queue and documented backup ownership 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so this guidance focuses on assessment and operational risk rather than case law.

Risk-wise, insider issues create two failures at once: the security incident itself and the inability to show trained, defined reporting pathways during an assessment. For CMMC Level 2, inability to produce evidence can directly threaten certification outcomes under the program structure. ^{2 3}

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum compliant control)

• Identify in-scope population for the CUI environment (employees + contractors).
• Draft the Insider Indicators Reference and reporting procedure (one page each).
• Add an insider module to your LMS (or create a tracked alternative if LMS is not available).
• Configure the reporting channel (shared mailbox or ticket category) with backup coverage.
• Start evidence capture: store content version, assignments, and initial completion exports. ¹

Days 31–60 (make it repeatable and assessable)

• Add role-based variants: privileged users, managers, and HR routing expectations.
• Run a test submission through the reporting channel; document results and fixes.
• Build onboarding workflow: new hires assigned automatically; exception handling defined.
• Centralize artifacts in a control binder (Daydream can help you keep this current with recurring evidence tasks). ³

Days 61–90 (harden and reduce assessment friction)

• Validate interview readiness: sample employees can explain indicators and reporting path.
• Review indicator list with Security/IT and update based on actual telemetry and recent issues.
• Confirm third-party workforce coverage: staffing firms, MSPs, consultants with boundary access.
• Do a mini internal audit: spot-check completions, verify reporting ownership, confirm retention. ¹

Frequently Asked Questions

Does CMMC 3.2.3 require a formal “Insider Threat Program”?

3.2.3 requires training on recognizing and reporting insider indicators, with proof it’s delivered and tracked. You can satisfy this with focused training and a functioning reporting process without standing up a standalone program. ¹

Who must take the training: everyone or only CUI users?

At minimum, assign it to personnel with access to the CUI environment or systems in the CMMC boundary. Many organizations assign a baseline to all users, then add an insider-focused module for CUI and privileged roles to reduce scope disputes. ¹

Is “report it to your manager” enough?

It’s risky because the manager could be involved or unavailable. Provide at least one alternate channel (for example, Security/IR queue or hotline) and document ownership and backup coverage. ¹

What evidence will an assessor ask for?

Expect to show the insider-specific training content, completion/attendance records, and the documented reporting path. Interview questions usually test whether personnel can describe what to report and how to report it. ³

How do we handle contractors who don’t have access to our LMS?

Put contractors into your LMS if possible; otherwise, collect completion attestations plus the underlying training record from their employer, and map it to the contractor identity and access dates. Keep the records with your 3.2.3 evidence. ¹

Do we need anonymous reporting?

The requirement is reporting capability and training, not a specific feature like anonymity. If you allow anonymous reports, document how they are received, triaged, and protected from abuse. ¹

Footnotes

1. NIST SP 800-171 Rev. 2

2. 32 CFR Part 170

3. DoD CMMC Program Guidance