Security Champions Programme Charter Template (OWASP)

Security Champions Programme Charter: [Organisation name]

Charter for a security champions programme: vision, goals, selection, time allocation, training path, duties across the development lifecycle, community rituals, metrics, recognition, rotation and governance. Aligned with the ten principles of the OWASP Security Champions Guide (securitychampions.owasp.org) and with the Education and Guidance practice of OWASP SAMM v2 (Governance business function, stream B "Organization and Culture"; core release v2.2.0, July 2026), both licensed CC BY-SA 4.0. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company with about 240 engineers in 30 product teams.

Document control

Approvals

Revision history

Contents

1. Purpose and vision
2. Scope and boundaries
3. Goals and success measures
4. Roles and responsibilities
5. Selection and nomination
6. Time allocation and manager agreement
7. Training path
8. Champion duties
9. Community rituals
10. Metrics
11. Recognition and career growth
12. Onboarding, rotation and offboarding
13. Alignment with OWASP guidance
14. Governance, budget and review
15. Glossary and references
16. Standard and licence note

1. Purpose and vision

Vision (Example): every Corvid Commerce team has a trusted, trained engineer who makes secure choices the easy default in that team's daily work, and who connects the team to the security organisation in both directions.

The programme exists to solve these problems (Example):

1. The AppSec team (6 people) cannot review designs and code for 30 teams at the speed teams ship.
2. Security findings arrive late, from scanners and penetration tests, when fixes are expensive.
3. Teams do not know whom to ask about security, so questions go unasked.
4. Security guidance written centrally does not match how each team builds software.

Champions are engineers first. They do not replace the AppSec team, approve risk on its behalf or become the team's only person responsible for security. Security remains the responsibility of every engineer and of the team's manager.

2. Scope and boundaries

3. Goals and success measures

Record a baseline for each measure before the programme starts. Without it, the first annual review cannot show change.

4. Roles and responsibilities

4.1 Roles

4.2 RACI

R = responsible, A = accountable, C = consulted, I = informed.

5. Selection and nomination

5.1 Coverage model

Example: one champion per team of up to 10 engineers, and a second champion for teams larger than 10 or teams that own payment, authentication or customer data services. For Corvid Commerce: 30 teams, 6 teams above 10 engineers or owning sensitive services, so 30 + 6 = 36 champions, which is 36 / 240 = 15 % of engineers.

5.2 Selection criteria

Prior security expertise is helpful but not required. Aim for champions from a range of levels, roles and backgrounds; a diverse group reaches more people.

5.3 Nomination process

1. The captain announces the call for champions with this charter and the time commitment.
2. Engineers self-nominate, or are suggested by peers or managers and then asked whether they want the role. Nobody becomes a champion without agreeing.
3. The engineering manager confirms the time allocation in writing.
4. The captain holds a short conversation with each candidate about motivation and expectations, then confirms the appointment.
5. The champion is added to the roster (12.1), the community channel and the Foundation training cohort.

5.4 Term

Champions serve a renewable term of [12] months (Example). At the end of each term, the champion, manager and captain agree to renew, rotate (12.3) or step down.

6. Time allocation and manager agreement

Manager agreement (Example wording): "I agree that [champion name] will spend about 10 % of working time on security champion duties for the term from YYYY-MM-DD to YYYY-MM-DD. I will plan this time in sprint capacity, include the work in performance discussions, and tell the programme captain if I can no longer support it." Signed: [manager], [champion], [captain], YYYY-MM-DD.

7. Training path

7.1 Levels

7.2 Modules

Foundation total: 1 + 3 + 4 + 4 + 2 + 2 = 16 hours. Practitioner total: 6 + 6 + 2 + 6 + 4 = 24 hours. Both match 7.1.

8. Champion duties

Champions are not expected to fix every security issue themselves, to approve exceptions, or to be on call for security outside the team's normal arrangements.

9. Community rituals

10. Metrics

Example quarter for Corvid Commerce: 28 of 30 teams have a champion (SCM-01 = 93.3 %); 24 of 26 champions appointed for more than 3 months completed Foundation (SCM-02 = 92.3 %); 22 of 34 appointed champions attended at least 2 of 3 meetings (SCM-03 = 64.7 %); 41 of 58 new features had a threat model or design review (SCM-04 = 70.7 %); median High remediation time fell from 34 to 26 days, a reduction of (34 − 26) / 34 = 23.5 % against the 30 % target.

11. Recognition and career growth

1. Career framework: the champion role is recognised as evidence of technical leadership and influence beyond the team in the engineering career ladder (career/engineering-career-ladder) and promotion packets (career/promotion-packet).
2. Performance reviews: the captain provides written input on each champion's contribution to the line manager before each review cycle (career/performance-review).
3. Visible thanks: monthly shout-outs in the newsletter and engineering all-hands, with the champion's agreement.
4. Development: funded external training or conference attendance (section 6) and access to advanced material and mentoring by the AppSec team.
5. Awards: an annual recognition at the summit for impact, chosen by a panel of champions and AppSec, based on outcomes rather than activity counts.
6. Path into security: champions who want a security career get priority consideration for AppSec openings and rotation opportunities.

12. Onboarding, rotation and offboarding

12.1 Roster

12.2 Onboarding

New champions receive within their first two weeks: a welcome session with the captain, a buddy from among experienced champions, access to the community channel and tools, the Foundation schedule, and an introduction to the AppSec contact for their area.

12.3 Rotation and offboarding

1. When a champion changes team, leaves or steps down, the manager tells the captain at least [4] weeks ahead (Example) where possible.
2. The outgoing champion hands over open items (threat models, findings, PSIRT cases) to the backup or successor and records them in the team's backlog.
3. The captain starts selection (5.3) for the team and invites the outgoing champion to stay in the community as an alumnus.
4. Offboarding removes elevated tool access granted for the role within [5] business days (Example); see Access Review (ops/access-review).

13. Alignment with OWASP guidance

13.1 OWASP Security Champions Guide principles

13.2 OWASP SAMM Education and Guidance, stream B

The SAMM v2 Education and Guidance practice (Governance business function) has two streams: Training and Awareness (A) and Organization and Culture (B). Stream B describes a path from naming a security champion in each development team (level 1), through a secure software centre of excellence (level 2), to an organisation-wide secure software community (level 3). Use a SAMM assessment (security/samm-assessment) to score the current level.

14. Governance, budget and review

14.1 Budget (Example)

Check: 28,800 + 6,000 + 3,000 + 7,200 = 45,000.

14.2 Risks

14.3 Exceptions and review

Teams that cannot provide a champion (for example a team of two engineers) are paired with a champion from a related team, approved by the captain and recorded in the roster. The sponsor and captain review the programme against section 3 every six months in the first year and annually after that, using section 10 metrics and the retrospective results, and update this charter through the Revision history.

15. Glossary and references

15.1 Glossary

15.2 References

Standard and licence note

Structure aligned with the OWASP Security Champions Guide (securitychampions.owasp.org) and the Education and Guidance practice of OWASP SAMM v2 (owaspsamm.org, core release v2.2.0), both published by the OWASP Foundation under the Creative Commons Attribution-ShareAlike 4.0 International licence (CC BY-SA 4.0). The ten principle names in section 13.1 are cited from the OWASP guide, and section 13.2 summarises the SAMM stream B levels in original words. If you redistribute sections 13.1 and 13.2 or other material adapted from OWASP sources, you must attribute OWASP, link to the licence, indicate changes and license that adapted material under CC BY-SA 4.0 (ShareAlike). All other text is original and written for this collection. OWASP is a trademark of the OWASP Foundation; this template is not affiliated with or endorsed by it. Check the current versions at securitychampions.owasp.org and owaspsamm.org. Template licence: MIT.