# 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.

<!--
Guidance: How to use this template
- A champions programme scales a small application security (AppSec) team by placing a
  trained, motivated engineer in each team. It fails when champions get a title but no time,
  no training and no support from their managers. Write sections 5, 6 and 7 with engineering
  management in the room.
- Fill section 3 (goals) first, then decide coverage and time in sections 5 and 6, then
  build the training path. Metrics in section 10 must measure the goals in section 3.
- Keep the programme voluntary. Nominated but unwilling champions do not stay.
- Pitfall: using champions as unpaid triage staff for scanner output. Champions should
  raise the security capability of their team, not absorb the AppSec backlog.
-->

## Document control

<!-- Guidance: Name the executive sponsor and the programme captain. The sponsor protects time allocation; the captain runs the programme day to day. -->

| 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

<!-- Guidance: Record changes to time allocation, training levels, duties and metrics; champions must see what changed in their commitment. -->

| 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

<!-- Guidance: Keep aligned with the headings. -->

1. [Purpose and vision](#1-purpose-and-vision)
2. [Scope and boundaries](#2-scope-and-boundaries)
3. [Goals and success measures](#3-goals-and-success-measures)
4. [Roles and responsibilities](#4-roles-and-responsibilities)
5. [Selection and nomination](#5-selection-and-nomination)
6. [Time allocation and manager agreement](#6-time-allocation-and-manager-agreement)
7. [Training path](#7-training-path)
8. [Champion duties](#8-champion-duties)
9. [Community rituals](#9-community-rituals)
10. [Metrics](#10-metrics)
11. [Recognition and career growth](#11-recognition-and-career-growth)
12. [Onboarding, rotation and offboarding](#12-onboarding-rotation-and-offboarding)
13. [Alignment with OWASP guidance](#13-alignment-with-owasp-guidance)
14. [Governance, budget and review](#14-governance-budget-and-review)
15. [Glossary and references](#15-glossary-and-references)
16. [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and vision

<!-- Guidance: One paragraph of vision and three or four problems the programme solves. The vision should still make sense if the AppSec team doubled in size; champions are not only a staffing workaround. -->

**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

<!-- Guidance: Say which teams take part and what the programme does not cover. Infrastructure, data and machine learning teams often need a champion too; include them explicitly or say why not. -->

| 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

<!-- Guidance: Use three to five goals with a measure and a target date each. Goals that only count activity ("hold 12 meetings") do not show value; pair them with outcome 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

<!-- Guidance: The OWASP guide stresses a dedicated captain and real management support. Write down what each role owes the others; that is the contract behind the programme. -->

### 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

<!-- Guidance: Select for interest, influence and communication, not only for security skill. The best champions are respected by peers and curious; skills can be trained. Pitfall: appointing the most junior person because they have the most free time. -->

### 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

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

<!-- Guidance: Without protected time the programme is a mailing list. Put the allocation in writing and make it visible in sprint planning. The percentage below is a common starting point, not a standard value. -->

| 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

<!-- Guidance: Build a path with levels, outcomes and evidence. Use internal material on your own stack wherever possible; generic courses rarely change behaviour. Record completion so you can measure GOAL-001. -->

### 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

<!-- Guidance: List duties by lifecycle activity, and mark which are core (always) and which are optional (by team need). Keep the core list short enough to fit the time allocation. -->

| 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

<!-- Guidance: Community is what keeps champions engaged after the first training. Keep the cadence light and protect the time. Record attendance only to understand engagement, not to police it. -->

| 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

<!-- Guidance: Mix programme health (coverage, engagement) with security outcomes (design reviews, remediation time, repeat weaknesses). Compare teams with and without an active champion only with care: other factors differ. Never use these metrics to rank individual champions. -->

| 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

<!-- Guidance: Recognition must be visible and connected to career progression, or the role becomes invisible extra work. Agree this section with the people team before launch. -->

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

<!-- Guidance: People change teams and leave. Plan for it so that a team never loses all its security knowledge at once. -->

### 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

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

<!-- Guidance: Use this mapping to check the charter is complete and to show maturity progress in a SAMM assessment. Principle names are cited from the OWASP Security Champions Guide; the "how this charter applies it" column is original. -->

### 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

<!-- Guidance: Treat the programme as a product: a budget, a backlog, regular reviews and a way to stop doing things that do not work. -->

### 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

<!-- Guidance: Keep the glossary short; link to the documents champions use every day. -->

### 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.