Last quarter, an accounts payable clerk who can approve changes to vendor bank details, an engineer with production credentials, and a contractor working the support queue all got the same annual security module.
A role-based training program would put the first two on different paths. The contractor, whose title in the HR system matches no department, would stay on the default, holding access levels the title doesn't account for.
This guide covers how to build paths for the roles most programs name, then spends longer on the harder problem of assigning training when your organization isn't sorted by role. It also covers the frameworks that already require differentiated training and what to ask a platform before you buy.
What is role-based security awareness training?
Role-based security awareness training assigns content by an employee's job function, system access, and actual threat exposure, rather than delivering one module to everyone and calling it coverage. The assignment is where implementations diverge, because a platform can only assign on attributes it can read.
Generic and role-based training cover the same threats in a different order. A developer still needs to recognize business email compromise. An accounts payable clerk still needs to understand credential theft.
What changes is the order, the depth, and the time budget. The developer's path leads with secure coding and dependency risk and treats BEC as a shorter module; the clerk's path inverts that. Role-based training that removes topics entirely creates new blind spots, which is a different failure from the one it set out to fix.
Generic training is built for an employee who doesn't exist
One annual module is written for the average employee, so it fits nobody in particular. Vendors build it that way on purpose. Vendors produce a library module once and ship it to every customer, so it has to work for a hospital, a bank, and a logistics company at the same time. Specificity is the first thing cut, including anything drawn from threat intelligence about one industry.
Employees notice. A module about an attack nobody in their job has ever seen reads as a compliance exercise, so they treat it like one and click through. Irrelevance and disengagement are the same problem, and over time they wear down your security culture, because people learn that security is something to get through.
Why completion rates measure the wrong thing covers what that does to the numbers you report.
Five roles, five different attack surfaces
Each role faces different cyber threats. A training path is easier to judge when it's written as something a person does. "Awareness of social engineering" describes a slide. "Verify a payment change out of band" describes an action you can look for in the data. Each of the five paths below names the attack vectors it responds to and the habit it builds.
1. Engineers: Credential phishing and supply chain risk
Engineers get phished for credentials to source control and cloud consoles, and they carry two exposures most employees don't: malicious dependencies and secrets committed to repositories. The habit to build is suspicion of any authentication prompt that shows up outside the normal flow, followed by verification before entering credentials.
The format needs to change along with the content. Build this role's training around code: vulnerable and hardened implementations side by side, live coding examples, and coding assessments. Video and a quiz can stay in the module, but they shouldn't carry it.
2. Finance teams: Invoice fraud and payment verification
Invoice fraud and vendor impersonation usually arrive, often as phishing emails, with a deadline attached to a wire approval. Finance staff need to verify any payment change out of band, calling a number already on file instead of the one in the message. Phishing simulations built around payment-change requests give the path something to measure.
The attack chain typically ends at one person's decision about whether to change the bank details. A trained habit at that point can stop the loss.
3. Executives and assistants: Deepfake impersonation and whaling
Whaling, a form of spear phishing aimed at senior leaders, now comes with deepfake video and cloned audio, often on a channel the executive doesn't normally use (a smishing text, for example) and framed as urgent. Whoever appears to be asking, the habit is the same: confirm through a known channel before approving anything.
Assistants belong in this path with the executives they support. They hold calendar access, travel details, and often delegated authority, and they're frequently the easier target. The human threats landing on trained workforces in 2026 walks through how these attacks run in practice.
4. IT and help desk: Voice phishing and reset requests
Help desk staff take the calls attackers make. Voice phishing (vishing), social engineering attacks on password and MFA resets, and MFA fatigue prompts are the main routes in. This path trains one check: verify identity through an independent channel before acting on any access request, including one that sounds urgent and internal.
IT administrators hold privileged access, so the path matters at both ends of the exchange, for the credentials they hold and for the ones they can grant. A reset granted to the wrong caller can be the first step in a ransomware attack.
5. HR and recruiting: PII handling and synthetic candidates
Recruiters handle personal data all day, where one mishandled file can become a data breach, and they're the first to meet a candidate who may not exist. Generative AI has made synthetic identities cheap enough to use for winning remote roles, and a recruiter who has never been told to expect one has no reason to look for it.
The habit is to verify identity before granting access or completing onboarding. Almost no program trains recruiting as an access path, which is why this one is usually missing.

Most organizations aren't structured by role
Role-based training assumes the org chart sorts people into clean job functions. In a lot of companies it doesn't.
Some organizations assign training by cost center, since that's the attribute the identity system holds and keeps current. The system knows which budget pays a person. It may not know that the same person approves vendor payments.
Contractors and interns, like the one in the support queue, often aren't in the standard employee record at all. The office manager who also administers building access control belongs on two paths and gets one, and so does the analyst with database rights.
Regional teams fall under different regulations, such as GDPR in Europe, so the same title needs different content in Frankfurt than in Austin. Anyone whose access doesn't match their title is invisible to a rule that assigns on title. At the larger end of the market, each of these groups is big enough to matter by itself, and every acquisition or new region adds more.
Over-assigning closes the gap by giving everyone every path, which inflates the time budget and lands you back at generic training. Leaving the mismatched people on the default path is worse, because they're the ones most likely to hold access their titles don't imply, and that gap is where insider threats, accidental or malicious, are hardest to spot.
Assignment has to run on whatever attribute the organization actually runs on, whether that's cost center or contract type, and content has to exist for the paths that attribute creates, including ones no vendor ever listed. Someone has to know what a new path should cover, usually the subject matter experts closest to the work. An attribute with no matching module is still a gap.
Compliance frameworks require role-differentiated training
Several frameworks already require or expect role-differentiated training, so for many organizations it's a baseline they've already agreed to. If you're building the business case internally, check last year's audit before you start.
NIST SP 800-53 Control AT-3 calls for role-based training before people get system access, at a frequency the organization sets, and again when systems change or security incidents teach something. Its discussion names developers, system and database administrators, senior leaders, and procurement staff.
CMMC inherits the requirement from NIST SP 800-171. PCI DSS adds training for developers of custom software and for incident response staff on top of general awareness. HIPAA's Privacy Rule ties training to each workforce member's function (164.530), and ISO 27001 covers it under its awareness and training control (Annex A 6.3). SOC 2 prescribes no training content, so what an auditor accepts depends on the criteria you map to.
Clearing a framework's role-differentiation requirement and reducing role-specific risk are different bars. Five named paths with a completion record for each will satisfy most auditors. Whether the finance path changed what the AP clerk does when a vendor's bank details change is a separate question, and a completion record can't answer it.
Role-based training works when paths can be built as fast as they're needed
Three questions are specific enough to sit in a requirements document. Frame Security's answers are below, but the questions work on any vendor, and a yes means little until they show you how it works.
1. Can the platform produce a path that isn't already in its catalog, and how long does that take?
In Frame, security awareness training runs through AI Content Studio, which generates a module (narrative, visuals, script, and assessment) from an admin's description and reference materials instead of assigning from a fixed library.
A path nobody anticipated, such as a contractor cohort, a cost center, or a regional requirement, takes minutes to build. You review and edit it before you assign anyone.
2. What else can drive assignment besides job title?
Frame maps employees to role, department, and risk profile. Dynamic groups fill themselves from behavioral criteria like click rate, assessment score, and security signals, so nobody maintains a list by hand.
3. Does the platform report risk per path, or completions per path?
Each employee gets a Human Risk Score built from simulation outcomes, training interactions, MFA posture, and behavioral signals, so a path's effectiveness shows up as movement in risk.
Frame's human risk reduction reporting breaks that down by department, role, and location. When a score crosses a threshold, an action plan runs on its own: targeted training, a follow-up phishing or deepfake simulation, or a manager alert.

A path sets the baseline. Training that fires at the moment of failure keeps it current between scheduled assignments, and how quickly training decays shows why that gap matters.
Back to the three people from the opening. The clerk and the engineer were always going to get the right path. The contractor in the support queue is the test, and it comes down to whether the platform can build a path for a group nobody wrote a module for.
Book a demo and bring the group your current platform can't assign. You'll see a path for it built from a description in minutes.


