How should CISOs build security support across leadership and frontline teams when budgets are tight and change resistance is high?

Why This Matters for Security Teams

Security support becomes harder to sustain when it is framed as an abstract control problem instead of an operating model that helps leaders make trade-offs and helps frontline teams work faster with less uncertainty. Budget pressure usually forces CISOs to prove that security reduces loss, downtime, and rework, not just that it satisfies policy. The message has to change by audience: executives need risk and business impact, while engineers and operators need friction reduction, clear ownership, and workflows that fit how work already happens. Research on secrets management reinforces that gap, with The State of Secrets in AppSec showing that organisations still dedicate substantial budget to the problem while confidence and day-to-day practice remain misaligned. In practice, support erodes fastest when security asks for commitment without showing which burden it removes from the people doing the work.

How It Works in Practice

The most effective approach is to build a support case around operational outcomes, then translate that case into specific asks for each audience. For leadership, the CISO should define the business problem in plain language: where delay, loss, incident frequency, audit exposure, or delivery disruption will occur if funding is reduced or change is resisted. For frontline teams, the same programme should be expressed as fewer manual steps, fewer exceptions, and fewer ambiguous decisions. If a control does not reduce noise, remove toil, or clarify ownership, it is unlikely to gain durable support.

Good programmes usually combine four elements:

• A small set of measurable risks tied to current business priorities.
• Clear ownership, so teams know who approves, implements, and maintains the control.
• Automation or workflow integration where manual review creates avoidable delay.
• Training that explains the “why” and the “what changes for me” in operational terms.

That is where the security narrative becomes credible. A leader is more likely to back a funding request when the CISO can show that a specific control shortens response time, limits exposure, or reduces recurring effort. A frontline manager is more likely to cooperate when the change reduces ad hoc exceptions and makes secure behaviour the default. The pattern is especially visible in secrets handling, where fragmented tooling and slow remediation create frustration for developers and analysts alike; The State of Secrets in AppSec is useful because it shows that capability and practice often diverge even when organisations believe they are already in control.

These controls tend to break down when security teams present a large programme as a single transformation instead of a sequence of concrete workflow changes with local ownership.

Common Variations and Edge Cases

Tighter budgets often increase the need for prioritisation, but they also raise the political cost of every change, so the CISO has to decide where support is gained through simplification and where it is gained through enforcement. In some organisations, the right move is to remove friction first, because frontline resistance is mainly caused by process burden. In others, the right move is to hold a firmer line, because the resistance is really a sign that a high-risk exception has become normalised.

There is no universal standard for the exact mix, but current guidance suggests three common edge cases. First, if leadership support exists but frontline adoption is weak, the issue is usually not awareness, it is workflow design. Second, if frontline teams are willing but managers are not, the blocker is often middle-management capacity, not technical disagreement. Third, if the organisation is highly distributed, a single central message will fail unless local leaders can adapt it without changing the control intent. The best security programmes accept that one-size-fits-all communication is usually the wrong model.

Where change resistance is high, CISOs should resist the temptation to justify everything with urgency alone. Urgency can start attention, but it rarely maintains support after the first round of trade-offs. The more durable path is to align the request to the audience’s own metric of success, whether that is uptime, delivery speed, audit readiness, or incident reduction.

Practitioner Guidance

What to prioritise: Start with the controls that remove repeated manual effort, because those are easiest to defend under budget pressure and easiest for frontline teams to notice as a benefit.

Decision rule: If a proposed control adds review work without reducing exposure, delay it or redesign it; if it reduces both exposure and toil, it is usually the strongest candidate for support.

What to verify: Confirm that every key audience can answer three questions: what risk is being reduced, what changes in daily work, and who owns the exception path.

Common mistake: Treating resistance as a communications failure when it is actually a design failure. If the secure path is slower, more confusing, or less reliable than the unsafe one, messaging will not fix adoption.

Practitioner takeaway: Durable support comes from making security visibly useful to the people who fund it and the people who operate it, not from asking either group to accept friction on faith.

Related resources from NHI Mgmt Group

• How should security teams build a cryptographic inventory across cloud and CI/CD systems?
• How should security teams build a unified view of identity risk across IAM tools?
• How should security teams govern developer agents that can act across code, build, and deployment systems?
• How should security teams handle identity-related support requests across Slack and ticketing tools?