Picture this.

It's a Tuesday morning. Your finance team is about to watch a 20-minute module on phishing. So is your engineering team. Same video. Same examples. Same quiz at the end.

What neither group knows is that by the end of the month, one of them will face a highly targeted invoice fraud attempt - a spoofed email from a vendor they've worked with for years, arriving at exactly the right moment in a payment cycle. The other will unknowingly pull a vulnerable package into a production codebase, opening a backdoor that an attacker has been waiting on for weeks.

They both clicked "complete" on their training. They both passed the quiz.

Neither of them was ready for what was actually coming.

Generic Training Is Easy to Assign. That’s the Problem.

The case for security awareness training isn't hard to make. Verizon's annual Data Breach Investigations Report has found, year after year, that the human element is involved in the majority of breaches. People click things they shouldn't. They share credentials. They get socially engineered. Training helps.

But "training helps" and "any training helps" are very different claims.

When an employee sits through content that has nothing to do with their day-to-day reality, they don't simply fail to engage. They tune out. They learn to associate security training with wasted time. That association is hard to reverse. You've now made your job harder every year going forward, because employees arrive at your next training already checked out.

The Ebbinghaus Forgetting Curve has been well-documented in learning research for over a century.

By Jaap M. J. Murre - https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4492928/, CC BY 4.0, https://commons.wikimedia.org/w/index.php?curid=143131931

Without reinforcement and relevance, people forget roughly half of new information within an hour. Most of what remains is gone within a day. Generic training that doesn't connect to someone's actual work evaporates almost immediately.

This is not a motivation problem. It's a design problem.

And for security teams, it creates a very practical issue. The easiest program to assign is often the least useful program for the people receiving it.

Why Security Teams Got Stuck With This

Most security awareness platforms were built with compliance in mind, not learning. The goal was to get everyone through the content and generate a completion report. Role-specific delivery was an afterthought, if it was a thought at all.

The result is a category built around the lowest common denominator. One piece of content. Maximum coverage. Minimum friction for the security team to deploy it.

That made sense when attacks were more uniform and when the tooling didn't exist to do anything more sophisticated. It doesn't make sense now.

And security leaders know it.

In our conversations with CISOs and awareness leads, role-based training comes up constantly. It’s something they've been wanting to do for years and haven't been able to execute cleanly with the tooling available to them.

The hard part is not agreeing that finance and engineering need different training. Most security teams already agree with that.

The hard part is running it without turning the awareness program into a spreadsheet exercise.

You have to map content to departments. Keep that content current. Assign the right modules to the right employees. Prove completion. Satisfy compliance. Avoid burying your team in manual administration. And still deliver training that employees don't hate.

That's where most programs fail.

The Risks Are Different by Role

The gap between a finance employee's threat profile and a developer's threat profile isn't a matter of degree. It's a different subject.

Finance and accounting teams are primary targets for business email compromise, invoice fraud, and wire transfer scams. Attackers study payment cycles, vendor relationships, and approval chains. They craft emails that look exactly right - the right name, the right context, the right level of urgency. The training that matters here is about recognizing manipulation in a context that looks completely normal.

Developers and engineers face threats that have almost nothing to do with clicking links in emails. Supply chain attacks, insecure dependencies, secrets committed to public repos, vulnerable APIs, unsafe AI-generated code are the vectors that matter. A developer who watches a generic phishing video isn't any better equipped to catch a compromised package in their build pipeline.

Executives and senior leadership are targets for deepfake voice calls, CEO impersonation, and high-value social engineering attempts that are researched, patient, and sophisticated. The prep they need involves understanding how these attacks are structured and why even skeptical, intelligent people fall for them.

Manufacturing and frontline workers often don't sit at desks. They don't have corporate laptops. The idea of a 20-minute desktop training module in this context isn't inefficient. It's logistically broken. The training format has to change entirely.

The same is true across every function in an organization. The threats are different. The workflows are different. The context is different.

Which means the training has to be different.

Role-Specific Training Has to Be More Than Custom Labels

Role-specific training is not taking a generic phishing module and changing the intro slide.

That distinction matters if you're evaluating a platform.

A useful role-specific program should deliver different training to different employee groups based on the risks they actually face. Finance should see invoice fraud and payment manipulation. Developers should see insecure dependencies, secrets exposure, and vulnerable code. Executives should see targeted impersonation and high-value social engineering. Frontline workers should get training that fits the devices, time constraints, and workflows they actually have.

It should also be easy for the security team to manage.

That part matters more than vendors like to admit. If role-based training creates hours of extra work every cycle, the program won't last. Security teams don't need another complex internal process to babysit. They need content that maps cleanly to roles, reporting that still satisfies compliance, and training that can be deployed without turning every assignment into a project.

This is why Anagram was built around role-specific content from the start.

Security awareness training, developer training, and frontline training should not feel like slightly edited versions of the same module. They should feel like they were made for the people taking them.

The best version of role-specific training does two things at once.

It feels more relevant to the employee.

And it gives the security team a cleaner way to manage risk.

That combination is the whole point.

What Happens When Training Actually Fits the Role

One of our customers rolled out Anagram's developer-specific modules to their engineering team. Developers are a notoriously hard audience to engage on security topics. They tend to be skeptical of anything that feels like box-ticking, and they're not shy about saying so.

A few weeks in, their program lead got an unsolicited direct message from one of the developers on the team.

A note saying the training was genuinely good.

That had never happened before.

It happened because the content was relevant to what that developer actually does. It spoke the right language. It covered the right threats. It treated them like someone who cares about doing their job well - which, in our experience, is exactly what most developers are.

We see a version of this with manufacturing customers too. Replacing standard desktop modules with short, mobile-friendly content designed for shift workers (content that fits into how those employees actually operate) produces measurably better engagement.

When training respects how people work, people engage with it.

What This Means for Your Current Program

If your finance team, engineering team, executives, and frontline workers are all receiving the same training, the program may be easier to administer than it is to remember.

That is a reasonable tradeoff if the goal is only completion.

It is a bad tradeoff if the goal is behavior change.

A finance employee who completes a generic training module and still wires money to a fraudulent account has technically met your compliance requirement and completely failed your security program.

A developer who passes a phishing quiz and still commits a secret to a public repo has completed the assignment and missed the risk.

That's the uncomfortable part of generic training. It can make the dashboard look healthy while leaving the actual organization exposed.

Security leaders usually know this. The question is whether their current platform gives them a practical way to do anything about it.

The Question Worth Asking

If an auditor asked you whether your employees completed security training, you could probably answer that.

If your CEO asked why your finance team and engineering team are getting identical training, what would you say?

Most security leaders don't have a great answer to that because most tools have trained the market to accept generic programs as the default.

Compliance is the baseline. It is not the goal.

The goal is behavior change. And behavior change requires relevance.

If you're trying to move from generic annual training to role-specific security awareness without adding a pile of admin work, we can show you what that looks like in Anagram.

Book a demo here.