03.02.02: Role-Based Training

To meet the 03.02.02: role-based training requirement, you must identify job roles that can affect the confidentiality of CUI and assign targeted security training to each role, then prove completion and effectiveness with durable records. Build a role-to-training matrix, deliver training on a defined cadence, and retain evidence that maps roles, content, attendance, and outcomes. ¹

Key takeaways:

• Role-based training is separate from general security awareness; it must be tailored to specific duties that touch CUI. ¹
• Your “control” is the role-to-training mapping plus execution evidence: assignments, completion, exceptions, and remediation.
• Auditors look for coverage gaps (admins, help desk, engineers, HR, procurement) and missing proof that training matches access and responsibilities.

03.02.02: role-based training requirement is one of the fastest ways assessors test whether your program is real or just “annual training.” If people can handle CUI, administer systems that store or transmit it, or approve third-party access to it, they need training that matches the risks their role introduces. That includes high-impact technical roles (system admins, security engineers) and operational roles that often get missed (program management, contracting/procurement, IT support, and anyone processing CUI in ticketing, email, or file shares).

Operationalizing this requirement is mostly a scoping and documentation discipline problem. You need a clean role inventory, a mapping from role to required modules, and a reliable way to show who took what and when. If your environment includes third parties, you also need a decision on whether they fall under your training program or must provide equivalent training with proof. NIST SP 800-171 is explicit that requirements apply to nonfederal systems handling CUI; your job is to translate that into enforceable onboarding, access governance, and recurring evidence collection. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.02.02 (Role-Based Training).” ¹

Operator meaning: You must provide security training that is role-based: tailored to the tasks and privileges of specific roles, especially roles that can affect the confidentiality of CUI or the systems that process it. General awareness training alone does not satisfy role-based expectations because it does not address role-specific error paths (for example, privileged command use, secure configuration, or handling CUI in business workflows). ¹

Plain-English interpretation (what this really requires)

You need a repeatable method to:

1. Define roles that have CUI handling responsibilities or can materially affect CUI protection (directly or indirectly).
2. Assign training that matches each role’s risk and responsibilities.
3. Verify completion and respond to non-completion (block access, escalate, or document exceptions).
4. Prove it with records that an assessor can trace from a person → their role → their system access → required training → completion and follow-up. ¹

A practical test: pick a random system administrator with access to CUI systems. Can you show (a) what “admin role” training they were required to take, (b) when they took it, (c) what it covered, and (d) what you do if they don’t complete it? If any link is missing, 03.02.02 will fail in an assessment.

Who it applies to

Entities: Federal contractors and other organizations operating nonfederal systems that handle CUI and are implementing NIST SP 800-171 controls. ¹

Operational contexts where 03.02.02 is commonly in scope

• Teams that store/process/transmit CUI (engineering, program teams, operations).
• IT roles with privileged access to systems where CUI exists (sysadmins, cloud admins, directory services, network admins, endpoint management).
• Security roles that configure controls (SOC, vulnerability management, incident response).
• Business functions that can disclose CUI through process mistakes (contracts/procurement, HR handling personnel-related CUI, finance handling CUI-linked invoices, customer support working tickets with CUI).
• Third parties (MSPs, consultants) if they access your CUI environment, depending on how you structure contractual obligations and access controls. ¹

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

1) Set scope: define “roles that need role-based training”

Create a short list of role categories. Start from access, not org chart.

• Privileged technical roles: system administrators, cloud admins, IAM admins, network engineers.
• CUI handlers: anyone who creates, edits, stores, emails, uploads, prints, or disposes of CUI.
• Approval/gatekeeping roles: hiring managers granting access, procurement approving third parties, project managers directing where data lives.
• Incident roles: incident responders, IT service desk, legal/compliance if they coordinate notifications. ¹

Output: a “Role Inventory” with role names, descriptions, and which systems/data types (CUI) they touch.

2) Build a role-to-training matrix (your core artifact)

Create a Role-Based Training Matrix with columns:

• Role name (standardized)
• Population (employees, contractors, third parties)
• Trigger (hire, role change, privileged access grant)
• Required modules (titles + brief objectives)
• Delivery method (LMS module, live session, tabletop)
• Recurrence rule (your policy-defined cadence)
• Evidence source (LMS report, sign-in sheet, ticket ID, quiz record)
• Owner (who maintains content and assigns training) ¹

Example role mappings (adapt to your environment)

• System Administrator: privileged access hygiene, logging expectations, secure configuration baseline, change control, backup/restore handling for CUI systems.
• Help Desk: identity verification scripts, secure remote support, ticket handling rules when CUI appears, phishing reporting workflow.
• Engineering/CUI Users: marking/handling rules, approved storage locations, secure sharing, encryption expectations, export controls flags if relevant to your program.
• Procurement/Third-party managers: onboarding a third party with CUI access, contract clauses requiring safeguards, access request workflow, offboarding triggers. ¹

3) Tie training assignment to access governance

Role-based training fails when it’s optional or detached from access.

• Add a control point: no privileged access without required role training (or a documented exception approved by the control owner).
• Automate where possible: map AD/Azure AD groups or HR job codes to LMS assignment rules.
• Ensure role-change events trigger reassignment: promotions into admin roles, transfers into programs handling CUI, new third-party engagement. ¹

4) Deliver training and measure completion (with consequences)

Decide how you will drive completion:

• Standard assignment workflow (LMS)
• Reminders and escalation path (manager → HR → access removal)
• Documented exception process (rare, time-bound, compensating controls)

Include a lightweight effectiveness check:

• Role-specific knowledge checks (quizzes) for privileged roles
• Tabletop exercises for incident roles
• Spot checks of correct CUI handling in tools (for example, whether CUI is being stored only in approved locations) ¹

5) Collect evidence continuously (don’t “scramble for audit”)

Assessors want traceability. Create an evidence pack you can regenerate on demand:

• Export LMS completion reports by role
• Keep versioned training content (slides, module IDs, change logs)
• Keep rosters and attendance for live sessions
• Track exceptions and remediation actions (tickets) ¹

A tool like Daydream helps by mapping 03.02.02 to your policy/control language and by running recurring evidence collection workflows so you always have current exports, rosters, and approvals in one place instead of rebuilding them during an assessment. ¹

Required evidence and artifacts to retain

Minimum artifacts most assessors expect to see for 03.02.02:

• Role-Based Training Policy/Standard (defines who needs role-based training, triggers, and consequences). ¹
• Role Inventory (list of roles in scope and definitions).
• Role-Based Training Matrix (role → required modules → recurrence → evidence source).
• Training content for each role (module outlines, slides, lab guides, tabletop materials) with version control.
• Assignment records (screenshots or exports showing training assigned to a role population).
• Completion records (LMS exports, certificates, quiz results, attendance sheets).
• Exception log (who was exempted, why, for how long, compensating controls, approvals).
• Remediation records (escalations, access suspension, make-up training tickets). ¹

Common exam/audit questions and hangups

Expect these questions from internal audit, customers, or assessors:

• “Show me how you determined which roles require role-based training.” (They want a defensible method, not opinions.)
• “Pick a privileged admin. Prove they completed the admin-specific training.” (They will sample.)
• “What happens if training is overdue?” (They expect enforcement, not reminders only.)
• “How do contractors and third parties get covered?” (They expect a consistent rule: train them, or require equivalent proof and contractually bind it.)
• “How do you update training when systems or threats change?” (They expect content ownership and change control.) ¹

Frequent implementation mistakes (and how to avoid them)

1. Only annual awareness training.
   Fix: maintain separate modules for privileged and CUI-handling roles, and document the distinction in the matrix. ¹

2. Roles defined by org chart, not access.
   Fix: derive roles from IAM groups and system privileges, then reconcile to HR titles.

3. No trigger on role change.
   Fix: integrate HRIS/IAM events with LMS assignment rules; at minimum, add a checklist item to access request approvals.

4. Evidence is not reproducible.
   Fix: schedule periodic exports and store them with a naming convention and retention rule; keep module versions.

5. Third parties ignored.
   Fix: decide: (a) include them in your LMS, or (b) require training attestations plus contractual obligations and validate before access is granted. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is assessment failure and contractual exposure if you cannot demonstrate that people with high-risk access received training appropriate to their role, especially for CUI environments. Under NIST SP 800-171-driven customer assessments, training gaps often cascade into findings in access control, incident response, and configuration management because untrained admins and users create repeatable control failures. ¹

Practical 30/60/90-day execution plan

First 30 days (establish the control design)

• Name an owner: Security/GRC owns the standard; HR and IT co-own role definitions; IT owns access enforcement.
• Build the Role Inventory (start with privileged access groups and known CUI programs). ¹
• Draft the Role-Based Training Matrix with “must-cover” roles: sysadmin, help desk, CUI users, incident responders, procurement/third-party sponsors.
• Decide evidence system of record (LMS + GRC repository) and retention approach.

Day 31–60 (implement and connect to operations)

• Publish the role-based training standard and make it enforceable through onboarding and access request workflows. ¹
• Configure LMS assignments by role group or job code.
• Launch training for the highest-risk roles first (privileged admins and incident roles).
• Create the exception workflow and approval routing; test it with one realistic edge case (new admin onboarding mid-project).

Day 61–90 (prove operation and readiness)

• Run a sampling exercise: select people from each role and verify traceability from role → required training → completion evidence.
• Add at least one effectiveness mechanism per high-risk role (quiz, lab validation, or tabletop outcome notes).
• Formalize recurring evidence pulls and store them in an audit-ready folder or a platform workflow (Daydream can automate recurring collection and mapping to 03.02.02). ¹

Frequently Asked Questions

Does annual security awareness training satisfy 03.02.02?

By itself, it usually won’t. 03.02.02 expects training tailored to job roles, especially privileged or CUI-handling roles. Keep awareness training, but add role-specific modules and document the mapping. ¹

Which roles are “must include” for role-based training?

Start with roles that can materially affect CUI: system/cloud/IAM admins, help desk with remote access, incident responders, and personnel who regularly handle CUI in business workflows. Your role inventory should be access-based so you can defend it to an assessor. ¹

How do we handle contractors or third parties with CUI access?

Choose one rule and enforce it: enroll them in your training program, or require equivalent training and retain proof before granting access. Document the decision and tie it to access provisioning and offboarding. ¹

What evidence is strongest in an assessment?

A role-to-training matrix plus system-generated completion exports (LMS), backed by versioned content and an exceptions/remediation log. Assessors want to trace a sampled person’s access and see training that matches that access. ¹

How do we keep the training content current without boiling the ocean?

Assign a content owner per module and update when systems, tools, or procedures change (for example, new secure file-sharing platform or new incident workflow). Keep version history so you can show what a learner saw at the time they completed training. ¹

We have a small company. Can one module cover multiple roles?

Yes, if the content still maps cleanly to the responsibilities of each role and you can show that assignment is role-driven. Keep the matrix explicit: one module can satisfy multiple roles if objectives match. ¹

Footnotes

1. NIST SP 800-171 Rev. 3