Three ways cybersecurity projects win buy-in in siloed organisations

At a glance

What this is: Illumio argues that cybersecurity projects most often fail on organisational alignment, not on the underlying technology.

Why it matters: For IAM and NHI programmes, the lesson is that access controls, containment, and lifecycle changes will not stick unless networking, operations, and leadership share the same incentives.

👉 Read Illumio's blog on three practical ways to win buy-in for cybersecurity projects

Context

Cybersecurity programmes frequently stall when the governance problem is mistaken for a tooling problem. The first obstacle is rarely a missing control, but a mismatch between teams that own adjacent systems, budgets, and operational risk. In identity-heavy programmes, that matters because access, segmentation, and lifecycle changes all cut across organisational boundaries.

For IAM, NHI, and PAM teams, the challenge is not only technical integration but shared accountability. If a security initiative affects networking, infrastructure, or operations, it needs sponsorship, a clear business outcome, and a plan for reducing friction, otherwise the project becomes a negotiation rather than a control change.

Key questions

Q: How should security teams get buy-in for a new cybersecurity control?

A: Start by identifying the teams that will carry the operational burden, then tie the control to a business outcome they already care about, such as recovery time or fewer disruptions. Present the change in terms of shared risk and shared benefit, not only technical necessity. When leaders visibly support the goal, approval becomes easier to sustain.

Q: Why do cybersecurity programmes stall even when the risk case is strong?

A: They stall when the proposal is technically correct but organisationally misaligned. Teams may already own overlapping tools, fear workflow disruption, or see the project as extra overhead. If the control is not translated into their priorities and timing constraints, resistance can slow delivery even when the security rationale is sound.

Q: What do security teams get wrong about executive sponsorship?

A: They treat sponsorship as a funding checkpoint instead of an operating signal. Executive backing should tell the organisation that the project matters, that teams are expected to cooperate, and that long-term resilience is the goal. Without that message, local objections can override the security intent and fragment implementation.

Q: How can security teams make technical risk understandable to non-specialists?

A: Use a concrete scenario that shows the operational consequence of not acting. Describe what fails, who absorbs the disruption, and why the timing matters. That approach makes the control easier to discuss with business, operations, and infrastructure stakeholders because it turns abstract risk into a shared operational story.

Technical breakdown

Why cross-team pushback stalls security programmes

Security initiatives often fail when they are introduced as standalone technical projects instead of operational changes that affect other teams' roadmaps. Cross-team pushback usually reflects local incentives, existing tooling commitments, or fears that a new control will create extra work or break established workflows. The issue is not always resistance to security itself. More often, teams are responding to uncertainty about cost, ownership, and disruption. That makes the implementation problem as much about governance as architecture. In identity programmes, the same dynamic appears when access review, segmentation, or secret-management changes touch multiple control owners.

Practical implication: map affected teams and their operational concerns before asking for approval.

Executive sponsorship and control adoption

Executive sponsorship does more than approve funding. It sets the organisational expectation that security changes are business priorities, not optional technical experiments. Without that signal, teams can treat a project as someone else's problem, especially when it requires work from networking, infrastructure, or application owners. Leadership backing also helps resolve trade-offs when short-term convenience conflicts with long-term resilience. In identity governance, this is critical because access and privilege controls only work when the organisation agrees to enforce them consistently across systems and teams.

Practical implication: secure leadership commitment before implementation details are finalised.

Storytelling as a control adoption mechanism

Storytelling works because it converts an abstract risk into an operational scenario people can picture. Facts tell stakeholders that a control matters, but stories explain what fails if the control is absent, who absorbs the disruption, and why timing matters. In security governance, this is especially useful when the audience does not live inside the control domain every day. For IAM and NHI programmes, stories about outage avoidance, breach containment, or reduced operational chaos often land better than control language alone. The point is not persuasion for its own sake. It is translating technical risk into business consequence.

Practical implication: use concrete failure scenarios to explain why the change matters now.

Threat narrative

Attacker objective: The objective is not data theft but delay, because stalled controls preserve exposure windows for future compromise.

1. Entry occurs through organisational friction, where a security initiative is delayed because teams do not agree on ownership, priority, or operational impact.
2. Escalation follows when unresolved objections and weak sponsorship let local vetoes override enterprise risk decisions.
3. Impact is programme stagnation, leaving security gaps in place longer and delaying resilience improvements that were already justified.

NHI Mgmt Group analysis

Cross-team alignment is now a core security control, not a soft skill. Security programmes fail when governance assumes technical correctness is enough to drive adoption. In reality, networking, operations, infrastructure, and security each carry different risk tolerances and delivery pressures. Identity programmes are especially exposed because access, privilege, and lifecycle controls cut across ownership boundaries. Practitioners should treat alignment as part of control design, not as a post-approval communications task.

Security buy-in breaks when the programme cannot translate risk into operational consequence. Teams rarely reject security because they oppose resilience. They resist when a project is framed in abstract threat language that does not connect to uptime, ticket volume, recovery time, or change stability. That gap is familiar in IAM and NHI governance, where lifecycle controls can feel bureaucratic until they are tied to outage reduction or incident containment. Practitioners should anchor the case in measurable business outcomes.

Strong executive sponsorship is the difference between policy intent and enforceable change. The article is right to emphasise leadership, because a control that is only supported at the project team level can be sidetracked by local priorities. That pattern matters in identity and segmentation programmes, where enforcement depends on many teams making the same trade-off at the same time. Practitioners should build sponsorship into the control operating model, not the launch plan.

Storytelling improves control adoption because it makes risk legible to non-specialists. A control programme that cannot explain what failure looks like will struggle to sustain momentum. The named concept here is security translation debt: the gap between a valid technical control and the organisation's ability to understand why it matters. In identity governance, that debt delays action and weakens enforcement. Practitioners should reduce it with concrete scenarios and business consequences.

Identity governance succeeds only when the organisation accepts shared ownership of access change. IAM, PAM, and NHI programmes often fail in the handoff between control design and operational reality. The article's core lesson is that programme risk increases when security expects compliance without negotiating workflow impact. Practitioners should design ownership, escalation, and sign-off paths before asking teams to absorb new identity controls.

What this signals

Security translation debt: many programmes have enough evidence to justify change but not enough organisational language to secure adoption. That gap will keep slowing IAM, NHI, and containment initiatives until teams tie controls to measurable outcomes and shared operating pain, not just policy language.

For identity-heavy programmes, the lesson is to treat stakeholder friction as a delivery risk. Stronger sponsorship, better timing, and clearer operational framing will matter as much as the control design itself, especially when access, privilege, or segmentation changes span several ownership domains.

For practitioners

• Build a stakeholder map for every control change List the teams that will absorb work, operational risk, or workflow disruption before the project is presented for approval. Capture their stated concerns, existing tooling, and decision authority so you can address friction early rather than after pushback starts.
• Secure executive sponsorship tied to a business outcome Ask leaders to endorse the outcome you are trying to deliver, such as lower recovery time, fewer outages, or faster containment, rather than only the implementation plan. That creates a visible mandate when other teams question priority.
• Translate technical controls into failure scenarios Use a short scenario that shows what happens if the control is missing, who is affected, and how the business absorbs the impact. Keep the example close to the audience's operating reality so the risk feels tangible.
• Align project timing with adjacent roadmaps Check change calendars, infrastructure milestones, and team capacity before proposing the work. A control that lands during a major platform shift or quarter-end freeze will face avoidable resistance even when the business case is sound.

Key takeaways

• Cybersecurity projects often fail because governance and incentives do not line up, even when the technical case is strong.
• The article’s practical lesson for identity teams is to frame access and containment changes in terms of shared outcomes, executive support, and operational disruption.
• Storytelling is not cosmetic in security change management. It is how teams make risk concrete enough for the rest of the organisation to act.

Key terms

• Executive Sponsorship: Executive sponsorship is visible leadership support for a security initiative that gives it priority across the organisation. It matters because many controls fail at the handoff from strategy to operations, and sponsorship helps resolve competing roadmaps, budget pressure, and ownership disputes.
• Security Translation Debt: Security translation debt is the gap between a technically valid control and the organisation's ability to understand why it matters. The larger the gap, the harder it becomes to secure buy-in, sustain adoption, and align teams around the operational impact of the change.
• Stakeholder Alignment: Stakeholder alignment is the deliberate coordination of security, operations, compliance, HR, and business leaders around identity goals. It matters because identity security succeeds only when different groups agree on risk, ownership, and the outcomes the programme is meant to deliver.

What's in the full article

Illumio's full blog covers the operational detail this post intentionally leaves for the source:

• A practical explanation of how to build a business case that survives cross-team resistance and budget friction.
• Examples of the stakeholder concerns that often block deployment, including overlapping tools and perceived workflow disruption.
• Concrete storytelling approaches for making cybersecurity risk understandable to non-specialist audiences.
• Guidance on using leadership sponsorship to keep implementation moving after initial approval.

👉 Illumio's full post adds the stakeholder tactics, storytelling examples, and leadership framing behind the buy-in approach.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management in a way that supports identity and security practitioners across programmes. It helps teams turn control intent into operational practice across access, lifecycle, and ownership decisions.