Security Champions: How to Build a Program That Works

Most security teams are outnumbered by roughly a hundred to one. The people who actually approve the wire transfer, reset the password, plug in the USB stick or answer the "urgent" call from the CEO are spread across dozens of teams the security function rarely talks to — and those teams are where the Verizon DBIR still finds the human element in 62% of breaches. A security champions program is the most reliable way to close that distance: it puts a trained, trusted peer inside each team, so the security conversation happens where the decisions are made rather than in a quarterly slide deck.

Champions programs have a long history in software engineering, where they are well documented and well measured. They are far rarer in the rest of the organization, which is exactly where most social engineering lands. This guide covers what a champion actually does, what the evidence says about the model, the design decisions that separate durable programs from ones that quietly die after a year, and how to measure the result.

Why a network of peers beats a bigger security team

The case for champions starts with a staffing reality. The SANS 2025 Security Awareness Report, drawn from more than 2,700 practitioners in over 70 countries, found that programs need at least 2.8 dedicated full-time equivalents to meaningfully change behavior and four or more to begin shifting culture — while lack of time and staffing remained the primary obstacle practitioners reported. Most awareness functions are a fraction of a person. The same report found 80% of organizations rank social engineering as their number one human-related risk. That is a large behavioral problem assigned to a very small team.

The second part of the case is that broadcast training alone does not hold. In an eight-month study of roughly 19,500 employees, Ho et al. (IEEE S&P 2025) found no significant relationship between recent completion of annual awareness training and the probability of failing a simulated phish, and embedded training moved failure rates by only about two percentage points. Whatever awareness content teaches, it needs continual, local reinforcement to survive contact with a busy Tuesday — and a peer sitting in the team is the cheapest reinforcement mechanism there is.

The third part is the data from the one domain where champions have been measured for years. The BSIMM, Black Duck's long-running study of real software security programs, has tracked champion networks — originally called the "satellite" — since it began with nine firms in 2008. The BSIMM16 report (2026) covers 111 organizations with roughly 3,700 software security group members and about 6,500 security champions: the champion network is nearly twice the size of the central security teams it supports, and "create or grow a security champions program" is a named governance activity in the model. Black Duck's own commentary on the data has consistently found champions concentrated among the highest-scoring firms and rare among the lowest. Correlation is not causation, and mature firms have the budget for many things. But the pattern is consistent enough across editions that it is a reasonable bet the same mechanism works outside engineering.

The security team cannot be in the room when the wire transfer is approved. A champion can.

What a champion actually does

The title is easy to award and easy to misunderstand. A security champion is not a junior security analyst, not a compliance enforcer, and not the person who gets blamed when their team fails a simulation. A champion is a member of a business team, doing that team's job, who has agreed to be the team's first point of contact for security and the security team's eyes and ears in return.

Concretely, the role in a human-risk program breaks down into four jobs:

Job	What it looks like in practice	Why security cannot do it alone
Translate	Turn a generic "beware of invoice fraud" bulletin into "here is how it would look in our AP inbox"	Security does not know each team's workflows or vendors
Reinforce	Remind colleagues of the callback rule when a real suspicious request lands; run a 5-minute drill at a team meeting	Reinforcement has to be frequent and local to survive decay
Report back	Surface the shadow spreadsheet of shared passwords, the vendor who emails from Gmail, the process everyone bypasses	These are invisible from the security office
Escalate	Recognize a live incident — a colleague who clicked, an odd MFA prompt — and get it to security fast	Time-to-report decides the outcome of most social-engineering incidents

The reporting-back job is the one most programs undervalue and the one that pays for the program. A champion who tells you the finance team routinely approves beneficiary changes by email because the "official" process takes too long has just handed you the finding a red-team engagement would have charged for — before an attacker uses it.

Designing a program that survives its second year

The failure mode is predictable: an enthusiastic launch, thirty volunteers, a kickoff session, and then silence as day jobs reassert themselves. The OWASP Security Champions Guide — written for application security but sound for any champion network — distills ten principles from programs that lasted. Six of them map directly onto human-risk programs.

1. Start with a written vision and a captain. Decide what the program is for in one sentence — "every team can recognize and report a social-engineering attempt within minutes" — and name one person in the security team who owns it. OWASP's guide is blunt that a program without a dedicated captain drifts; the captain runs the cadence, keeps the roster current and is the champions' advocate inside security.

2. Secure the time before you secure the volunteers. Agree a concrete allocation — two to four hours a month is common — with each champion's manager, and write it into the champion's objectives. This is the single decision that most determines whether the program still exists in eighteen months. Unfunded goodwill runs out; a line in a performance review does not.

3. Select for standing, not for security knowledge. The best champion in accounts payable is the person colleagues already ask when something looks odd, not the one who knows what a hash is. You can teach the security; you cannot teach the trust. Cover the highest-exposure teams first — finance, HR, executive assistants, the help desk, anyone with privileged access — because those are the people help-desk impersonation and business email compromise actually target.

4. Give champions a real toolkit and real information. A champion with nothing to say stops speaking. Feed them monthly: the templates from the last phishing simulation and how their team did, a sanitized real incident from the organization, one short drill they can run in a team meeting, and early notice of any policy change. Treat them as insiders — OWASP's "trust your champions" principle exists because programs that keep champions at arm's length get arm's-length effort back.

5. Build the community, then reward visibly. A monthly champions call, a dedicated chat channel and a shared backlog of issues they have raised turn thirty individuals into a network that learns from itself. Recognition should be public and specific — the champion whose team went from 8% to 41% report rate deserves to be named in the all-hands — and paired with tangible investment: training budget, a conference, a certification. Points and badges alone do not sustain adults with day jobs.

6. Plan for turnover from day one. Champions get promoted, move teams and leave. Keep a bench, make handover a normal part of the role and re-baseline coverage every quarter. A program that depends on the same twelve people is one reorganization away from disappearing.

Measuring a champions program without fooling yourself

The temptation is to count activity — champions recruited, sessions held, badges awarded. None of that tells leadership whether the organization is harder to socially engineer. Measure the outcomes you already track, split by whether a team has an active champion.

The metrics that show the difference fastest are the reporting metrics: the share of simulation recipients who report, the share who report after clicking, and the median time-to-first-report — the same simulation metrics that predict real resilience. Champion-covered teams should pull ahead on all three within two or three quarters, because reporting is a social behavior and champions are social infrastructure. Add the real-world equivalents: suspicious-email reports per hundred employees, callback-verification compliance in finance, and help-desk identity-check pass rates.

Then count the intelligence the program produces. Every process gap, shared credential and shadow workflow a champion surfaces is a finding; log them, fix them, and report the count and the fix rate. A program generating a steady stream of findings is doing the job no tool can.

Finally, feed the result into your risk model. A team's champion coverage, its reporting trend and its resolved findings are all signals that belong in a human risk score alongside simulation outcomes and access exposure — which is also how you decide where the next champion should go. Gartner's 2023 cybersecurity trends predicted that by 2027 half of large-enterprise CISOs would adopt human-centric security design practices; a champion network is what human-centric design looks like when it leaves the whiteboard.

The mistakes that kill champions programs

Three are common enough to name. Making champions responsible for their team's simulation results turns peers into police and ends the flow of honest information within a quarter. Recruiting only from IT and engineering builds a program that covers the teams least targeted by social engineering and skips the ones that move money. And launching without a measurement plan means that when budget season arrives, the program has enthusiasm to show and no evidence — which is how the second year gets cancelled.

Avoid those, secure the time, pick people for their standing, and treat their findings as the product. Done that way, a champions program is not an awareness initiative with extra steps; it is the mechanism by which human risk management stops being something the security team does to the organization and becomes something the organization does for itself.