The Politics of IT Security in 2026: Why Good Security Decisions Get Blocked (And How to Get Them Approved)

If you’ve worked in IT security long enough, you’ve probably experienced this scenario.

You identify a clear risk. You propose a well-thought-out solution. It’s aligned to best practices, backed by vendor guidance, and in many cases, relatively straightforward to implement.

And then… it gets blocked.

Not because it’s technically wrong. Not because it’s too complex. But because of something less visible—and far more frustrating.

Organisational politics.

This is the part of IT security that rarely gets documented. Frameworks don’t cover it. Vendor playbooks ignore it. Yet it’s often the single biggest reason why security improvements fail to materialise.

In real-world environments, security decisions are influenced by:

• Business priorities
• Budget constraints
• Internal power dynamics
• User resistance
• Fear of disruption

In this article, I’m going to break down:

• Why good security decisions get blocked (even when they’re right)
• The political and organisational factors at play
• Real-world examples of where things go wrong
• Practical strategies to get security initiatives over the line

Because in 2026, technical skill alone isn’t enough—you need to understand how to navigate the business side of security as well.

Quick Fix Summary

If you want to get security decisions approved faster:

• ✅ Translate technical risks into business impact
• ✅ Align security initiatives with organisational goals
• ✅ Start with low-friction, high-impact wins
• ✅ Build allies outside of IT (finance, operations, leadership)
• ✅ Present solutions, not just problems

The Reality: Security Decisions Aren’t Made on Technical Merit Alone

One of the hardest lessons for technical professionals is this:

👉 The “best” solution doesn’t always win.

In most organisations, decisions are made based on a mix of:

• Risk tolerance
• Cost vs benefit
• Operational impact
• Internal priorities

Security is just one piece of that puzzle.

And unless your proposal fits into that broader context, it’s likely to be delayed—or rejected entirely.

Why Good Security Decisions Get Blocked

1. The Risk Isn’t Understood (Or Felt)

Security risks are often abstract.

You might explain:

• Credential theft
• Lateral movement
• Data exfiltration

But to a non-technical stakeholder, these don’t always translate into something tangible.

Compare that to:

• Revenue loss
• Customer impact
• Regulatory fines

If the risk isn’t clearly tied to business outcomes, it won’t get prioritised.

2. The Impact Feels Immediate—The Risk Feels Distant

Security improvements often introduce friction:

• MFA prompts
• Access restrictions
• Workflow changes

The problem is that:

• The impact is immediate
• The benefit is preventative

So from a business perspective, it can feel like:
👉 “We’re making things harder for a problem that hasn’t happened.”

That’s a tough sell.

3. Ownership Is Unclear

In many environments, security sits in an awkward position.

It:

• Recommends controls
• Identifies risks

But doesn’t always:

• Own systems
• Control budgets
• Make final decisions

This leads to:

• Delays
• Conflicting priorities
• Decisions being pushed elsewhere

4. “We’ve Always Done It This Way”

Legacy processes are one of the biggest blockers.

Even when:

• Better solutions exist
• Risks are understood

Change is resisted because:

• Systems are familiar
• Processes are embedded
• Nobody wants to own the disruption

5. Fear of Breaking the Business

This one is often justified.

Security changes can:

• Break applications
• Impact integrations
• Disrupt workflows

So teams hesitate—even when the risk is real.

I’ve seen MFA rollouts delayed for months because of concerns around:

• Legacy systems
• Service accounts
• User experience

Real-World Example: MFA That Took 12 Months to Approve

In one organisation, the security team identified a clear gap—MFA wasn’t enforced across all users.

The solution was straightforward.

But approval took over a year.

Why?

• Finance was concerned about licensing costs
• Operations worried about user disruption
• Application owners flagged compatibility issues

None of these concerns were wrong—but they weren’t addressed effectively upfront.

Once the proposal was reframed around:

• Risk of account compromise
• Impact on business continuity
• Phased rollout strategy

…it was approved within weeks.

How to Navigate the Politics (Without Losing Your Mind)

This is where things shift from technical to strategic.

Step 1: Translate Security Into Business Language

Instead of saying:

• “We need Conditional Access policies”

Say:

• “This reduces the risk of unauthorised access to customer data”

Tie everything to:

• Revenue
• Reputation
• Compliance

Step 2: Present Solutions, Not Just Problems

Highlight:

• The risk
• The impact
• The solution
• The effort required

Avoid:
👉 Dropping a problem and expecting others to solve it

Step 3: Start Small and Build Momentum

Big security initiatives often fail.

Instead:

• Identify quick wins
• Implement low-impact changes
• Demonstrate value early

This builds trust—and makes future approvals easier.

Step 4: Identify and Engage Stakeholders Early

Before formal approval:

• Talk to application owners
• Engage operations teams
• Get buy-in from leadership

This reduces resistance later.

Step 5: Use Data to Support Your Case

For example:

Check MFA coverage:

Get-MgUser -All | Select DisplayName, UserPrincipalName, AccountEnabled

Or review risky sign-ins in Entra:

• Entra ID → Sign-in logs → Risky sign-ins

Data makes the risk real.

The Role of Technical Validation

Here’s something often overlooked:

Sometimes resistance comes from legitimate technical concerns.

Before pushing forward:

• Test changes in a pilot group
• Validate compatibility
• Document impacts

This turns:
👉 “We think it might break”
Into:
👉 “We’ve tested this, and here’s the outcome”

Additional Tips / Pro Tips

Frame security as an enabler, not a blocker
Show how it supports the business—not slows it down.

Understand your organisation’s priorities
Align your proposals with what leadership cares about.

Build relationships, not just proposals
Trust matters more than technical detail in many cases.

Use phased rollouts
Reduce risk and resistance.

Warnings

Being technically right isn’t enough
If you can’t communicate effectively, your ideas won’t land.

Pushing too hard can backfire
Collaboration works better than confrontation.

Ignoring business context is a mistake
Security must fit into the organisation—not the other way around.

FAQ Section

Why do security initiatives get blocked?

Because decisions are influenced by business priorities, cost, operational impact, and risk perception—not just technical merit.

How can I get leadership to support security projects?

By translating technical risks into business impact and aligning proposals with organisational goals.

What is the biggest mistake security teams make?

Focusing on technical detail without considering business context.

How do I handle resistance to security changes?

Engage stakeholders early, address concerns, and demonstrate value through testing and phased implementation.

Is it normal for security projects to be delayed?

Yes. It’s common due to competing priorities and organisational dynamics.

Conclusion / Actionable Takeaways

The uncomfortable truth is this:

👉 IT security is as much about people as it is about technology.

You can have:

• The right solution
• The right tools
• The right approach

But if you can’t navigate the organisational landscape, it won’t matter.

What to do next:

1. Reframe your current security proposals in business terms
2. Identify key stakeholders and engage them early
3. Start with small, high-impact improvements
4. Validate changes before pushing for approval
5. Build trust and credibility over time

From experience, the IT professionals who succeed in security aren’t just technically strong.

They’re the ones who understand how to get things done inside real organisations.

Last Updated

April 2026 – Reflects current organisational challenges in cybersecurity decision-making and Microsoft 365 security environments.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.