How to market a resilience program internally

Marketing a resilience program internally means getting people who did not ask for it to change how they work: to run the exercise, own the dependency, keep the plan current when nothing is on fire. That is an adoption problem, and adoption responds to the same craft that wins customers, applied to an audience that cannot churn but can absolutely ignore you.

Most programs are designed well and adopted badly. The plan is sound, the framework maps cleanly, and the business routes around all of it, because nobody made the case in terms the business recognizes.

Why resilience is a hard internal sell

• It is invisible when it works. A program that prevents disruption produces no evidence of the disruption it prevented.
• It competes with revenue work for the same hours, and it loses that comparison whenever it is framed as compliance.
• The people who must act are usually not the people accountable. The resilience owner has the mandate; the engineering, operations and supplier teams have the work.
• The payoff is deferred and probabilistic, which is the hardest thing to sell in any market.

None of that makes it unsellable. It makes it a positioning problem: the program has to be about something the audience already wants.

Start from their problem, not your framework

Segment the internal audience the way you would segment a market, because they are not one audience. Operations leaders care about downtime and the 2am call. Engineering cares about release velocity and not being blocked. Finance cares about the cost of disruption and the cost of insurance. Legal and compliance care about what is defensible to a regulator.

One deck about the resilience programme speaks to none of them. Four versions of the same claim, each landing in the language of one group, is the same discipline you would apply to a buying committee outside the building.

Make the first ask small

The instinct is to launch the whole program: full business impact analysis, dependency mapping across the estate, plans for everything. That asks a team with no prior interest to commit weeks on a promise.

Product marketing solved this a long time ago with the free trial. Ask for twenty minutes: one scenario, one team, one dependency. A short exercise that produces an uncomfortable finding does more for adoption than a mandate, because the team reaches the conclusion themselves. We have written about that format in microsimulations.

Proof that travels

• The exercise result, especially the one that went badly. Nothing else creates urgency as cheaply.
• A near miss from your own organization, described honestly and without blame.
• Peer practice. What comparable organizations do carries more weight than what the framework says.
• The regulator's own language, where one applies: DORA, the Bank of England and FCA rules, or ISO 22301 as a reference point rather than a cudgel.
• A named internal champion who went first and will say it was worth it.

Documentation nobody has tested is the weakest asset in the set, and everyone in the room knows it. More on that in resilience documentation.

Recruit champions rather than compelling attendance

Every adoption curve starts with a small group who went first. Find the team that already had the bad quarter, run with them, and let their story do the persuading. Name them internally. People will do for peer recognition what they will not do for a policy.

The corollary is to stop trying to reach everyone at once. A program with three teams doing it properly is in better shape than one with thirty teams filing templates nobody reads.

Give people something to take upward

Participation has to pay the participant back. The team that runs the exercise should walk away with something they can show their own leadership: a finding, a metric that improved, a risk closed. That converts your program from a tax into a resource, and it is the single fastest way to get invited back.

The sequence that works

• Name the problem in the terms the affected team already feels, not in the terms your framework uses.
• Make the first ask small enough to say yes to without a meeting: one exercise, one dependency mapped, one supplier reviewed.
• Run it with a friendly team first and record what happened, so the second ask arrives with evidence attached.
• Give the people who did it something to show upward, so participation pays them back internally.
• Repeat on a published cadence, so the program becomes a rhythm rather than an annual interruption.

Cadence matters more than scale here. A predictable rhythm removes the negotiation from every individual ask, which is the same reason launch works better as a habit than as an event. We made that argument in always be launching.

Measure adoption, not attendance

Attendance is a vanity metric. Adoption shows up as teams initiating exercises without being asked, dependencies being updated because something changed rather than because a date arrived, and the program's language appearing in decisions you were not part of.

If none of that is happening, the program is being complied with rather than adopted, and the fix is upstream in the message rather than downstream in the enforcement.

Questions people ask

Why treat an internal program like a marketing problem?
Because the constraint is attention and behaviour change, not design. Audience, message, proof, a small first ask, and repetition are what move people, whether they are customers or colleagues.

How do we get engineering teams to take part?
Frame it in their terms: fewer 2am pages, fewer blocked releases, clearer ownership when something breaks. Ask for a short exercise rather than a documentation exercise, and give them the finding to use.

Does executive mandate work?
It gets you compliance and rarely gets you capability. A mandate is useful as air cover for the teams who already want to do it well; on its own it produces filed templates.

How often should we exercise?
Often enough that no single exercise carries the year, and on a published calendar so teams can plan. Short and frequent beats annual and elaborate for both adoption and evidence.

What if leadership only cares after an incident?
Use the window, then convert it into a cadence before attention fades. The post-incident moment is the cheapest budget you will ever raise and the easiest to waste.

How does this connect to board reporting?
Adoption produces the evidence the board wants. Tested capability beats documented plans, so the internal campaign and the upward story are the same work. See explaining a security program to the board.

Related

• How to explain your security program to the board — the upward half of this work.
• Marketing for operational resilience platforms — the same category, sold externally.
• Microsimulations — the short-exercise format that drives adoption.
• Resilience documentation — why untested plans read as weak evidence.
• Communications for risk and security teams — how we run this work inside enterprises.