Security Champions Programme Guide

Central security teams cannot review every design, pull request and pipeline change, so security knowledge has to live inside the delivery teams themselves. A security champions programme puts a trained, recognised person in each team who acts as the link to the security function, raises risks early and helps colleagues fix them. Many programmes start with enthusiasm and fade within a year because time, mandate and recognition were never agreed. This guide covers how to design, launch, run, scale and sustain a champions programme, drawing on the OWASP Security Champions Guide, OWASP SAMM and NIST SSDF. It is written for application security leads, engineering managers and CISOs, with notes for executives who must fund it.

Key takeaways

A champion is a liaison, not a substitute security team. OWASP SAMM describes the champion as the link between information security and developers, with a set number of hours each week for security work.
Formal time and management backing decide success. The OWASP guide warns that when priorities conflict, formalised priorities win, so the programme needs approval from engineering and security leadership.
Someone must run it full time. OWASP's interviews found that leading a programme is a full-time job, and a small team in larger organisations.
Recruit volunteers and invest in them. Passion, training budget, recognition and a career path keep champions engaged; assigned, unrewarded champions drift away.
Plan for people leaving. Group champions by specialism, keep a sensible ratio and run continuous onboarding so one departure does not break coverage.
Give champions somewhere to grow and make the network a budget line. A levelled path with rising mandate keeps experienced champions engaged, and protected time, a programme team and training belong in annual plans with an accountable senior owner.

What a security champion is, and is not

OWASP SAMM's Education and Guidance practice places "Identify a 'Security Champion' within each development team" at maturity level 1 of its Organization and Culture stream. SAMM describes the role in some detail:

Who: depending on team size and structure, a software developer, tester or product manager.
Time: a set number of hours per week for information security activities.
Learning: periodic briefings across security disciplines and additional training to develop subject-matter expertise.
Work: researching, verifying and prioritising security and compliance defects; taking part in risk assessments, threat assessments and architecture reviews; giving the team periodic reviews of open security issues.

A champion is not a part-time penetration tester, a compliance officer or the person who signs off releases alone. The security team keeps ownership of policy, specialist testing and risk acceptance above the agreed threshold. The OWASP guide frames the vision as democratising security knowledge in development teams, reducing dependency on the central team and governing security within those teams. Champions are also not limited to software: the same model works in infrastructure, data, cloud platform and IT operations teams.

The ten OWASP principles in practice

The OWASP Security Champions Guide is organised around ten principles. The table summarises each one and what it means in a real programme.

OWASP principle	What it asks for	Practical decision
1. Be passionate about security	Recruit volunteers, avoid assigning champions where possible, keep curiosity alive	Open call for volunteers with manager agreement; ask about security in hiring
2. Start with a clear vision for your program	A vision that is imaginable, desirable, feasible, focused and communicable	One-page operating model showing champion, engineer, lead, product owner and security roles
3. Secure management support	Formal approval from the head of IT or engineering and the security leader, with HR involved	Charter signed by engineering and security leadership
4. Nominate a dedicated captain	A dedicated leader for strategy, roadmap, community and reporting	Full-time programme lead, a small team in large organisations
5. Trust your champions	Clear mandate, freedom to experiment, involvement in security team processes	Champions may decide on risks within the organisation's risk appetite
6. Create a community	Purpose, channels, events and measurable success criteria	Chat channel, monthly meet-up, quarterly in-person or virtual event
7. Promote knowledge sharing	Formal and informal learning, rotating speakers, gamification	Lunch sessions, capture the flag events, internal talks by champions
8. Reward responsibility	Tangible and intangible recognition tailored to individuals	Awards, conference sponsorship, development plans, extended privileges for milestones
9. Invest in your champions	Formally allocated time, training budget, job titles, bonuses or promotion	Time allocation written into team capacity plans
10. Anticipate personnel changes	Continuity through ratios, training pipelines and official recognition	Specialist pools rather than a single champion per team

Designing the programme

Scope and operating model

Teams in scope: start with teams that build or run systems handling sensitive data or internet-facing services, then expand.
Coverage model: one champion per team is simple to explain but fragile. OWASP recommends against a strict one-champion-one-team model and suggests pools grouped by specialism (for example container security or API security) so knowledge survives departures. For large organisations it gives an example ratio of one champion per 25 developers.
Mandate: write down what champions may decide (for example, accepting low-severity findings within policy, approving use of a vetted library) and what must escalate to the security team.
Time: agree a fixed allocation with engineering managers and record it in capacity planning. SAMM calls for a set number of hours per week; the exact figure is a local decision, so state it in the charter and measure against it.

Network roles and routing

Most mature networks run a hybrid: every team has a named first contact, and that person can call on a specialist pool.

Role	Responsibility	Typical time model
Executive sponsor	Owns the budget line and resolves conflicts between delivery and security priorities	Quarterly review
Programme captain	Strategy, roadmap, community, metrics and reporting	Full time; a small team in large organisations
Team champion	First contact for a delivery team	Agreed fixed allocation in capacity plans
Specialist pool lead	Runs a topic pool (for example cloud, API, mobile, identity and secrets, AI-assisted development); maintains patterns and answers escalations	Larger allocation than a team champion
Engineering manager	Protects the allocation and reflects champion work in performance reviews	Part of normal management
Security team liaison	Named AppSec engineer for each pool or business unit; answers within an agreed time	Part of the AppSec role

Routing is the hidden design problem. Publish a simple map of which pool owns which question, how to reach it and the expected response time. Without it, everything still flows to the central security team and the network adds latency rather than removing it.

Responsibilities across the lifecycle

Lifecycle stage	Champion activity	Security team activity
Requirements	Raises security requirements and abuse cases in refinement	Maintains requirement catalogues and standards
Design	Leads or joins threat modelling sessions (SAMM lists champions as participants)	Facilitates high-risk threat models, reviews outcomes
Build	Reviews security-relevant changes, helps tune scanners for the team	Owns tool selection and central rules
Test	Triages and prioritises findings with the team	Runs specialist testing and penetration tests
Release and operate	Checks secrets, dependencies and configuration hygiene	Monitors, responds to incidents, handles disclosure
Learn	Shares lessons from findings and incidents with the team and community	Feeds threat intelligence and incident lessons to champions

See the Security Requirements and Abuse Cases Guide, the Threat Modelling Guide and the Secure Code Review Guide for the techniques champions use most.

Onboarding security champions

Onboarding is where most programmes either build confidence or lose people. A structured first 90 days works better than a single training course.

Agreement: the champion, their manager and the programme lead sign a short role agreement covering time allocation, mandate and expectations.
Orientation (weeks 1 to 2): meet the security team, learn the escalation routes, the secure development standard, the vulnerability management SLAs and the tools the team uses.
Foundation training (weeks 2 to 6): role-based training on common vulnerability classes for the team's stack, threat modelling basics and secure code review. NIST SP 800-218 task PO.2.2 calls for role-based training for all personnel whose responsibilities contribute to secure development.
Shadowing (weeks 4 to 8): join a threat model and a triage session led by the security team or an experienced champion.
First contribution (by week 12): lead one activity for their own team, for example a threat model for a new feature or a scanner tuning exercise, with support.
Development plan: agree a personal development plan, which OWASP lists among its reward artefacts, and set the next learning goal.

To test the onboarding path, pilot it with a small cohort of volunteer champions, collect feedback after each stage and adjust before wider rollout. If a cohort struggles, pause new intake rather than lowering the bar.

Champion levels and progression

After a year, a strong champion doing the same work with the same authority tends to drift away. OWASP's reward principle suggests milestone badges that unlock extended privileges: a mandate to review specific security policies, a mandate to decide on specific risks and a seat on security committees. Turning those milestones into explicit levels gives champions a visible path and gives managers something to recognise in reviews. The ladder below is illustrative; set the criteria to your own organisation.

Level	Entry criteria	Mandate	Recognition
1. Contributor	Volunteered with manager agreement; onboarding complete	Triage findings for own team; raise risks; join threat models	Digital badge; listed in programme register
2. Champion	Led threat models or scanner tuning for own team; core curriculum complete	Accept low-severity findings within policy; approve vetted libraries	Training budget; conference attendance
3. Specialist	Member of a topic pool; delivered internal training or a reusable pattern	Review designs in their specialism across teams; contribute to standards	Job title recognition agreed with HR; speaking opportunities
4. Lead champion	Runs a pool or business unit network; mentors new champions	Review policies before publication; decide on defined risks; committee seat	Promotion evidence; formal role in career framework

Two rules keep levels honest. Every step up adds responsibility and authority, not only rewards. And levels are re-confirmed annually, so a champion who no longer has time steps down to alumni status without stigma. OWASP's personnel changes principle also suggests building T-shaped engineers with a security specialism and rewarding that skill financially, which a levelled path makes possible to administer.

Curriculum by level and specialism

NIST SP 800-50 Rev. 1 describes a life cycle approach to learning programmes with metrics and evaluation, and SAMM's Training and Awareness stream moves from awareness for all to role-specific and then standardised in-house guidance. A sustained curriculum follows the same shape.

Core (levels 1 and 2): the vulnerability classes your scanners and testers actually find, threat modelling, secure code review, your secure development standard and vulnerability SLAs.
Specialist tracks (level 3): one track per pool, for example API security, cloud and infrastructure as code, mobile, identity and secrets, and AI-assisted development.
Leadership track (level 4): facilitating risk discussions, mentoring, writing standards and presenting to engineering leadership.
Refresh loop: each quarter, compare the top recurring finding types against the curriculum and rewrite modules that no longer match, using the network's own incidents and penetration test reports.

Rolling out the programme

Baseline: assess current practice, for example with OWASP SAMM, and record the metrics you intend to improve.
Vision and charter: draft the vision with engineering leads, product owners and senior developers, as OWASP advises, then get it approved by engineering and security leadership and HR. NIST SSDF task PO.2.3 calls for upper management commitment to secure development, conveyed to everyone with development roles.
Appoint the lead: name or hire the dedicated programme lead before recruiting champions.
Pilot: start with three to five teams that volunteer. Run onboarding, community events and metrics for one or two quarters.
Review: compare pilot teams with the baseline, gather champion and manager feedback, and fix the operating model.
Expand in waves: add teams by risk, keeping the champion-to-developer ratio and the lead's capacity in view.
Roll back safely: if a wave overwhelms the programme lead or champions report no protected time, stop expanding, restore the allocation and resume once capacity is fixed. A stalled programme is better than a nominal one that teams stop trusting.

Scaling past the pilot

Stabilise first: confirm pilot teams meet protected time and response time targets for two consecutive quarters before expanding.
Stand up the first pools: start with two or three specialisms that match your biggest risk areas, led by the strongest pilot champions.
Publish the ladder: agree levels and recognition with HR before announcing them, so promises can be kept.
Expand by business unit: name a security liaison for each unit and treat the captain's span of control as the limiting resource, adding programme staff before adding units.

SAMM shows the path beyond champions: level 2 is a secure software centre of excellence with an official charter, and level 3 is a security community open to everyone involved in software security, which in turn helps identify future champions.

Decision guidance: choosing a model

Model	Best for	Trade-offs
One champion per team	Small organisations, fewer than about ten teams	Simple, clear ownership; fragile when people leave
Specialist pools (OWASP's suggested pattern)	Large organisations with varied stacks	Resilient and deep in each topic; needs good routing so teams know whom to ask
Hybrid: team champion plus specialist pools	Organisations scaling past a few hundred engineers	Best coverage; more coordination for the programme lead
Federated network: unit leads, shared pools, programme team, full ladder	More than about 50 teams or several business units	Coordination cost; risk of uneven quality between units
Same model for non-software teams (cloud platform, data, IT operations)	Infrastructure and operations functions	Curriculum must be rebuilt for the domain, not copied from AppSec
Embedded security engineers instead of champions	Highest-risk platforms where full-time security staff are justified	Expensive; does not build security skills across the wider team on its own

Small organisations can run a lightweight version with a part-time lead, a monthly session and a shared channel, but they should still write the role agreement and protect time. Large organisations should expect to need a small programme team and HR involvement for job titles, recognition and recruitment.

Funding and governance

The UK Software Security Code of Practice asks software vendors to appoint a Senior Responsible Owner at senior leadership level, and expects senior leaders to ensure teams have the necessary skills and resources. A champion network is one of the most direct ways to meet that expectation, and the SRO is a natural executive sponsor.

Budget line items: programme team salaries; champion protected time expressed as a share of engineering capacity; training and conference budget per level; recognition budget; tooling for the community and programme register.
Governance forum: a quarterly steering meeting where the captain reports health and outcome metrics and the sponsor resolves time conflicts.
Charter review: re-approve the charter annually with engineering, security and HR.

Running the community and keeping champions engaged

The OWASP guide treats community, knowledge sharing, reward and investment as four separate principles, which reflects how much effort they take after launch. A workable annual rhythm looks like this:

Weekly: an open chat channel where champions ask questions and the security team answers within an agreed time. Track unanswered questions; slow answers are an early sign the security team is under-resourced.
Monthly: a community session with a short talk from a champion or the security team, a review of recent findings or incidents, and one practical exercise. Rotate speakers and topics, as OWASP advises, so sessions stay relevant to daily work.
Quarterly: a capture the flag event, hackathon or deeper workshop, and a metrics review with sponsors.
Annually: recognition awards, renewal of role agreements, refresh of the curriculum against the organisation's main vulnerability classes, and a programme reassessment against SAMM.

Feed champions what the security team learns: threat intelligence relevant to their stack, lessons from incidents and penetration tests, and early notice of new standards. OWASP's trust principle also asks the security team to involve champions in its own processes and to seek their input on policies, so treat champions as a review panel for new standards before they are published. Recognition should be visible to managers and HR, because a champion's work otherwise rarely appears in performance reviews. OWASP suggests milestone badges that unlock extended privileges, such as a mandate to review specific policies or decide on specific risks, which rewards growth with responsibility rather than only with gifts.

Where identity fits

Champions are often the first to see how a team handles credentials: API keys in configuration files, shared service accounts, long-lived tokens in pipelines. Make secrets and non-human identity hygiene part of the champion curriculum, and route secret-scanning alerts to the team's champion as well as to security. In the xAI API key leak, an automated scanner alert reached the developer who committed the key, but the key stayed valid for about two months until a public report reached the security team. Identity and secrets deserves its own specialist pool; see the Git Secret Scanning Guide. AI coding assistants and agents add a newer track, since champions are well placed to set team norms for reviewing generated code and scoping agent tokens; see the AI Coding Agents Security Guide. For the wider context see the Application Security Guide and the DevSecOps Guide.

Detection and measurement

OWASP's vision principle suggests goals such as hours spent on security by champions, training objectives, number of meet-ups and reduction in security risk. Split measures into health indicators, which predict whether the network will last, and outcome indicators, which show whether it reduces risk, and report both to the sponsors quarterly.

Metric	What it shows	Source
Coverage: percentage of in-scope teams with an active champion or pool	Reach of the programme	Programme register
Protected time used versus agreed	Whether the allocation is real	Champion self-report, capacity tools
Threat models completed for new features in champion teams	Earlier security involvement	Threat modelling records
Median time to remediate high and critical findings, champion versus non-champion teams	Effect on risk	Vulnerability management platform
Champion retention after 12 months	Health and sustainability	Programme register, HR
Onboarding completion within 90 days	Onboarding quality	Learning platform
Succession depth: teams with a trained second contact	Resilience; warning sign is critical systems with one trained person	Programme register
Median response time on the community channel	Security team capacity; rising times mean under-resourcing	Chat tooling
Champions progressing a level in the year	Whether the ladder is real	Programme register, HR

Avoid counting only attendance or training hours: they show activity, not whether teams ship fewer or less severe vulnerabilities. Compare like with like: champions often volunteer from already mature teams, so compare each team with its own baseline. See the Identity Security Metrics Guide for metric definitions that survive audit.

Succession, attrition and renewal

Annual renewal: champion, manager and captain re-confirm the role agreement each year, the moment to step up a level, rotate specialism or step down.
Named successors: each team champion mentors a second contact, and pools keep at least two people able to answer every common question.
Exit routine: when a champion leaves or changes role, hand over open findings, in-flight threat models and pool duties, and update the register the same week.
Alumni network: former champions who move into management or architecture stay in the community and become sponsors and recruiters for their new teams.
Hiring pipeline: OWASP suggests working with HR so recruitment favours candidates with security interest; mention the champion path in job adverts.
Reorganisation playbook: treat a reorganisation as an incident for the network, freeze champion reassignment where possible, run a coverage check within 30 days and brief new managers on the agreement.

Framework mapping

Framework	Reference	Relevance
OWASP SAMM	Governance: Education and Guidance, Organization and Culture stream	Level 1 identify champions; level 2 centre of excellence; level 3 security community
NIST SP 800-218 (SSDF)	PO.2.1, PO.2.2, PO.2.3	Define SDLC roles, role-based training, management commitment
NIST SP 800-50 Rev. 1	Learning program life cycle	Curriculum design, delivery and evaluation metrics
NIST CSF 2.0	GV.RR-02, GV.RR-04, PR.AT-01, PR.AT-02	Roles and authorities; security in HR practices; general and specialised training
NIST SP 800-53 Rev. 5	AT-2, AT-3, PM-13, SA-3, SA-8, SA-15	Awareness and role-based training, security workforce, SDLC, engineering principles, development process
UK Software Security Code of Practice	Principle 1.1 and the Senior Responsible Owner and skills expectations	Secure development framework including governance and roles; leaders ensure teams have skills
CIS Controls v8.1	Control 16 Application Software Security	Managing the security life cycle of in-house developed software, including developer training

Common failure patterns

No protected time: champions are named but their delivery targets are unchanged, so security work happens only in spare moments and stops under deadline pressure.
Volunteers by decree: managers assign the most junior person, who has neither interest nor influence; OWASP advises recruiting volunteers wherever possible.
Programme run on the side: a busy security engineer runs it alongside other work and momentum collapses after launch.
Champions as unpaid gatekeepers: champions are made to sign off releases without authority or support, and teams start to route around them.
Single points of failure: one champion per team with no pool or successor, so coverage disappears when they move on.
Levels without authority: a badge scheme with no change in mandate, which experienced champions see through.
Expansion outruns the captain: units are added without programme staff, response times rise and pilot teams lose confidence.
Curriculum frozen at launch: training covers old vulnerability classes while findings are now dominated by secrets, cloud misconfiguration or AI-generated code.
Reorganisations erase coverage: no coverage check after restructuring, so teams lose their champion silently.
Alerts that go nowhere: scanner and secret alerts reach individuals but not the champion or security team, as the xAI case above shows.

Practitioner checklist

Charter approved by engineering and security leadership, with HR involved for role recognition.
Named, dedicated programme lead in post before recruitment starts.
Written role agreement for each champion: time allocation, mandate and escalation routes.
90-day onboarding path with role-based training and a first supported contribution.
Community channel, regular meet-ups and a calendar of knowledge-sharing sessions.
Recognition scheme and training budget agreed for the year.
Network map published: team champions, specialist pools, security liaisons and routing with response times.
Levelled progression agreed with HR, each level adding mandate as well as recognition.
Curriculum by level and specialism, refreshed quarterly against real findings.
Budget line with a named executive sponsor and a quarterly steering review.
Named successor for every team, at least two people per pool topic, and annual renewal of agreements and charter.
Reorganisation playbook with a 30-day coverage check.
Quarterly metrics on coverage, protected time, remediation time and retention reported to sponsors.
Secrets and credential hygiene included in the champion curriculum, with alerts routed to champions.

Security Champions Programme Guide: Building Security into Every Team