One security person cannot watch ten teams

The math of a lean security program is brutal. One person, maybe a fraction of one, is responsible for the posture of an entire company — every engineering team, every SaaS tool, every laptop, every vendor. Meanwhile the actual risk is being created and encountered constantly by people who do not report to security: the developer who adds a dependency, the ops lead who spins up a service, the team that trials a new tool. The central function is structurally too far from where risk is born to catch most of it in time.

A security champions program is the answer that does not require hiring. Instead of trying to scale the central function, you borrow a set of eyes inside each team — a volunteer who stays in their normal role but agrees to be the local point of contact for security. The champion is not a second security engineer. They are the person who notices something looks off and knows who to tell, which shortens the distance between a problem and a response from weeks to hours.

What a champion actually does — and does not

The fastest way to kill a champions program is to make it a burden that feels like a second job. The role has to be light enough that a volunteer with a full plate can genuinely carry it:

  • Be the local contact, so the central function has one known person per team instead of a diffuse "someone should tell security." Questions route to the champion; the champion escalates what matters.
  • Carry context security lacks. The champion knows their team is about to ship a risky change, or that a tool everyone quietly relies on has never been reviewed — the kind of shadow IT that a central sweep only finds months later.
  • Nudge the small habits. Reminding the team to rotate a shared credential, close a stale access grant, or file the finding instead of ignoring it — the least-privilege hygiene that decays without someone local caring about it.
  • Help triage, not own the outcome. A champion helps decide whether a finding is urgent for their team; the security function still owns severity and the program.

Just as important is what the champion is not: they are not on the hook for fixing everything, not expected to become a penetration tester, and not a place to dump accountability the central function should keep.

Standing it up without it becoming shelfware

A champions program decays the same way a password-manager rollout decays — a burst of enthusiasm at launch, then silence. A few things keep it alive:

  • Volunteers, chosen for curiosity, not seniority. The best champion is often not the most senior engineer but the one who already asks security questions unprompted. Draft the interested, not the available.
  • A real, recurring touchpoint. A short regular sync between champions and security keeps the network warm and turns the role into a habit instead of a title on an org chart. Without it, the program quietly reverts to nothing.
  • Make the role visibly worth it. Give champions early context, a direct line, and genuine influence over decisions that affect their team. A champion who feels heard stays; one who feels like an unpaid inbox leaves.
  • Keep the ask small and the wins visible. Celebrate the near-miss the champion caught. The program earns its next volunteer by being the reason a problem got found early.

It also scales the parts of the program people avoid

A champions network quietly makes several other efforts work better because it distributes them. Security awareness lands harder when it comes from a trusted teammate than from a company-wide email nobody reads. Asset inventory stays current because someone local flags the new service instead of security discovering it in an audit. And incident response is faster when every team already has a known person who knows the escalation path before anything is on fire.

The evidence it produces

There is an audit dimension, too. Frameworks increasingly ask how security responsibility is distributed and how the organization builds a security culture beyond a single owner. A documented champions program — who the champions are, how often they meet, what they have surfaced — is exactly the kind of organizational-control evidence that drops into continuous evidence collection and shows an assessor that security is a shared function rather than one overworked person.

One honest caveat: a platform can organize the findings and context a champions network surfaces, route them to the right owners, and keep the record of how the program operates current for an auditor — it organizes and proves the work. It does not recruit your champions, sustain the culture, or make you compliant on its own; the volunteers, the meetings, and the follow-through are human work your organization owns, and which governance obligations apply to your program is a question for counsel.

You cannot hire your way to eyes on every team, but you can borrow them. A security champions program embeds a volunteer in each team as the local contact — light enough to survive a full workload, real enough to shorten the distance between a problem and someone who notices. The central function stops being the only one watching, and starts being the one that hears about it early.