You’ve probably seen this: a security initiative that makes perfect technical sense, that addresses real risk, that has clear value—and it dies anyway.

Not because the technology doesn’t work. Not because the solution is flawed. It dies in a conference room during a budget meeting, or gets deprioritized when a business initiative takes precedence, or gets killed because nobody wants to deal with the organizational change it requires.

Security projects fail for organizational and political reasons far more often than they fail for technical reasons. And if you don’t understand those dynamics, you’re going to keep proposing good ideas that go nowhere, and you’re going to get frustrated wondering why leadership “doesn’t take security seriously.”

Often they do take it seriously. They’re just managing constraints and priorities that you might not see or understand. Your job is to figure out how to work within those constraints, or how to change the constraints if they’re actually fixable.

A note on broader applicability: This post focuses on security projects specifically, but the organizational dynamics we’re covering—budget competition, change resistance, executive sponsorship, political navigation—apply to ANY initiative that requires organizational change and resources. If you’re a network engineer trying to get budget for infrastructure upgrades, a developer advocating for technical debt reduction, or an operations manager proposing process improvements, the same patterns apply. Understanding these dynamics makes you more effective regardless of what type of initiative you’re trying to drive.

The Budget Reality

Security competes with everything else the organization needs to spend money on.

That SIEM you want? That’s $200K annually. Which is also three mid-level engineers. Or a business analyst the sales team has been requesting. Or infrastructure upgrades that have been delayed for two years. Or the CRM implementation that’s going to improve customer retention.

Money is finite. Saying “security is important” doesn’t create budget. Every dollar spent on security is a dollar not spent on something else.

Your leadership is making trade-offs constantly. Revenue-generating initiatives tend to get prioritized because they justify themselves—”if we invest X, we’ll generate Y in additional revenue.” That’s a clear ROI calculation.

Security investment is about avoiding negative outcomes. “If we invest X, we reduce the probability of a breach that might cost Y.” That’s a risk reduction calculation, which is inherently squishier and less compelling.

It shouldn’t be that way. The cost of a breach can be quantified reasonably well. But psychologically, spending money to enable growth is more appealing than spending money to prevent hypothetical harm.

Understanding this dynamic doesn’t mean accepting inadequate security budgets. It means framing your requests in ways that acknowledge the reality of budget competition and make the clearest possible case for why this particular investment matters more than the alternatives.

The Organizational Change Problem

A lot of security improvements require people to change how they work. And people hate changing how they work.

Implementing MFA means users have to do an extra step when they log in. Rolling out a new access review process means managers have to spend time reviewing permissions. Enforcing least privilege means people lose access they’ve had for years and have to request it when they need it.

These are all reasonable security measures. They’re also friction. And friction generates resistance.

Sometimes the resistance is loud. “This is going to slow us down.” “This is going to hurt productivity.” “Users are going to hate this.” Sometimes it’s passive—people just don’t do the thing, or they find workarounds, or they complain until leadership caves.

Either way, if your security project requires organizational change and you haven’t planned for managing that change, you’re going to struggle.

This means communication. Explaining why the change is happening, what the actual impact will be, how it benefits people (or at least the organization). It means providing support during the transition—help desk staffing for the initial rollout, documentation, training. It means having executive sponsorship so that when people push back, leadership reinforces that this is happening.

A lot of security people treat this as someone else’s problem. “I designed the technical solution, implementation is operations’ job, change management is HR’s job.” But if you care whether the project succeeds, you care about adoption. And adoption requires managing the human factors, not just the technical ones.

The “Not Right Now” Problem

Even when people agree a security project is valuable, it’s often not the highest priority right this moment.

There’s a major product launch coming. There’s an acquisition being integrated. There’s a regulatory audit happening. There’s a system migration in progress. There’s always something.

“Let’s do this after the launch.” “Let’s wait until the audit is done.” “Let’s revisit this next quarter when things calm down.”

Sometimes this is legitimate. Timing matters. Implementing major security changes during a critical business period might genuinely be a bad idea.

Sometimes it’s avoidance. Next quarter there will be a different reason why it’s not the right time. Things never actually calm down. This is how security work gets perpetually deprioritized.

The difference is whether there’s actually a plan to revisit it or whether “not right now” is a soft no.

If leadership says “this is important but we need to wait until after the product launch, let’s schedule planning for next month,” that’s different from “we’ll get to this when we have time” with no actual commitment.

Your job is to distinguish between realistic timing constraints and indefinite deferral disguised as timing constraints.

The Executive Sponsorship Gap

Security projects that don’t have executive sponsorship rarely succeed.

You can have the best technical plan. You can have identified a real risk. You can have a clear implementation path. But if nobody with organizational authority is backing it, it’ll get killed the first time it creates friction or competes with something else.

Executive sponsorship means someone in leadership who will say “this is happening” when people push back. Someone who will defend the budget when it’s challenged. Someone who will prioritize it when other initiatives compete for resources. Someone who has the authority to make decisions and the political capital to make them stick.

Without that, you’re trying to implement organizational change through force of argument and technical competence. Which doesn’t work when you don’t have decision-making authority.

Finding an executive sponsor means understanding who cares about what you’re trying to accomplish and why. Maybe it’s the CFO who’s worried about financial risk. Maybe it’s the COO who’s concerned about operational disruption. Maybe it’s the General Counsel who understands regulatory exposure.

Frame the security work in terms they care about. Build the relationship. Get them bought in. Then they can be your advocate in rooms you’re not in.

The Competing Priorities Reality

Organizations have finite attention and capacity. Even if budget isn’t the constraint, bandwidth is.

The IT team is already working on five major projects. The infrastructure team is underwater dealing with technical debt. The application team is fully allocated to new feature development. The operations team is firefighting daily.

Your security project requires time and effort from all of them. Where does that time come from?

Either something else gets deprioritized (which means someone else’s project gets delayed or killed, and they’re not going to be happy about that), or people work more hours (which isn’t sustainable and leads to burnout), or your project gets sequenced after their current work (which means it’s delayed, possibly indefinitely).

This is the reality of working in organizations. Everything competes for the same resources. Your project isn’t evaluated in isolation—it’s evaluated against everything else people could be doing instead.

Understanding this means being realistic about timing and scope. Maybe you can’t do the full implementation right now, but you can do phase one. Maybe you can’t get dedicated resources, but you can get part-time support. Maybe you can’t launch in Q2, but you can realistically launch in Q4.

Flexibility in how you approach the work makes it more likely to actually happen.

The “We Already Did Security” Problem

Sometimes organizations think they’ve already addressed security adequately, and new initiatives are viewed as unnecessary.

“We already have a firewall.” “We already do patching.” “We already have antivirus.” “We already passed the audit.” Therefore, additional security investment must not be needed.

This is frustrating because security isn’t binary. Having basic controls doesn’t mean you have adequate controls. Passing an audit doesn’t mean you’ve addressed all your risks—it means you’ve met the specific requirements that audit tested.

But try explaining that without sounding like you’re moving goalposts or just asking for more budget because security is never done.

The way through this is demonstrating gaps clearly. Not theoretical risks—actual gaps in visibility, detection, or capability.

“We have a firewall, but we can’t detect lateral movement inside the network.” “We do patching, but we have no visibility into SaaS applications.” “We passed the audit, but we can’t investigate incidents because our logging is inadequate.”

Make it concrete. Make it about specific capabilities you lack and specific scenarios where that creates exposure. Abstract arguments about security being an ongoing process are less compelling than concrete demonstrations of what you can’t do right now.

The Risk Communication Failure

A lot of security projects fail because the risk was never communicated in a way that resonated with decision-makers.

You know the threat is real. You understand the potential impact. You can explain the technical details of how an attack would work.

None of that matters if leadership doesn’t understand why they should care.

This goes back to what we talked about in Week 2 about calibrating your risk tolerance to organizational reality. Your assessment of what’s critical might not match leadership’s assessment—not because they’re wrong, but because they’re weighing factors you might not see. Your job is to translate the risk into terms that connect with their context.

And remember from Week 6: speak their language, not yours. Security terms mean nothing to them. Business impact does.

“We’re vulnerable to credential theft” is abstract. “If an attacker gets one compromised account, they can access our customer database and financial systems, which means breach notification, regulatory penalties, and significant reputational damage”—that’s concrete.

“We need better logging” is vague. “Right now, if we have an incident, we can’t determine what data was accessed or how long the attacker was in our environment, which means we have to assume the worst case for breach notification and we have no evidence to show regulators that we responded appropriately”—that’s specific.

Decision-makers need to understand the business impact, not the technical vulnerability. They need to understand the realistic threat, not the theoretical worst case. They need to understand what happens if this risk materializes, in terms of money, reputation, regulatory exposure, operational disruption—things they’re measured on.

If you’re explaining security risk in security terms, you’re probably not being understood.

The Perfect vs. Good Enough Problem

Sometimes security projects fail because they’re over-engineered for the actual need.

You want the enterprise-grade solution that solves everything comprehensively. Leadership is willing to fund the good-enough solution that addresses the most critical gap at a fraction of the cost.

You want to implement least privilege everywhere. Leadership is willing to do it for the highest-value systems first and revisit the rest later.

You want comprehensive logging. Leadership is willing to fund logging for critical systems and compliance requirements.

You want to move from traditional antivirus to EDR with full detection and response capabilities. IT is nervous about the “what ifs”—what if it impacts performance, what if it generates too many alerts, what if users complain? Deploy EDR initially in monitor-only mode or with basic detection enabled. Prove it doesn’t break things. Then enable advanced features progressively over the next year or two. You still get better security than AV, just not everything at once.

The perfect solution that never gets funded is worse than the good-enough solution that actually gets implemented.

This doesn’t mean compromising on things that are genuinely critical. But it means being honest about what’s critical versus what’s nice-to-have. It means being willing to phase implementations. It means accepting that incremental progress is still progress.

(Go back to Week 2 if you need a reminder: Fort Knox isn’t the goal. Sometimes the phased, imperfect implementation is actually better security than holding out for the comprehensive solution that never gets approved.)

Sometimes the perfect solution isn’t realistic given organizational constraints. Good-enough that’s achievable beats perfect that never happens.

The Politics You Can’t Ignore

Security work happens in a political environment whether you like it or not.

There are power dynamics. There are relationships. There are people who have influence beyond their formal authority. There are historical conflicts that shape current decisions. There are alliances and rivalries.

If you ignore all of this and just focus on the technical merits, you’re going to be confused when technically sound projects fail and technically questionable projects succeed.

I’m not saying you need to become a politician. But you need to understand the political landscape enough to navigate it.

Who are the decision-makers? Who influences them? Who benefits from your project succeeding? Who might perceive it as threatening their domain? Who’s going to push back and why?

Here’s something practical: there will be naysayers to any initiative. Learn what they consistently stand on. Trust me—it’s almost always the same exact things, maybe phrased differently, but if you boil it down to the core objection, it’s the same every time.

The IT Help Desk manager who pushes back on every new tool? It’s about call volume. He doesn’t want an influx of break-fix calls or password resets. So when you propose MFA, don’t just talk about security benefits. Address his concern directly—and better yet, show how it helps him: “With MFA using authenticator apps, we can now enable self-service password resets. Users can prove their identity and reset their own passwords without calling the help desk. Here’s the training we’ll provide. Here’s the online resource users can reference. And I’ll personally help answer calls during the first week of rollout. Long-term, this should actually reduce your password reset call volume.”

The developers who resist using a secrets manager? They’re thinking it’s going to be complicated—that they’ll have to write dedicated functions and rewrite significant portions of their code. Learn their stack. Most secrets managers and vaults provide drop-in modules for common languages. Show them the actual code: “Here’s the three-line change in Python. Here’s the SDK for Node. Here’s how it works in .NET. It’s literally a module import and one function call to retrieve secrets.”

Better yet: learn a little bit of the code your developers actually work in and write a few small demo apps that show it in practice. You don’t need to be an expert—just competent enough to prove it works in their environment with their stack. Walking into a meeting with a working example in their language earns respect. It shows you’re not just theorizing from a security ivory tower—you actually understand what you’re asking them to do. And it makes it harder for them to claim it’s too complicated when you’ve already done it.

The application team lead who resists security requirements? It’s usually about timelines and scope creep. So when you need security reviews integrated into their process, frame it as: “I can review designs in 24 hours if you get them to me early. That’s faster than trying to retrofit security after implementation, which delays your launch.”

Understanding this helps you build support before you need it. It helps you anticipate objections. It helps you frame proposals in ways that address what people actually care about—not just what they say they care about.

Security people often want to believe that good ideas win on merit. In functional organizations, merit matters. But it’s never the only thing that matters.

What Actually Works

Start small and demonstrate value. Don’t ask for everything up front. Ask for enough to prove the concept, deliver results, and build credibility for the next phase.

Build coalitions. Find allies in other parts of the organization who benefit from what you’re trying to do. IT operations might care about better logging because it helps them troubleshoot. Legal might care about access controls because it reduces compliance risk. Get them on your side.

Frame in business terms. Not technical risk—business impact. Not security concepts—outcomes leadership cares about.

Have executive sponsorship. Find someone with authority who will advocate for the work. Without that, you’re fighting uphill.

Plan for organizational change. If your project requires people to work differently, plan for how you’ll manage that. Communication, training, support.

Be flexible on timing and scope. Phase the work if you can’t do it all at once. Accept delays if they’re unavoidable. Adapt to organizational constraints.

Understand the political landscape. Know who the decision-makers are, who influences them, and what they care about.

Accept imperfect progress. Good-enough that gets implemented is better than perfect that doesn’t.

Practical Takeaways

Security projects compete for budget and resources with everything else the organization needs. Frame requests to acknowledge this reality.

Organizational change is harder than technical implementation. Plan for managing the human factors.

Executive sponsorship is critical. Find someone with authority who will advocate for the work.

Communicate risk in business terms, not technical terms. Business impact, regulatory exposure, operational disruption—things leadership is measured on.

Be flexible on scope and timing. Phased implementation beats waiting for perfect conditions.

Understand the political landscape. Decision-making isn’t purely rational. Relationships and influence matter.

Start small, demonstrate value, build credibility for larger initiatives. Prove you can deliver.

Good-enough that happens beats perfect that doesn’t. Accept incremental progress.

Most security project failures are organizational, not technical. Plan accordingly.

Podcast: Download (Duration: 20:42 — 11.2MB) | Embed

Subscribe to the Cultivating Security Podcast Spotify | Pandora | RSS | More