Most Security Champions programmes are designed as rosters: how many champions, which teams, what they will be asked to do. How the champions are connected, to each other and to the colleagues sitting beside them, gets treated as admin. It is the main design variable. What a champions network can carry depends on its shape, and the shape that spreads information is not the shape that spreads behaviour.
Dotted terms show a short explanation when you point at them, or tap them on a phone.
Network science has spent twenty years separating two ways things move through a social network. Simple contagion travels on a single exposure: you hear that a new phishing lure is doing the rounds, and the hearing is the whole transmission. Complex contagion needs reinforcement: a person adopts a behaviour only after several of the people around them have, and the several has to be visible at the same time.
Awareness, alerts and know-how behave like the first. Reporting a suspicious message, pausing on a request that arrives with authority attached, or changing a working habit behave like the second. A programme is asked to do both, and the two jobs pull the network design in opposite directions.
One exposure can be enough. The ideal network has many long ties, short paths and low redundancy, and the ideal seeds are the people who sit on the bridges between groups.
A single long tie into a new team cannot carry it, because the person at the far end sees only one adopter. It needs clustered neighbourhoods, where a person's contacts also know each other, and wide bridges between them.
Four things make a behaviour complex, and all four are common in security: it costs something; its value depends on others doing it too; it risks looking foolish; and it conflicts with a habit. A network designed for the top of this list fails quietly at the bottom, and the failure does not show in the usual metrics, because champions recruited, attendance and content delivered are all measures of simple contagion.
Having run one network and advised on many, we can recognise five recurring shapes. Real programmes are usually a mixture, but each has a distinct profile against the properties that matter for contagion: path length, clustering around colleagues, ties among champions, the width of the bridges between teams, and what happens when someone leaves. Find the one you have built.
The default when a programme is launched from a mailing list. Each champion is tied to the centre, receives material and is expected to pass it on. Champions rarely know one another. Cheap to run, easy to measure, and a good carrier of alerts: every team is two hops from the security function.
It carries almost nothing back, and no behaviour at all, because each champion is a single adopter in a team of non-adopters and can supply only one signal. A champion who leaves takes their spoke with them; a centre that loses attention loses the network.
The model programmes grow into. The champions get a channel, a regular call and events of their own, and over a year or two they become a community of practice. Measured on its own terms it is a success: the champions know more, stay longer and speak up more.
The difficulty is where the ties are. Most of a champion's security-related ties now run to other champions. The dense, reinforcing structure that behaviour needs has been built among the people who have already adopted. From a colleague's desk the champion is still one adopter among non-adopters, and the cluster is somewhere else.
Champions sit inside the teams whose behaviour is to change, chosen for their position in the team rather than their interest in security, and placed in twos or threes so a colleague can see more than one adopter at once. Few ties between champions in different teams. This is the structure the experimental work identifies as the best carrier of complex contagion.
Its weakness is the mirror of the cluster's strength. The champions have no community, learn slowly, drift from the security function's intent, and are hard to reach quickly with an alert. Isolation also costs retention, which the champions literature repeatedly names as the main risk to the role.
Model 3 plus a sparse set of ties among champions and back to the security function. The backbone is thin on purpose: its job is to carry alerts, which need few ties, and identity, which needs even fewer. A handful of long ties between champions in different business units is enough to make the backbone a short-path network for information.
The design has to resist the pull towards Model 2, because the champions' community is pleasant and the team's resistance is not. In practice: fewer all-champion calls and more local work, a channel for broadcast rather than discussion, and recognition tied to what changed in the champion's team rather than to attendance.
Large organisations add tiers: lead champions in each division sit above local champions, and the security function talks to the leads. Tiers manage span of control rather than contagion, and can be laid over any of the first four models.
If the tiers are reporting lines, they add path length and a point of failure at each lead without adding reinforcement. If the leads are themselves embedded in their divisions and the tiers are used to build wide bridges between neighbouring teams, they can help behaviour cross department boundaries, which is where it most often stalls.
| Model | Paths from centre | Clustering around colleagues | Ties among champions | Carries information | Carries behaviour | Main risk |
|---|---|---|---|---|---|---|
| Hub and spoke | Short | Low | None | Outward only | No | Single points of failure; nothing flows back |
| Single champion cluster | Short | Low | Dense | Yes, among champions | Among champions only | Network runs parallel to the business |
| Distributed, embedded | Long | High | Sparse or none | Slowly | Yes, within teams | Isolation, drift, slow alerts, attrition |
| Distributed with backbone | Short via backbone | High | Thin | Yes | Yes; across teams if bridges are wide | Backbone grows into a cluster |
| Tiered hierarchy | Depends on tiers | Depends on base model | Structured | Yes | Only if leads create wide bridges | Added path length and failure points |
The words are close and the structures are opposites. In a single cluster the champions are clustered with each other. In a clustered network each champion is clustered with their own colleagues, and the champions as a group are only lightly connected.
The single cluster is the attractive mistake, and its attractions are all real. It builds capability, because champions learn from each other faster than from the security function. It builds retention, because belonging keeps people in a voluntary role. It is visible, so it is easy to report on and easy to fund. And it is where information moves best: a message dropped into the cluster reaches every champion within a day.
What it does not do is move behaviour in the teams. Closure, the pattern in which a person's contacts also know each other, is the structural basis for norms, because it lets a group observe, sanction and reward its members. A single cluster has high closure among the champions and none between a champion and their team. The norms that form in it are the champions' norms.
A clustered network puts the closure where the behaviour needs to change. Two or three champions in a team of twenty, who know each other and who each know most of the team, give every colleague several adopting contacts at once. Once a team has tipped, the team itself becomes the reinforcement for anyone who joins it later.
A network that has to carry both kinds of contagion should be built as two layers, each shaped for what it carries. The lower layer places champions in pairs or triads inside the teams whose behaviour is the target, chosen by nomination for their position in the team, with wide bridges between neighbouring teams and some ties that span departments. This is where behaviour moves, in months, driven locally.
The upper layer is a thin, organisation-wide backbone among champions, with the security function attached to it rather than at the centre of it. This is where information moves, in days, driven from the centre. The backbone is held sparse so that it never becomes the champions' home. Seven parameters set the shape, and the contagion argument gives each one a direction the roster view does not.
The two layers, with each champion appearing on both. Six teams in two departments; two champions in each team, tied to each other and to most of the team; several ties between neighbouring teams and a couple that span departments; and above it all a sparse backbone that carries alerts and identity, with the security function attached at the edge rather than sitting at the centre.
| Parameter | The roster view | The contagion view |
|---|---|---|
| Champion ratio | One per 20 to 50 employees | Secondary; what matters is seeds per team |
| Local seed density | Not considered | Two or three champions per target team, tied to each other |
| Selection | Interest in security; volunteers | Position in the team; nomination by colleagues |
| Coverage | Every unit has a champion | Every target behaviour has a tipped team nearby |
| Ties among champions | As many as possible | Thin; a small-world backbone for alerts and identity |
| Bridge width | Not considered | Several ties between neighbouring teams; some spanning departments |
| Measure of success | Champions recruited, sessions held | Behaviour adopted by colleagues; exposure counts; teams tipped |
None of this needs more than a short survey, a spreadsheet and a network library. Ask each person who they go to for security advice, who they would tell about a suspicious message, and who they talk to about work, and six things can be read from the answers: exposure count (how many adopting contacts each non-adopter has, which is the direct measure of whether behaviour can start); champion embedding (the share of a champion's security ties that lie inside their own team, which a single cluster shows up as low); modularity against team membership; bridge width between neighbouring teams and between departments; champion betweenness, which finds the people who should carry the backbone and are often not the embedded ones; and the simple count of tipped teams and the teams next to them. What most programmes lack is not the tooling. It is the decision to measure reach rather than coverage.
The homepage routes you by where you are: Getting Started, Running Your Network, or Beyond Awareness. The network models matter at each point, in different ways, and they line up with the stages of the Security Champions Maturity Model.
Models 1 and 2 are the networks a programme builds at Stages 1 and 2, and they carry awareness. Models 3 and 4 are what Stages 3 and 4 require, and they carry behaviour. The wall between them is a change of shape. Read the maturity model →
You will build a hub and spoke first, and that is fine: it is the easiest transition in the model and it gets alerts to every team. The mistake is to let the roster decide where champions go.
If your champions know each other better than they know their teams, you have Model 2. It will keep reporting success on coverage, attendance and content while the behaviour line stays flat.
Behaviour change at scale is the two-layer reference model made real: pairs and triads in target teams, bridges between neighbouring teams and across departments, and a backbone held thin.
HEROES by CyBehave is built around the idea that the programme's view of itself is one vantage point and not enough. Base measures what reaches colleagues: the Behaviour Index comes from the quarterly Team Pulse, in which colleagues rate the security behaviours they observe in their own team, independent of the champions and of the training platform. The coverage map and the Champion influence map show which teams have a champion and how security actually spreads. The Network Optimisation module, in development, is where the measures on this page live: who bridges teams, who is isolated, whose position carries a message furthest, recruitment targeting drawn from the gaps, and succession risk where coverage rests on one person.
The position on this page is set out in full, with the simulation, its limits and the references, in a working paper from the CyBehave Lab. The paper also describes the field study that would test the argument: an organisation with a champions programme, a network survey at two points a year apart, a behaviour measured directly, and champion placement varied between business units.
Wood, A. (2026). Network models for Security Champions: Design variations, contagion dynamics and the choice between a clustered network and a single cluster. Working paper, version 1, 24 October 2026. CC BY 4.0.
The free Champions Programme Health Check gives you a first read on your programme in about ten minutes. The maturity model tells you what to do about it.