Security Champions Programme Charter Template (OWASP)
Security champions charter: vision, goals, selection, time allocation, training path, duties, rituals, metrics, recognition, rotation, OWASP and SAMM mapping
使い方: Use it when you launch or relaunch a security champions programme across engineering teams. Fill goals (section 3) and agree time allocation with engineering managers (section 6) before recruiting. The main pitfall is giving champions a title without protected time, training or career recognition.
プレビュー
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
| Field | Value |
|---|---|
| Document ID | [SCP-CHARTER-001] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (programme captain) | [@appsec-lead] |
| Executive sponsor | [@vp-engineering] |
| Approvers / reviewers | [@ciso], [@vp-engineering], [@head-of-people], [@engineering-managers-group] |
| Last updated | YYYY-MM-DD |
| Classification | Internal |
| Programme start | YYYY-MM-DD |
| Teams in scope | Example: 30 product and platform teams, about 240 engineers |
| Budget holder | [@name], annual budget [amount] |
| Next review | YYYY-MM-DD (annually, plus a six-month health check in the first year) |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Head of people (career and recognition) | [@name] | [Decision] | YYYY-MM-DD |
| Engineering managers representative | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft after interviews with team leads |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; pilot with 8 teams |
| 1.1 | YYYY-MM-DD | [@name] | Example: Extended to all teams; Practitioner level added |
Contents
- Purpose and vision
- Scope and boundaries
- Goals and success measures
- Roles and responsibilities
- Selection and nomination
- Time allocation and manager agreement
- Training path
- Champion duties
- Community rituals
- Metrics
- Recognition and career growth
- Onboarding, rotation and offboarding
- Alignment with OWASP guidance
- Governance, budget and review
- Glossary and references
- 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):
- The AppSec team (6 people) cannot review designs and code for 30 teams at the speed teams ship.
- Security findings arrive late, from scanners and penetration tests, when fixes are expensive.
- Teams do not know whom to ask about security, so questions go unasked.
- 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
| In scope | Out of scope |
|---|---|
| All product, platform, mobile and data engineering teams that write or operate code (Example) | Corporate IT and end-user security awareness (handled by the security awareness programme) |
| Security activities inside the team's lifecycle: design, code, dependencies, pipelines, operations | Approving security exceptions or accepting risk (AppSec and risk owners decide) |
| Community, training and recognition for champions | Incident command (incident response roles are defined in compliance/incident-response-plan) |
| Feedback from champions into standards, tools and training | Performance management of champions (the line manager owns it, with input from the captain) |
3. Goals and success measures
| ID | Goal | Measure (see section 10) | Target (Example) |
|---|---|---|---|
| GOAL-001 | Every team has an active, trained champion | Coverage and Foundation completion | 100 % of teams by month 9 |
| GOAL-002 | Security is considered at design time | Share of new features with a threat model or security design review | 80 % by month 12 |
| GOAL-003 | Findings are fixed faster in teams with champions | Median time to remediate High findings | 30 % lower than baseline by month 12 |
| GOAL-004 | Fewer repeat weaknesses | Repeat weakness rate per CWE class | Falling for four consecutive quarters |
| GOAL-005 | Champions find the programme worthwhile | Champion satisfaction and retention | Satisfaction ≥ 4.0 of 5; annual attrition ≤ 20 % |
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
| Role | Responsibility |
|---|---|
| Executive sponsor | Secures budget and time allocation; removes blockers; reviews results each half year |
| Programme captain | Runs the programme: recruiting, training, rituals, metrics, recognition; first point of contact for champions; at least [50] % of one role (Example) |
| AppSec team | Delivers advanced training, office hours and expert reviews; answers escalations within the agreed time; supplies tooling and guidance |
| Security champion | Performs the duties in section 8 within the agreed time; shares knowledge in the team; feeds back to AppSec |
| Engineering manager | Agrees and protects the champion's time; plans security work in the backlog; recognises the role in reviews |
| People and learning team | Includes the role in career frameworks and recognition; supports training budget and records |
| Product owner | Prioritises security stories raised by the champion alongside feature work |
4.2 RACI
| Activity | Sponsor | Captain | AppSec | Champion | Eng. manager |
|---|---|---|---|---|---|
| Nominate and select champions | I | A | C | R | R |
| Protect champion time | A | C | I | I | R |
| Deliver training path | I | A | R | C | I |
| Threat modelling in the team | I | C | C | R | A |
| Triage scanner findings in the team | I | C | R | A | |
| Run community rituals | I | A/R | C | C | I |
| Report metrics | I | A/R | C | C | I |
| Recognition and career evidence | C | R | C | I | A |
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
| Criterion | Evidence | Weight (Example) |
|---|---|---|
| Interest in security and willingness to learn | Self-nomination statement; past contributions | Required |
| Respect and influence within the team | Manager and peer input | High |
| Communication and teaching ability | Has explained technical topics to others | High |
| Technical breadth in the team's stack | At least [12] months in the team or equivalent (Example) | Medium |
| Manager commitment to time allocation | Signed agreement (section 6) | Required |
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
- The captain announces the call for champions with this charter and the time commitment.
- Engineers self-nominate, or are suggested by peers or managers and then asked whether they want the role. Nobody becomes a champion without agreeing.
- The engineering manager confirms the time allocation in writing.
- The captain holds a short conversation with each candidate about motivation and expectations, then confirms the appointment.
- 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
| Item | Commitment (Example) |
|---|---|
| Time for champion duties | 10 % of working time, about 4 hours per week, planned in sprint capacity |
| Training time in the first 6 months | Additional 2 hours per week until Foundation is complete |
| Community rituals | Monthly meeting (1 hour) and quarterly workshop (half day) |
| Conferences or external training | [2] days per year, funded by the programme budget |
| Escalation if time is not protected | Champion raises with the captain; captain raises with the manager, then the sponsor |
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
| Level | Outcome | Typical duration (Example) | Evidence |
|---|---|---|---|
| Foundation | Recognises common weakness classes in the team's stack; knows the secure development lifecycle and whom to ask | 16 hours over the first 3 months | Modules completed; one threat model co-facilitated |
| Practitioner | Leads threat modelling and security design reviews in the team; triages findings with confidence | 24 further hours over months 4 to 12 | Two threat models led; one secure code review session run |
| Advanced (optional) | Acts as a mentor and specialist for a domain (for example cloud, mobile, AI features) | Individual plan | Talk or workshop delivered; contribution to a standard or tool |
7.2 Modules
| ID | Module | Level | Hours (Example) | Delivered by |
|---|---|---|---|---|
| TRN-001 | Role of a champion, programme ways of working, where to get help | Foundation | 1 | Captain |
| TRN-002 | Secure development lifecycle at [Organisation name] and the secure coding standard (security/secure-coding-standard) | Foundation | 3 | AppSec |
| TRN-003 | Common web and API weakness classes, mapped to the OWASP Top 10, with examples from our code | Foundation | 4 | AppSec |
| TRN-004 | Threat modelling basics with STRIDE (security/threat-model) | Foundation | 4 | AppSec |
| TRN-005 | Dependencies, SBOM and supply chain basics (security/supply-chain-security) | Foundation | 2 | Platform security |
| TRN-006 | Reading and triaging scanner results; false positive handling | Foundation | 2 | AppSec |
| TRN-007 | Leading threat modelling and design reviews | Practitioner | 6 | AppSec |
| TRN-008 | Secure code review practice (quality/code-review-checklist) | Practitioner | 6 | AppSec |
| TRN-009 | Vulnerability handling: how the PSIRT works and how champions support fixes (security/psirt-vulnerability-handling) | Practitioner | 2 | PSIRT |
| TRN-010 | Cloud and pipeline security for the team's platform | Practitioner | 6 | Platform security |
| TRN-011 | Security for AI features and agents in our products | Practitioner | 4 | AppSec |
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
| ID | Lifecycle activity | Duty | Core or optional |
|---|---|---|---|
| DUT-001 | Planning | Help the product owner write security acceptance criteria for features that touch sensitive data, authentication or external input | Core |
| DUT-002 | Design | Facilitate or co-facilitate threat modelling for significant changes; request AppSec review when risk is high | Core |
| DUT-003 | Implementation | Promote the secure coding standard; review security-relevant pull requests or pair on them | Core |
| DUT-004 | Dependencies | Watch dependency update and vulnerability alerts for the team's services and make sure owners act on them | Core |
| DUT-005 | Testing | Make sure security tests and scans run in the team's pipeline and that results are triaged | Core |
| DUT-006 | Findings | First-line triage of findings for the team: confirm, deduplicate, route to the right owner, flag false positives to AppSec | Core |
| DUT-007 | Vulnerability handling | Act as engineering contact for PSIRT cases affecting the team's components | Core |
| DUT-008 | Knowledge sharing | Share one security topic with the team each month (demo, write-up or short talk) | Core |
| DUT-009 | Feedback | Bring friction, gaps in guidance and tool problems back to AppSec | Core |
| DUT-010 | Incidents | Support investigation of security incidents involving the team's services, under the incident commander | Optional |
| DUT-011 | Exercises | Take part in security game days or tabletop exercises (security/tabletop-exercise) | Optional |
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
| Ritual | Cadence (Example) | Format | Owner |
|---|---|---|---|
| Champions meeting | Monthly, 60 minutes | News from AppSec, one deep-dive topic, one champion story, open questions | Captain |
| Office hours | Weekly, 60 minutes | Drop-in with an AppSec engineer for design and code questions | AppSec |
| Community channel | Continuous | Questions, alerts, shared material; AppSec answers within one business day | Captain |
| Hands-on workshop | Quarterly, half day | Capture-the-flag, secure code review of real (sanitised) code, or threat modelling clinic | AppSec |
| Newsletter | Monthly | Short digest: new guidance, notable fixes, recognition | Captain |
| Programme retrospective | Twice a year | What helps, what blocks, what to change | Captain with sponsor |
| Annual summit | Yearly | Talks by champions, recognition awards, plans for next year | Captain |
10. Metrics
| ID | Metric | Formula | Goal |
|---|---|---|---|
| SCM-01 | Coverage | Teams with an appointed champion / teams in scope | GOAL-001 |
| SCM-02 | Foundation completion | Champions who completed Foundation / champions appointed for more than 3 months | GOAL-001 |
| SCM-03 | Engagement | Champions attending at least 2 of the last 3 monthly meetings / champions | GOAL-001 |
| SCM-04 | Design coverage | New features with a threat model or security design review / new features delivered | GOAL-002 |
| SCM-05 | Remediation time | Median days from finding to fix for High findings, teams with active champion versus baseline | GOAL-003 |
| SCM-06 | Repeat weakness rate | Findings whose CWE class appeared in the same team in the previous 12 months / findings | GOAL-004 |
| SCM-07 | Satisfaction | Mean response to "The programme is worth my time" on a 1 to 5 scale, twice a year | GOAL-005 |
| SCM-08 | Retention | Champions who left the role in 12 months / average number of champions | GOAL-005 |
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
- 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). - Performance reviews: the captain provides written input on each champion's
contribution to the line manager before each review cycle (
career/performance-review). - Visible thanks: monthly shout-outs in the newsletter and engineering all-hands, with the champion's agreement.
- Development: funded external training or conference attendance (section 6) and access to advanced material and mentoring by the AppSec team.
- Awards: an annual recognition at the summit for impact, chosen by a panel of champions and AppSec, based on outcomes rather than activity counts.
- 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
| Team | Champion | Level | Appointed | Term ends | Backup |
|---|---|---|---|---|---|
| Checkout (Example) | [@name] | Practitioner | 2026-02-01 | 2027-01-31 | [@name] |
| Merchant API (Example) | [@name] | Foundation | 2026-05-15 | 2027-05-14 | [@name] |
| Edge Agent (Example) | [@name] | Foundation | 2026-09-01 | 2027-08-31 | None yet |
| [Team] | [@name] | [Level] | YYYY-MM-DD | YYYY-MM-DD | [@name] |
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
- When a champion changes team, leaves or steps down, the manager tells the captain at least [4] weeks ahead (Example) where possible.
- 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.
- The captain starts selection (5.3) for the team and invites the outgoing champion to stay in the community as an alumnus.
- 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
| Principle (OWASP name) | Where this charter applies it |
|---|---|
| Be passionate about security | Voluntary selection on interest (5.2, 5.3) |
| Start with a clear vision for your program | Vision and goals (1, 3) |
| Secure management support | Executive sponsor, manager agreement (4, 6) |
| Nominate a dedicated captain | Programme captain role and time (4.1) |
| Trust your champions | Champions decide how to apply guidance in their team; feedback loop (8, DUT-009) |
| Create a community | Rituals (9) |
| Promote knowledge sharing | Monthly team topic, newsletter, summit (DUT-008, 9) |
| Reward responsibility | Recognition and career links (11) |
| Invest in your champions | Training path and development budget (6, 7) |
| Anticipate personnel changes | Terms, backups, rotation (5.4, 12) |
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.
| SAMM level (stream B, summary) | Charter elements that provide evidence |
|---|---|
| 1: champions identified in development teams | Roster (12.1), coverage metric SCM-01 |
| 2: a secure software centre of excellence that leads developers and architects | AppSec office hours, Advanced level, champion-authored guidance (7.1, 9) |
| 3: community including everyone involved in software security | Open rituals, summit, knowledge sharing beyond champions (9, DUT-008) |
14. Governance, budget and review
14.1 Budget (Example)
| Item | Annual amount |
|---|---|
| Captain time (0.5 of one role) | Internal cost, [amount] |
| External training and conferences: 36 champions × USD 800 | USD 28,800 |
| Workshops and summit (venue, materials) | USD 6,000 |
| Recognition awards | USD 3,000 |
| Learning platform licences | USD 7,200 |
| Total cash budget | USD 45,000 |
Check: 28,800 + 6,000 + 3,000 + 7,200 = 45,000.
14.2 Risks
| ID | Risk | Mitigation |
|---|---|---|
| RSK-001 (Example) | Champion time is consumed by delivery pressure | Manager agreement; sponsor escalation; time tracked in sprint planning |
| RSK-002 (Example) | Champions become the only people doing security in their team | Duties framed as enabling the team; DUT-008 knowledge sharing |
| RSK-003 (Example) | AppSec team cannot keep up with champion questions | Office hours, response target, champion-to-champion help in the channel |
| RSK-004 (Example) | Engagement drops after the first year | Retrospectives, Advanced level, rotation, recognition |
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
| Term | Meaning |
|---|---|
| Security champion | Engineer in a delivery team who spends part of their time helping the team build securely and connects it to the security organisation |
| Programme captain | Person who runs the champions programme day to day |
| AppSec | Application security team |
| Threat modelling | Structured analysis of what can go wrong in a design and what to do about it |
| CWE | Common Weakness Enumeration: catalogue of software weakness types |
| SAMM | OWASP Software Assurance Maturity Model |
| PSIRT | Product security incident response team |
15.2 References
| Reference | Use |
|---|---|
| OWASP Security Champions Guide (securitychampions.owasp.org), CC BY-SA 4.0 | Principle names (13.1) |
| OWASP SAMM v2, Education and Guidance practice (owaspsamm.org/model/governance/education-and-guidance), core release v2.2.0, CC BY-SA 4.0 | Stream B maturity path (13.2) |
| OWASP Top 10 (owasp.org/Top10) | Training module TRN-003 |
SAMM Assessment (security/samm-assessment) | Measuring maturity |
Secure Coding Standard (security/secure-coding-standard) and Threat Model (security/threat-model) | Core material for champions |
PSIRT Vulnerability Handling Procedure (security/psirt-vulnerability-handling) | Champion role in product vulnerability cases |
Vulnerability Management Policy (security/vulnerability-management-policy) | Remediation targets for findings |
Secure by Design Roadmap (security/secure-by-design-roadmap) | Organisation-level commitments champions help deliver |
Engineering Career Ladder (career/engineering-career-ladder) and Promotion Packet (career/promotion-packet) | Recognition in career progression |
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.
関連テンプレート
Attack Tree Analysis Template
Attack tree for one attacker goal: AND/OR tree as list and Mermaid, leaf cost/skill/likelihood, path analysis, countermeasures
セキュリティエンジニアリングCIAM Solution Design Template (Passkeys, OIDC, FAPI 2.0)
Journeys and risk, proofing, passkeys and step-up, recovery, OAuth/FAPI profiles, consent and GDPR rights, B2B2C, fraud, scale, KPIs, migration
セキュリティエンジニアリングCloud Security Posture Review Template (CSA CCM v4.1)
Periodic cloud posture review: scope, shared responsibility, CSPM findings by CCM v4.1 domain, identity, exposure, data, logging, drift, risks, actions, trend