Role-based Risk Awareness
Practice statement
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.
Quoted verbatim from NIST SP 800-171 Rev. 2 §3.2.1.Source
The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.
Assessment Objectives(4)
An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.
- [a]
security risks associated with organizational activities involving CUI are identified;
1 example covers this
- [b]
policies, standards, and procedures related to the security of the system are identified;
1 example covers this
- [c]
managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and
1 example covers this
- [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.
1 example covers this
Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.
Implementation examples(1)
Submit your own example- addresses
AT.L2-3.2.1Role-based Risk Awareness
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.
[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.
Three audiences, three risk briefings: shop floor, engineers, IT admins
ControlVerdict Corpus@cv-corpusOSCJul 31, 2026Community is just starting — add yours. No verdicts yet.Implementation
AO coverage. Addresses all Role-based Risk Awareness objectives: identifying the risks, identifying the governing policies, and making all three audiences aware of both.
Identified risks. Security leads maintain a one-page risk list derived from the risk register and from incidents seen in our sector: drawing files emailed to a personal account, USB sticks carried between the shop and home, vendor techs plugging laptops into the machine network, and credential phishing against contract managers. The list is reviewed whenever the risk register changes, so awareness content tracks real exposure rather than a canned curriculum.
Identified policies. The CUI handling policy, acceptable use, media handling SOP, and the incident reporting card are published in the policy portal with version numbers. Each awareness module cites the specific policy sections it teaches, so a user who wants the authoritative text can find it in one hop.
Delivery by audience. Users get a 20-minute annual module plus monthly simulated phishing. Shop-floor staff who do not have individual mailboxes receive the same content as a supervisor-led toolbox talk with a signed attendance sheet — the LMS record is created by HR from that sheet. Managers get an added segment on approving access, escorting visitors, and what they must escalate. Systems administrators get a separate technical session covering privileged account handling, change control, and log review duties.
Making it stick. New hires complete the module before enclave access is granted; the access request cannot be fulfilled without the completion record. Phishing simulation failures assign a short remedial module, and repeat failures escalate to the manager rather than to HR discipline on the first offense.
Maintenance. Content is refreshed annually and after any incident or near-miss that would have been prevented by awareness. Completion is reported to leadership quarterly with a named list of overdue staff.
Accepted gap. Seasonal temporary machinists rotate faster than the annual cycle. They receive an abbreviated in-person briefing on day one and are excluded from CUI systems entirely; their kiosks reach only the production scheduling app.
What the evidence looks like
- One-page risk list with revision history, traceable to the risk register
- Policy portal index showing versions of the policies cited in training
- LMS completion report by role for the current cycle, plus the toolbox-talk attendance sheets
- Administrator session agenda and sign-in sheet
- Access request ticket showing training completion as a fulfillment prerequisite
Environment
Precision machining supplier, ~140 staff across two buildings. CUI lives in engineering drawings and one ERP module; most shop-floor users work from shared kiosks and rarely open email.Tools
Discussion(0)
No discussion on this control yet
Edge cases, scoping questions, and “would this pass?” scenarios belong here.
Sign in to start a thread.