CMMC Level 2 Practice 3.2.2: Ensure that personnel are trained to carry out their assigned information security-related

CMMC Level 2 Practice 3.2.2 requires you to ensure personnel are trained to perform the specific security duties tied to their roles (not just general awareness). To operationalize it quickly, build a role-based training matrix for your CUI environment, deliver targeted training to each role, and retain durable evidence (assignments, completion records, and competency checks) for assessors. ¹

Key takeaways:

• Map training to security responsibilities by role (admins, engineers, help desk, incident responders), not “everyone takes the same course.”
• Make training provable: assignments, completions, content, and periodic checks must be easy to retrieve for the assessment boundary.
• Treat third parties with access to CUI systems as “personnel” for training purposes if their duties include security-relevant tasks.

For most CMMC Level 2 programs, training fails in a predictable way: the organization can show annual security awareness, but cannot show that people with security responsibilities were trained to execute those responsibilities in the CUI environment. Practice 3.2.2 closes that gap by focusing on “assigned information security-related” duties, which often sit with IT operations, security engineering, HR/onboarding, system owners, and service desk teams. ²

This requirement page is written to help a Compliance Officer, CCO, or GRC lead stand up an assessor-ready implementation with minimal debate. The operational goal is simple: for every role that touches your CMMC scope, you can show (1) what security tasks the role performs, (2) what training covers those tasks, (3) that the right people took it, and (4) that you can reproduce the evidence on demand. ³

If you already have training, you may only need to reorganize it into a role-based structure and fix evidence capture. If you do not, you will build a small, auditable program that scales: defined roles, a training matrix, delivery and tracking, and recurring refresh and updates when responsibilities or systems change. ²

Regulatory text

Excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.2.2 (Ensure that personnel are trained to carry out their assigned information security-related).” ¹

What the operator must do:
You must ensure that people who have information security responsibilities receive training that is specific to those responsibilities, and you must be able to prove it to a CMMC Level 2 assessor. General security awareness is necessary, but it does not satisfy 3.2.2 by itself if the person’s job includes security tasks (for example, managing access control, reviewing logs, handling incidents, approving changes, or administering secure configurations). ²

Plain-English interpretation

3.2.2 means: if someone’s role includes a security duty, they need training for that duty.
Examples:

• If your help desk resets passwords, they need training on identity verification, secure reset workflows, and escalation.
• If your sysadmins manage servers in the CUI enclave, they need training on secure configuration, patching expectations, logging, and incident response handoffs.
• If a project manager approves access to a shared CUI repository, they need training on access approvals, least privilege, and how to route exceptions. ²

The assessment expectation is traceability: assigned duties → training content → evidence of completion → periodic refresh or updates when duties change. ³

Who it applies to

Entities: Defense contractors and federal contractors that handle CUI and require CMMC Level 2 alignment. ⁴

Personnel in scope:

• Employees with security-related duties (IT, security, engineering, DevOps, platform teams, system owners).
• Business roles with security approvals or control operation duties (HR onboarding/offboarding, procurement roles that manage tool access, managers who approve access).
• Third parties (MSPs, consultants, staff augmentation) who perform security-relevant work or administer systems in the CUI boundary. Treat their training as your responsibility to verify and document, even if delivery happens through their employer. ²

Operational context:
Applies most directly inside your CMMC assessment boundary: the people and systems that store, process, or transmit CUI, plus shared services that protect that boundary (identity provider, ticketing workflow for access, SIEM/log management, endpoint management). ³

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

Step 1: Identify security-relevant roles and responsibilities (make it auditable)

Create a short list of roles with assigned security duties in scope. Common CUI-scope roles:

• System Administrator (Windows/Linux)
• Network Administrator
• Security Analyst / Incident Handler
• IAM Administrator
• Help Desk / Desktop Support
• Application Owner / System Owner
• DevOps / Build & Release (if they manage pipelines or secrets)
• HR/People Ops (account provisioning triggers)
• Procurement/IT Asset (device issuance, approvals) ²

Deliverable: Role-to-responsibility map (one page per role, or a single table).

Step 2: Build a role-based training matrix

Create a matrix that answers, for each role:

• What security tasks they perform
• Required training modules (internal SOPs + external courses)
• Frequency trigger (e.g., onboarding, role change, procedure change)
• How completion is tracked
• Who owns delivery and evidence (GRC, IT, HR, Security) ²

Practical tip: keep “annual awareness” separate from “role-based security training.” 3.2.2 is the role-based piece. ²

Step 3: Define minimum training content by role (tie it to your procedures)

For each role, include training that is specific to how your environment works. Examples:

• Sysadmin: secure baseline configs used in the enclave, patch workflow, privileged access rules, log review expectations, change control steps.
• Help desk: identity verification, remote support restrictions, handling suspected compromise, phishing reporting path, when to involve security.
• Incident handler: triage, containment steps, evidence preservation, escalation tree, CUI-specific communications constraints.
• System owner: access approval criteria, periodic access reviews, data handling rules for CUI repositories. ²

Anchor modules to internal artifacts (SOPs, standards, runbooks). Assessors favor training that matches real operations. ³

Step 4: Deliver training and enforce assignment

Use an LMS if you have one; if not, you can start with controlled assignments via HRIS, ticketing, or a GRC tool plus attestations. What matters is that you can show:

• who was assigned
• when they completed
• what content they took
• who validated it ²

For third parties, require proof of completion or provide your training and track their completion before granting access to in-scope systems. ²

Step 5: Add a competency check for high-risk roles

For privileged roles, add one of:

• short quiz with pass/fail record
• tabletop exercise participation record (incident response)
• hands-on walkthrough signoff (patching, log review, access provisioning) ²

This reduces the “checkbox training” critique and gives stronger evidence that training enables performance.

Step 6: Set recurring evidence capture and review

Build a recurring control operation:

• Quarterly (or another regular cadence you choose) export training completion for in-scope roles.
• Review exceptions: overdue training, new hires not assigned, role changes.
• Document remediation (tickets, reminders, access holds). ³

Daydream (as a practical workflow): many teams use Daydream to store the training matrix, link each role to its SOPs, and schedule recurring evidence pulls so the assessor package stays current without a scramble. This aligns with the recommended approach to map 3.2.2 to documented control operation and recurring evidence capture. ⁵

Required evidence and artifacts to retain

Keep evidence in a single assessor-ready folder (or GRC system) mapped to 3.2.2:

1. Role-based training matrix (roles, duties, required training, tracking method).
2. Role descriptions or responsibility statements (job descriptions, RACI, SOP acknowledgments).
3. Training content (slides, SOPs, runbooks, vendor course outlines) with version/date.
4. Assignment records (who was assigned which training, including third parties if applicable).
5. Completion records (LMS exports, certificates, signed attestations).
6. Competency checks (quiz results, tabletop attendance, practical signoffs).
7. Exception handling (overdue training tickets, corrective actions, access restrictions where used).
8. Change triggers (evidence that training updates occur when procedures/tech change, such as change management references). ⁶

Common exam/audit questions and hangups

Assessors commonly press on traceability and scope:

• “Show me your roles with security responsibilities in the CUI boundary and the training each role receives.”
• “How do you know new hires, transfers, and contractors get assigned the right training?”
• “What training do privileged users receive that regular users do not?”
• “Show evidence for a sample set of personnel: assignment, completion, and content.”
• “How do you update training when your SOPs or tooling changes?” ⁵

Hangup: teams can produce certificates but cannot explain what security duties the person performs. Fix that with the role-to-responsibility map.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating annual awareness training as sufficient.
   Fix: keep awareness as baseline, then add role-based modules tied to duties. ²

2. Mistake: No training for business roles that approve access or changes.
   Fix: include system owners and approving managers in the matrix if they perform control steps.

3. Mistake: Training exists but evidence is scattered.
   Fix: centralize evidence, and export completion reports on a recurring cadence. ³

4. Mistake: Ignoring third-party administrators.
   Fix: require documented training completion (yours or theirs) before access to in-scope systems. ²

5. Mistake: No trigger for role changes.
   Fix: connect HR role change events to training assignment (ticket or HRIS workflow).

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this specific practice, so you should plan around assessment risk, not case law narratives. The practical risk is straightforward: if you cannot prove role-based training for security duties, an assessor may view the practice as not met, which can block CMMC Level 2 outcomes for contracts that require it. ⁴

Operationally, gaps here show up during incidents and access audits: people execute ad hoc steps, evidence handling breaks, privileged workflows drift, and your “paper controls” fail under pressure. Training tied to your SOPs is the fastest way to reduce that drift. ²

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Name an owner for 3.2.2 (often GRC with IT/security delivery).
• Define in-scope roles and build the role-to-responsibility map.
• Inventory existing training and internal SOPs/runbooks that should be training sources.
• Draft the training matrix and get IT/security signoff on role coverage. ²

Days 31–60 (Near-term)

• Create or procure missing role-based modules (start with privileged roles).
• Implement assignment and tracking in your LMS/HRIS/ticketing or GRC system.
• Run a first completion push for in-scope personnel; capture exceptions and remediate.
• Add a simple competency check for incident handling and privileged administration. ³

Days 61–90 (Operationalize and stabilize)

• Establish recurring evidence capture (export completion reports, store artifacts, document review).
• Add role-change and onboarding triggers so assignments happen automatically.
• Run an internal “mini assessment” by sampling personnel and producing an evidence packet within a short turnaround.
• Tighten documentation: version control for training content and explicit mapping to SOPs. ⁵

Frequently Asked Questions

Does annual security awareness training satisfy CMMC Level 2 Practice 3.2.2?

Annual awareness helps, but 3.2.2 focuses on training for assigned security duties by role. If someone administers systems, approves access, or handles incidents, you need training specific to those tasks. ²

Which roles usually trigger 3.2.2 scope in a CUI environment?

Privileged administrators, help desk staff with account actions, security analysts/incident responders, IAM administrators, and system owners commonly have assigned security-related duties. Build your list from what people actually do, not titles. ²

How do we handle contractors or MSP staff?

Treat them as in-scope personnel if they perform security-relevant tasks or administer in-scope systems. Require proof of training completion and retain it with your 3.2.2 evidence package. ²

What evidence is strongest for assessors?

A role-based training matrix plus training assignments, completions, and the underlying content (SOPs/runbooks or course outlines). Add quiz results or tabletop participation for high-risk roles to show competency. ⁵

We have good training content but weak tracking. Is that a problem?

Yes. 3.2.2 is commonly failed on evidence, not intent. Put completions into a system of record and schedule recurring exports so you can respond quickly to sampling requests. ³

How often must role-based training be refreshed?

The source excerpt does not set a fixed cadence. Use triggers you can defend: onboarding, role change, and material procedure/tool changes, with periodic review to catch drift. ²

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. 32 CFR Part 170; DoD CMMC Program Guidance

5. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

6. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance