Aim for one security champion per delivery team, meaning the group that ships and owns a service together. Do not size by a ratio of developers. A champion needs to sit inside the team's daily work, so the unit that matters is the team, with a named backup for leave and turnover.
What a champion is
A security champion is a developer or engineer who volunteers to be the first point of contact for security inside their own team. They are not a junior security analyst and they do not own every finding. They carry context both ways: bringing security guidance to the team, and bringing the team's constraints to the security group.
Why per team beats a ratio
Ratios such as "one per ten developers" sound tidy but ignore how work is organised. Ten developers on one product need one person. Ten developers split across five services need five contact points, because each service has its own pull requests, dependencies and release rhythm.
Count the teams that:
- own production code or infrastructure
- merge their own pull requests
- carry an on-call or release duty
Each of those wants a champion. Teams that only consume a platform may share one.
How to choose
Pick people who already care and already have credibility. A good champion:
- reviews pull requests and is trusted by peers
- has enough seniority to say "not this sprint" and be heard
- volunteers, rather than being assigned as a chore
Avoid making the most junior person the champion because they have spare time. The role loses weight and the person burns out.
What to expect of them
Keep the commitment small and written down. A reasonable shape:
| Activity | Typical cadence |
|---|---|
| Triage the team's new findings | Weekly, short |
| Join a champions sync | Every two to four weeks |
| Review security checklist items on risky changes | As needed |
| Raise blockers to the security group | As needed |
Agree with the manager that this time is planned capacity, not evenings. If it is unplanned, the program quietly dies.
When to add a second champion
Add a second person when the team grows large enough to split, when the champion becomes the bottleneck for reviews, or when one person leaves and the knowledge walks out with them. Pair a new champion with an experienced one for the first month.
What to measure
Do not measure the number of champions named. Measure whether their teams close findings, respond to the gate and ask for help earlier. Use team level trends, and avoid ranking teams against each other.
Quick check
Can a manager be the security champion?
It works poorly. Managers rarely triage pull requests day to day. A senior engineer is a better fit, with the manager as sponsor.
What if nobody volunteers?
Ask why. Usually the time is not protected or the role is unclear. Fix those, then ask again, rather than assigning someone.
Safeguard's dependency scanning reports findings per repository, so each champion can look at their own team's results instead of the whole backlog. A free scan shows what a team's first queue would look like.
Last reviewed: 19 October 2026.
