A security champion should help their team notice, explain, and route application risk inside ordinary development work. Give them protected time to identify relevant changes, bring local architecture facts into reviews, share practical guidance, and make sure a concern reaches the right owner. Assign technical review, risk acceptance, incident command and staffing authority explicitly. A champion may exercise a delegated decision within their competence and mandate; the title alone grants none of those powers. The champion is a bridge between the engineering team and AppSec, not a second security department hidden in a developer's calendar.
The exact role changes with the team's size and experience. A senior engineer may lead a focused design discussion; a newer champion may start by collecting context and asking questions. In both cases, publish the mandate and time allocation. OWASP's Security Champions Guide emphasizes management support, a named program captain, trust, knowledge sharing, and investment. A volunteer title without capacity or escalation rights does not deliver those conditions.
Assign a useful local mandate
Choose a champion who understands the service and is willing to learn, then ask their manager to reserve time. An illustrative starting allowance is one hour a week plus planned participation in a material design or incident review; it is a staffing choice, not a universal benchmark. The AppSec lead supplies coaching and the technical decision process. The engineering manager protects time and fixes conflicts with delivery work.
Give the champion four recurring tasks:
- Spot relevant changes. Flag new customer-data flows, authorization boundaries, credentials, external integrations, and major dependency or deployment changes early enough for a focused review.
- Bring context. Map entry points, shared middleware, production configuration, and owner contacts so a reviewer can test the right claim. State unknowns rather than assuming a function is deployed.
- Teach and feed back. Share a short lesson from a real reviewed issue and tell AppSec where a checklist or tool output is confusing or noisy.
- Route concerns. Preserve the initial evidence, raise a plausible harmful action, and connect the report to a qualified reviewer or incident owner. Follow up that the concern received a decision.
OWASP SAMM's Education and Guidance practice treats collaboration and role-specific guidance as part of a security program. The champions guide's trust principle describes champions as people with local team knowledge who can influence the program. OWASP's trust principle also recommends giving champions a mandate to make security decisions within the organization's risk appetite. Decide which decisions that includes locally; do not reduce an experienced champion to a messenger, or assume every volunteer can accept material risk.
Keep decision rights explicit
This division prevents a helpful local role from becoming an unreviewed approval path:
| Decision or task | Champion | AppSec / security lead | Service owner or engineering manager | Risk or incident authority |
|---|---|---|---|---|
| Identify a new trust boundary or suspicious path | Flag and describe local context | Choose review method | Provide deployment and ownership facts | Receive urgent escalation if needed |
| Establish a finding's technical status | Review within explicitly delegated competence; otherwise supply evidence | Review consequential or disputed conclusions under policy | Challenge facts and assign eligible fix owner | — |
| Implement a fix | Help when they own the affected code | Define acceptance evidence and review result | Own delivery and code review | — |
| Decide a deadline or accept a temporary exception | Explain technical and delivery constraints | Record technical risk and interim-control evidence | Plan engineering work | Approve according to policy |
| Coordinate an active incident | Report and assist with service facts | Support investigation | Provide service responders | Lead response under incident plan |
A champion who also happens to be an authorized technical reviewer or service owner can wear both roles, but the record should identify which authority they exercised. Do not assume the title grants access to every repository, customer report, scanner result, or security secret. Share technical details only to the extent needed for the assigned service and task.
Give Maya a difficult Tuesday
Constructed role exercise: CedarCRM is adding a partner route for account documents. Maya, the Documents champion, has one protected hour this week. The additional material-change review slot in her charter has not yet been booked. Three requests arrive before lunch.
| Request | Useful response from Maya | Decision that remains elsewhere |
|---|---|---|
| “Where is account ownership checked for this route?” | Spend 20 minutes linking the handler, shared read and intended partner rule; state that the production route map is pending | AppSec decides whether the complete path supports a finding |
| “Can you accept the risk so we can launch?” | “I can explain the missing control evidence. I cannot accept customer-data risk; here is the policy's service owner and business approver.” | Release/exception authority follows the policy |
| “A customer may have received another account's document. Can you investigate after stand-up?” | Escalate immediately to the on-call incident owner with the report and affected service; supply local context under that response | Incident command and containment authority remain with the incident owner |
The third request is not an ordinary item to squeeze into the remaining 40 minutes. Maya spends 15 minutes handing off the concern and notifying her manager. The incident owner requests two more hours of service assistance. Her manager explicitly moves two hours of feature work and records Maya's incident-support role. Without that adjustment, the response would have converted a volunteer hour into hidden on-call duty.
Maya uses the remaining 25 ordinary champion minutes to leave a useful context note for the planned partner review:
Expected rule: partner user may retrieve only documents of its authorized account.
Changed path: partner handler -> document service -> object delivery.
Local evidence: handler checks login; service implementation and revision linked.
Do not infer: the existing single-document route's guard protects this new caller.
Missing: effective route binding; location of per-document account enforcement.
Next owners: service engineer supplies read contract; Platform supplies route map.
Champion output: context assembled and routed; no vulnerability verdict or launch approval.
Assume the service engineer subsequently shows a mandatory account-bound read and the qualified review defeats the suspected gap on this path. Maya's contribution still succeeded. “Zero vulnerabilities found” would be a poor measure of a role that helped settle an important question before launch.
The team records a separate outcome for the customer report when the incident owner has evidence. It must not use the partner-review rejection to dismiss an incident about a different route or release. A champion's local knowledge helps avoid that mistaken transfer of conclusions.
Copy a small champion charter
Here is a filled charter for CedarCRM. Replace the time and contacts with actual organizational commitments.
- Team and term: Documents team; eight-week pilot.
- Champion: Senior engineer Maya; manager reserves one hour each week and a planned review slot for material access changes.
- Purpose: Surface document-access risks early and carry accurate local context into AppSec reviews.
- Owns: Change prompts in team planning, first-pass service map, secure-development discussion in one team meeting per month, and routing of suspected issues.
- Does not own: Final finding verdict, company risk acceptance, release veto, incident command, all security fixes, or access to unrelated applications.
- Escalation: AppSec lead for ordinary review; on-call incident owner for suspected active customer-data exposure; engineering manager for missing time or owner.
- Support: AppSec lead offers a monthly case review and updates the checklist when the pilot uncovers unclear guidance.
- Pilot check: Did material document-access changes reach review before release? Were context requests answered? Did the champion's allocated time remain available? Record missed changes and why.
The manager should review the charter with the candidate rather than simply appointing the most security-interested engineer. The OWASP management-support principle explains why formal priority and budget matter when champion work competes with normal delivery. Its investment principle supports allocating time for that work.
Protect the role from becoming the default owner of every fix
A champion's familiarity with the security process can make them the easiest person to assign work to. That is useful when they own the affected code and have capacity. It becomes harmful when other teams treat routing expertise as responsibility for every remediation task. Maya's charter should let her identify the right service owner without acquiring the entire fix backlog.
When a task reaches her, separate three questions: can she explain the local path, is she qualified and delegated to make the technical decision, and can she implement the change within her planned work? The answers may differ. A senior champion can review a narrow account-binding change while the service team still owns delivery. A newer champion can assemble excellent context without making the final finding judgment.
The manager should check these boundaries in sprint planning. If a security repair is assigned to Maya as a developer, account for it as repair work, not inside the one-hour champion allowance. If incident support takes additional time, record the incident role and displaced feature work. The same person can contribute in several ways without making those costs invisible.
Make local learning safe and reusable
A useful champion lesson describes the failed rule and the corrected pattern without distributing sensitive report details. For CedarCRM, the lesson could explain why a new partner caller needed its own account-bound read, even though a single-document route already had a guard. It need not include customer identifiers, private source or a reproduction path for a live issue.
Ask the receiving developers to identify where that rule applies in an upcoming change. This creates a concrete discussion rather than a generic security presentation. If the example does not match their architecture, collect that feedback for AppSec instead of imposing the pattern blindly.
At the pilot review, use those observations alongside capacity and routing measures. Did a material change receive a clearer question? Did a service owner supply the needed artifact sooner? Did a misleading approval request reach the actual authority? These are more defensible indicators of the champion's contribution than counting vulnerabilities or expecting one volunteer to prevent every release problem.
Decide what to change after eight weeks
At CedarCRM's pilot review, suppose the log shows four material changes surfaced before release, three useful context packets, one late change missed during a feature deadline, and three requests for risk acceptance that Maya correctly escalated. These are exercise facts, not evidence of a measured program benefit.
The manager has two actionable problems. The missed change means the team planning checklist needs an explicit document-access prompt. Repeated approval requests mean the charter is not enough: put the actual approver next to the release form's exception field. Giving Maya a stronger title would solve neither problem.
Maya also reports that the one-hour allocation was overridden in three weeks. The manager chooses to retain the pilot, reserve the hour visibly in sprint planning, and book the promised material-review slot in advance. If that capacity cannot be protected, narrow the mandate to context and routing; do not retain monthly teaching, design participation and incident support as unpaid expectations. An incident assignment or extra fix work requires an explicit role and time decision each time.
Use the application security policy to locate authority and the cadence guide to book access to reviewers. A manager can use the charter immediately: choose the local problem the champion will help resolve, reserve time for it, and publish who answers when the champion reaches their limit.