Start a security champions program by writing down what it is for, getting a manager to back it, naming one person to run it, and building a community around the volunteers. The OWASP Security Champions Guide lists ten principles that follow that order, and they work for a team of five or five hundred.
Why programs fail without a plan
A champions program is a social structure, not a tool rollout. Most failures come from the same few causes: nobody owns it, developers are volunteered without time to do the work, and the security team treats champions as free labor for triage.
The OWASP guide describes itself as vendor neutral and says one size will not fit all. Treat its ten principles as a menu, not a checklist you must complete.
The ten principles, in a useful order
- Be passionate about security. The person starting the program has to care, because early momentum depends on it.
- Start with a clear vision. Decide what champions will do and, just as important, what they will not do.
- Secure management support. Champions need time on their calendar, and only a manager can give it.
- Nominate a dedicated captain. One named person keeps the program moving.
- Trust your champions. Give them real decisions, not only chores.
- Create a community. A shared channel and a regular meeting matter more than a long charter.
- Promote knowledge sharing. Let champions teach each other.
- Reward responsibility. Recognition, career credit and learning budget all count.
- Invest in your champions. Training that fits their stack beats generic courses.
- Anticipate personnel changes. People leave and move teams, so plan for replacements from day one.
A small first version
Pick three to five teams that already ask security questions. Ask each team lead to nominate one person who is curious, not the most senior engineer. Agree on a fixed slice of time, such as a couple of hours a week, and write it in the team plan.
Hold a first meeting where the champions choose one problem to tackle together. A shared dependency policy, a pull request review checklist or a first threat modeling session all work. Early wins build the case for expansion.
What to measure
Count things you can observe without inventing a baseline: how many teams have a champion, how often the group meets, how many design reviews a champion joined, and how long findings sit before a champion picks them up. Avoid scoring individuals. The point is a healthier habit, not a leaderboard.
Common first-year mistakes
Three show up often. First, recruiting too many champions before the program can support them, which leaves people with a title and nothing to do. Second, filling the meetings with security lectures instead of problems champions brought. Third, never saying no: if a champion asks for something the program cannot deliver, say so and explain when you can.
A good test for the first year is simple. Could a champion explain, in two sentences, what the program gives them and what it asks of them? If not, revisit the vision.
Quick check
Who should run a champions program?
A dedicated captain, ideally someone from the security team who has credibility with developers. The OWASP guide lists nominating a dedicated captain as its own principle.
Should champions be volunteers or assigned?
Volunteers nominated by their lead usually do better. Assigned champions without protected time tend to fade, which is why management support is on the list.
Sources
Last reviewed: 19 October 2026.
