In the Security Champion Program Success Guide blog, I invite industry professionals to offer their opinions, thoughts, experiences, and viewpoints about Security Champion programs in order to expand our collective knowledge and encourage healthy conversation. In this post, Lead Security Architect at Swisscom Collin Geisser explains how to make a solid business case for leadership investment in a security champion program. Enjoy! — Dustin Lehr
Organizational structure
For reference throughout the article, we at Swisscom organize our work using the Scaled Agile Framework (SAFe). Teams with aligned objectives form an Agile Release Train (ART). Multiple ARTs with a shared mission form a Solution Train. Several Solution Trains together make up a department.
For security, each team has a Security Champion. Within each ART, a System Security Architect provides governance and leadership. All System Security Architects report to the Solution Security Architect, and all Solution Security Architects are led by the Lead Security Architect.
Introduction – The First Success
Like many companies, Swisscom had a Security Champion Program that was formally defined but far from successful. Each Solution Train handled the Champion Program differently.
I started as a Security Champion within my team, and my passion for this role led me to become a System Security Architect in my Agile Release Train. With this new responsibility, my influence grew across other Trains. My goal was clear: the program should not just exist but deliver a real impact.
To achieve this, I changed the approach. Champions should volunteer rather than be nominated. This works only if the role is attractive, recognized, and visible. I increased the presence of security in the organization and highlighted the Champions’ contributions. During our 10-week planning sessions, where we plan all development activities in a certain area, I presented our goals for the upcoming weeks, making the Champions’ work visible and acknowledged.
During our retrospective meetings, I showcased our successes: the number of risks created and closed, reduced mean time to repair, the closure of vulnerabilities, and team-specific vulnerability counts. We celebrated achieving goals set in planning meetings, which elevated the visibility and recognition of the Security Champions’ work. After one year of doing this practice, security became an automatic topic in meetings, encouraging the organization to think about security tasks regularly.
Soon, every team in my organization had a motivated volunteer, resources became available, and the program gained traction. This success paved the way for me to become the Solution Security Architect, overseeing multiple Agile Release Trains. I was convinced I could replicate this formula, but how naïve I was…
New Challenges – Pushback from the Business
Every organization was different, with shared problems and unique challenges, but a recurring issue emerged: business-side pushback. An anonymous survey revealed the underlying problem: while our Champions were motivated, they often lacked the time to fulfill their roles. Product Owners and Line Managers were either unaware or prioritized feature delivery over security tasks. Champions frequently mentioned, “I understand its importance, but with current delivery pressure, I cannot leave my team behind when deadlines slip.”
Additionally, many felt inadequately trained, not having the time to hone their skills. Although the role was defined clearly, Champions were to dedicate 20 percent of their time to coordination, risk management, vulnerability management, coaching, and training. This commitment was repeatedly questioned or sacrificed.
Speaking the Business Language – Facts Instead of Assumptions
Management, responsible for staffing, training and line management, supported the program wholeheartedly, but convincing the business side required a different approach. Since Business is financing our solution trains and deciding, which features will be implemented.
Classic arguments like “fewer incidents” or “reduced risk” were too abstract and difficult to measure. What I needed was transparency and solid data.
The Analogy
I began with a simple question: “If someone plays football for one hour a week, would you call them a professional? Maybe two hours? Or four?” Then I drew the connection: our Champions are expected to spend eight hours a week on their role. Security cannot just be a hobby, it is our profession, and we must treat it professionally. The analogy worked, shifting the discussion from whether two or four hours were sufficient to recognize full commitment as necessary.
The Ranking
Next, I presented data: the percentage of workforce dedicated to Security Champions versus other employees in each organization. This allowed me to show how much each organization was investing in security. The company-wide average was 2.3 percent. Showing results in ascending order created a ranking.
Example of Workforce Distribution:
Healthy competition ensued, as no leader wanted their organization at the bottom of the list, especially if their department was responsible for developing security products. By the next quarterly update, teams across the board ensured they had Champions in place.
The Next Step – Maturity Instead of Only Resources
Having Champions in every team was progress, but their time was sometimes redirected to delivery work. I needed a stronger argument, leading to the introduction of a Security Maturity Check.
We defined various discipline categories, each rated from Level 0 to Level 4. For example, in “Staffing”, if an organization had no Security Champions, they were Level 0 with zero points. Although we didn’t define a minimum target, Level 4 was always the “Rolls Royce.” Every organization responded to the same criteria to evaluate their maturity level, with results shared across the company as benchmarks.
No one wanted to be below average. Once again, transparency and competition drove change. We secured both the number of hours and Champions per team. Additionally, we explained to each Champion why it was crucial to retain their 20 percent commitment instead of sacrificing it for feature development.
Example of a Maturity Report:
Lesson Learned – Facts Convince the Business
Today, 4 years since I became a Security Architect and grew into Solution Security Architect, our Security Champion Program is well-established. All Champions understand why properly utilizing their 20 percent is crucial, and leadership supports them in maximizing their capacity. The key to success was not just management support but consistently making the program’s value visible through data, transparency, and regular communication of achievements like Bug Bounties and Penetration Test results.
All results were regularly presented in leadership meetings, making security transparent without imposing goals. Pressure to improve arose naturally through transparency and competition. My key lesson learned: even with leadership support, the business side remains the decisive stakeholder. To win them over, communicate using facts, transparency, and measurable results.
Of course, other pillars of success, such as passion, vision, community, and investment remain essential. But without business buy-in, even the best Security Champion Program will never succeed in the long run.
Want to share your own viewpoint or case study about security champions to post on this site? Contact me on LinkedIn and let’s chat! — Dustin Lehr
