It’s a Trap! Avoiding the Security Budget Trap.


It’s a trap.  You know it’s a trap.  But you don’t know how to avoid the trap.

It is budget season.  You need to start defining your budget for 2019.  There are two main ways I’ve seen this play out.


You take a look at your program, think about a couple of tools you want to add.  They’ll cost what 100K-200K each?  Maybe account for some raises, maybe one or two new hires and we’re already looking at $500K – $1M.  Cool.  That’s a significant increase, let’s pull the trigger.


Most IT budgets increase somewhat year over year as companies grow and expand their investment into IT.  So … let’s just make our security budget = last year’s security budget + 10%.  Maybe we’ll ask for 25% and hope to actually get 10%.

The Trap

The trap is that neither of these approaches gets you anywhere near:

  • The right budget
  • The right argument for the right budget

Without the right argument for the right budget, you’re probably not going to be able to make major changes and or more importantly, the right major changes.


Every year (maybe every quarter) we should be looking at risk.  We should use risk to inform the whole direction and composition of our program.  Our investment in security should be a well-informed function of risk.

Guess what, it’s really hard to understand risk without having conversations with business stakeholders about what would happen if X, Y and Z happened?  You don’t want to scare them, but you need to be on the same page with them.

Whether we use the Percentages approach or the Wants approach, it is quite likely that our security program will continue to lag well behind where it should be.  That’s because it is likely that your program, as it exists today, is extremely underfunded.  So adding even a good year over year percentage won’t get you there.  What if your security investment should be 20X what it is right now?  How would you even know?


  • $20 M program.  10% = $2M.  That’s a significant program with a significant growth investment by classic standards.
  • But what if the right size of that program is $50M?  You’re still less than half way there!!!

The same argument applies for larger and smaller budgets by the way.

So let’s say your program is underfunded.  One way to deal with that is to whine about not having enough resources.  Another is to go to your stakeholders and make them accept the risks they are facing.  Like, with a specific monetary penalty in mind.


The fundamental nature of the trap is that the common approaches to sizing a security program lend themselves to an incremental _addition _of resources in new areas but not corrections in others.  Some tools need to be retired but rarely is the person who is running those tools going to advocate for that.  You can be sure the company that is selling them wants to keep them there.  Sometimes if you try to re-allocate resources from one area to another you risk losing them so the whole program is built on a foundation that can never be shifted.

Learn To Negotiate

Sometimes whole sectors shift.  Consider AV.  What should you really be spending on AV?  Firewalls?  If your investment in AV and Firewalls haven’t changed over the past few years, you are probably missing something.  That should be reflected in the contracts you are signing.  Think about how to secure AWS?  Maybe that actually has more to do with your internal DevOps practices than an external vendor.  (Shocking, I know!)  If you know the value of a given service and the risk of not having it, you can negotiate cleanly with vendors and stakeholders to get your best outcome.

By the way, this doesn’t mean the same thing as “shake vendors down”.  We’ve seen a few scenarios where it was obvious after the fact that the company was just talking to us to either get a better price from a competitor or to get the lowest price.  While you should absolutely do your best to know the value of what you are paying for and hold your vendors accountable, not all services can be compared apples to apples.  There are few security firms that can truly say they partner with developers the way we do for instance.  We don’t do physical tests or hardware hacking at all.  If you didn’t think about the right factors for differentiation when you made the choice, that can’t be part of your evaluation.  Beware of anyone who says they are good at everything…


Budgeting is hard but maybe not for the reason many people think.  Learn the mechanics of it early to empower yourself to understand how you got to the present moment.  The hard part of budgeting is the negotiating and prioritization.  Be up front and understand what your budgets mean.  Be able to translate that into a narrative or a story for your boss and your stakeholders.  Few companies have great stories here, but it might be the most important place that we can make a huge difference.

Share this article with colleagues

Matt Konda

Founder and CEO of Jemurai

Popular Posts

Ready to get started?

Build a comprehensive security program using our proven model.
© 2012-2024 Jemurai. All rights reserved.
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram