Start by naming champions in teams that build, deploy, or support systems, then give them a clear remit and regular time to act on it. Define escalation paths, training expectations, and measures such as review findings, awareness gaps closed, and issues raised into engineering or risk processes.
Start with the teams and workflows that need the most leverage
A security champion programme works best when champions sit close to the work that creates risk: product teams, engineering squads, platform owners, and operations groups that change systems frequently. Start with a small, visible set of teams where the programme can influence design reviews, release decisions, and day-to-day habits, rather than trying to cover the whole organisation at once.
The role should be explicit enough that people know what “champion” means in practice. The programme should define whether the champion is expected to spot issues early, route concerns into engineering, coordinate with security, or help teams adopt safer defaults. A vague advocacy role tends to become optional awareness theatre; a concrete remit makes the programme operational.
That is why the first phase should focus on problems the teams already encounter, such as insecure design choices, missed reviews, or repeated exceptions. When the champion is embedded in a live delivery workflow, the programme can influence decisions before they become incidents, not after the fact.
Make the programme usable, not ceremonial
Champions need time, training, and a clear path for escalation. If the role is added on top of a full delivery load with no protected capacity, it will fail quietly. A workable programme gives champions regular time to review changes, raise issues, and participate in conversations that would otherwise happen only inside security.
Training should be practical and role-based. Champions do not need to become security specialists, but they do need enough context to recognise common failure patterns, know when to ask for help, and understand the threshold for escalation. That usually means teaching them how to spot risk in design discussions, how to route decisions into the right engineering or risk forum, and what evidence to collect when they escalate.
For teams building software, a good starting point is often to align champions with Application Security Guide style practices: reviews, threat modelling, secure coding feedback, and practical triage. For organisations that are more focused on awareness and behaviour change, the broader Security Awareness and Human Risk Management Guide is a better anchor because it ties champions to culture, communication, and measurable behaviour change.
Measure whether champions are changing decisions, not just attending meetings
The value of the programme should be measured by action, not attendance. Useful indicators include review findings that were raised earlier in the lifecycle, recurring awareness gaps that were actually closed, and the number of issues that moved from discussion into engineering backlog, risk acceptance, or remediation. Those measures show whether the programme is influencing control decisions, not merely creating a network of contacts.
It also helps to watch for coverage gaps. If the same types of issues keep reappearing, the programme may be too shallow, too informal, or too disconnected from engineering reality. If champions are raising issues but nothing changes, the escalation path is weak. If teams do not know who the champion is, the role has not been operationalised.
For teams that need an application-security lens, the champion programme should connect to review quality, design decisions, and remediation throughput. For awareness-led programmes, the important question is whether the programme changes what people notice and report early enough to matter. In both cases, the programme succeeds when it shortens the distance between seeing a problem and getting it acted on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-14 — Security Awareness and Skills Training | Champions extend security awareness and role-based enablement into delivery teams. |
| Recommendation — Build a role-based champion training path and measure whether it closes recurring awareness gaps. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Champions help shift security feedback into design and coding decisions. |
| Recommendation — Use champions to surface design and coding issues before they become release defects. | ||
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | A champion programme depends on explicit responsibilities and escalation authority. |
| ID.RA-05 — Threats, Vulnerabilities, and Risks Are Used to Inform Risk Response | Champions should route findings into risk decisions and remediation workflows. | |
| Recommendation — Define champion responsibilities and escalation paths so the role is operational rather than informal. Feed champion findings into risk response and remediation processes. | ||
Practitioner Guidance
What to prioritise: Start with a limited number of high-change teams and give each champion a specific remit tied to the work already flowing through that team. Avoid selecting champions only because they are enthusiastic; choose people who are close enough to delivery to influence decisions.
What to verify: Confirm that each champion has protected time, a named escalation route, and a manager who understands the role. If those three elements are missing, the programme will become informal support work rather than a control that changes outcomes.
What good looks like: Champions raise issues early, teams know where to send them, and recurring findings start to decline because the programme is feeding back into engineering and risk processes instead of operating as a separate community.
Practitioner takeaway: The best security champion programmes do not try to “spread security” in the abstract, they create a repeatable path from team-level observation to concrete action, with enough authority and time for the role to matter.