With a security champion in every squad, what should the central security team still own itself?
answer
- Delegation, not abdication
- Keep the method, give up the sessions
- Blank page is the champion's real enemy
- Escalation should not depend on temperament
- Sample for method quality, not to redo it
basics
~20 sThe centre keeps the method, not every session: curriculum and coaching, a small library of reference models, a published risk line above which it reviews the design itself, and a sample review that stops model quality drifting.
solid answer
~50 sDelegating threat modeling to champions delegates the routine sessions, not the standard. The centre keeps four things. First, the curriculum and ongoing coaching — champions are made by repeated cohorts and office hours, not one course. Second, a small library of reference models for shapes that recur, such as the standard event-consumer service or the standard vendor webhook receiver, so a squad starts from a known threat set rather than a blank page. Third, a published risk line — new external trust boundary, new regulated data class, money movement, changes to authentication — above which the centre facilitates or reviews the design itself, so escalation does not depend on a champion's nerve. Fourth, a light sample review of squad-produced models for method quality. What it gives up is being in the room for everything else.
go deeper
Understand that champions do not replace the central security team. The centre still trains people, still looks at the riskiest designs, and is who you ask when a threat modeling session raises something the squad cannot resolve.
Be able to say why a reference model helps: it gets a squad past the blank page with a known starting threat set for a familiar shape, and it must be short enough that people actually read and then diverge from it.
Demonstrate the escalation mechanics. Name concrete triggers that pull a design back to the centre and explain why written triggers beat leaving it to each champion's judgment, then say how you would tune the line with evidence.
Own the delegation strategy end to end, including what you deliberately stop seeing. Be ready to defend retained central headcount against an expectation of savings, and to argue the consistency-versus-local-fit tradeoff for an organisation of a specific size.
## The question behind the question An interviewer asking this wants to know whether you understand that a champion programme is a *delegation*, and that delegation without retained scope is abdication. The failure at both ends is easy to describe: a centre that keeps reviewing everything has just added a layer of intermediaries and no capacity, while a centre that keeps nothing watches thirty squads slowly invent thirty different methods and discovers two years later that none of the models are comparable or trustworthy. ## What the centre keeps ### 1. The curriculum and continuous coaching Champions are not created by a single training course. The centre owns a repeating training cohort so that new and replacement champions are weeks from ready rather than months, plus a standing channel and regular office hours where a champion can bring a session they are unsure about. Coaching load is permanent, not a launch cost — that is the staffing consequence most programmes underestimate. The centre also owns *what good looks like*: a worked example, the vocabulary, and the expectation that a threat is written specifically enough for an engineer to act on rather than as a category label. ### 2. A small library of reference models This is the highest-leverage thing a small central team can produce. Most squads are not building something unprecedented; they are building another instance of a shape the organisation already has. A short reference model for the standard event-consumer service, or for the standard vendor webhook receiver, gives a champion a starting diagram and a starting threat set: for the webhook receiver, for example, the recurring questions about whether the sender is authenticated, whether a replayed delivery is accepted twice, and what a compromised vendor can push into the system. Keep the library **small**. A reference model that tries to cover every variation becomes a document nobody reads, and the point is to get a squad past the blank page in ten minutes, not to pre-empt their thinking. Reference models are a starting point that the squad must then diverge from — a champion who submits the reference model unchanged has not modelled anything. ### 3. A published risk line, and the designs above it The centre should name, in writing, the categories of change it wants to be in the room for. Typical lines: a new trust boundary exposed to the internet or to a third party; a new class of regulated or especially sensitive data entering the system; anything that moves money or credit; changes to authentication, session handling or authorisation; and a design whose failure has a safety or legal consequence. Below the line, the champion runs the session and the centre does not attend. Writing the line down does two things. It gives the champion cover to escalate without looking timid, and it stops escalation from being a function of individual temperament — otherwise a bold champion under-escalates and a cautious one floods the centre, and neither pattern is about the actual risk. ### 4. Sample review for method quality The centre should read a modest sample of squad-produced models, and it should be explicit that this is a review of the *method*, not a re-run of the analysis. Useful questions: is the boundary drawn where the trust actually changes, or at the network edge out of habit; are the external dependencies on the diagram at all; are the threats specific enough to be acted on; does every accepted risk have a named person who accepted it. Findings from this feed back into the curriculum, which is what makes it worth doing. The centre also stays the escalation path when a champion and their squad disagree — the champion should never be left to win an architectural argument alone against their own tech lead. ## What the centre gives up Everything else, deliberately: attendance at routine sessions, the pen, the decision on which mitigations a squad chooses for a below-the-line design, and the comfort of having seen every model. If the centre cannot let go of these, the programme's economics never arrive, because the whole point was to stop scarce specialists being the rate limit on design. A related discipline: the centre should not become the squad's general security help desk. Champions raise design questions; dependency alerts, access requests and production incidents belong to whatever process already owns them. A central team that absorbs all of it will quietly stop doing the curriculum and the reference models, which are the only things nobody else can do. ## Tradeoffs worth naming out loud - **Consistency versus local fit.** A rigid method travels badly to a squad with an unusual architecture; a purely local method produces models that cannot be compared. Hold the *questions* constant and let the format flex. - **The risk line will be wrong at first.** Set it deliberately, then adjust: if the centre is drowning it is too low, and if a design you would have wanted to see went past unescalated it is too high. Publish the change either way. - **The centre shrinking is not the goal.** The work changes rather than disappears: less facilitation, more curriculum, coaching, reference models and hard cases. A leadership expectation that champions let you cut the central team is worth challenging directly. ## Interview shape Answer with the four retained items, then say explicitly what you gave up and why. The strongest signal is naming the risk line as a *written, revisable* artifact rather than a judgment call, because that is the piece that makes delegation safe and it is the piece most candidates omit.
- How do you set the risk line above which the central team gets involved?Start from the changes whose failure you could not absorb — a new internet-facing or third-party trust boundary, a new regulated data class, anything moving money, changes to authentication or authorisation — and write them down as named triggers rather than as a severity judgment. Then tune it with evidence: if the centre is saturated the line is too low; if a design you would have wanted to see went past unescalated, it is too high. Publish every change.
- Leadership says champions mean the central security team can shrink. How do you respond?The work changes rather than disappears. Facilitation hours drop, but curriculum, coaching cohorts, reference models, escalated designs and sample review are all permanent and none of them can be delegated to the squads themselves. Turnover alone guarantees a continuous training load. I would offer to re-shape the team toward enablement, and be explicit that cutting it turns champions into an unsupported group whose method drifts within a year.
- What does a bad reference model look like?One that tries to be complete. A forty-page model of a service shape becomes a document nobody opens, and worse, it invites champions to submit it unchanged as their own model. A good one is a page or two: a small diagram, the boundaries, and the handful of threats that recur for that shape, framed as a starting point the squad is expected to diverge from as their design differs.
The centre becomes a driving examiner and highway code, not a chauffeur: it sets the standard, trains, and takes the wheel only on genuinely dangerous roads.
saying these in an interview costs you the question
- Keeps reviewing every model and calls it delegation
- Delegates with no written escalation criteria
- Says champions let the central team be cut
- Publishes exhaustive reference models nobody reads
- Treats sample review as redoing the squad's analysis
- Lets the centre become the squad's general security help desk