It’s that time of the year again when we work through the budgeting process, which inevitably takes longer every year than anticipated. Every participant is fighting for their slice of the pie, and the inevitable conversation comes up to figure out whatright amount to spend on Security. No one wants to overspend, but underspending can also be disastrous. Phil Venables did a great job in a recent post on budgeting to approach it as a supply and demand problem. 

The issue we end up having as Security leaders is that Security programs tend to be multi-dimensional, while it appears unidimensional to those outside of the field. The unidimensional view is backed by the typical platitude of measuring the Security budget as a percentage of the IT budget, rather than as a proportion of spending across a number of different budget areas. It’s time to dig in to understand how to get the appropriate Security funding, and stop answering the percentage of IT budget questions.

It is important at this point to discuss different types of spending that a business will account for. For the sake of this exercise, we will look at a typical SaaS business budgeting process, but this thinking can be applied to any business and the means of funding Security:

• R&D: The R&D Budget is allocated for the creation of products and services. This is the budget where the developers, product managers, and QA teams tend to live, and the technology that supports them. The R&D budget, in many cases in the United States, can also be capitalized and part of tax write offs for the business as part of doing research for new products. R&D costs exist up front in a product’s existence as part of building products, as well as fixing issues on an ongoing basis. When we say “shift left” it means that we are more and more in the R&D space.

• Cost-of-Goods-Sold (COGS): The COGS budget is what is needed in order to operate the product during its running life. In the SaaS example, this includes things like cloud hosting costs or datacenter operations costs, manpower around those environments, and other expenses related to delivery. COGS is used to calculate ongoing operating costs that impact product margins and profitability.

• Customer Acquisition Costs (CAC): The CAC budget is what it costs to find and onboard customers. The CAC budget typically includes sales and marketing expenses and the process of selling to a customer.

• General and Administrative (G&A): G&A budget is the overhead to run a business, and overhead is something that needs to be tightly controlled as it does not generate revenue. Teams typically covered under G&A include Information Technology (IT), Legal, Finance, Human Resources, etc.

There are other budget areas as well, but these four budget areas are the most important for this discussion with the SaaS example. Manufacturing will have other budget areas as will industries like health care, but we will start here.

As you read through these different areas, you can immediately start to see that Security teams actually touch a variety of these areas. It may become obvious that describing the entirety of the Security budget as a percentage of IT does not make sense. Moreover, if the entire budget is allocated to G&A, then Security will always be overhead, and it will become a perennial candidate for cutting costs.

Aligning Security to Budget Areas

One of the most important things a CISO can do is to start aligning different elements of the Security budget to the correct budget type. Once they are properly aligned we can then address scaling predictably to ensure ongoing proportional funding is provided to Security.

A typical Security organization for a SaaS company will consist of the following broad strokes groups:

• Product Security: Securing the product development and software development process, and the security of the products throughout their existence. This can include everything from threat modeling to product security incident response.
• Platform Security: Securing where things run whether they are in the cloud or on premise environments related to the products and services.
• Governance, Risk, and Compliance (GRC): Design and management of the organization’s governance controls and certifications required to operate, and managing risk on an ongoing basis.
• Enterprise Security: Securing where and how employees and contractors do their work for the organization. This can include securing endpoints, SaaS services used by the organization, identity, etc.

Each of the areas above have a strong linkage to the different budget areas enumerated earlier. We now need to define scaling factors for the Security budget that are foundational to ongoing budget discussions. Agreement on the scaling factors allows for the more strategic risk conversations to happen. The scaling factors should take into account headcount, consulting, software, and licensing costs germane to the area in question.

• Product Security -> R&D Budget: The Product Security team should be closely aligned to the investment and staffing levels of the R&D budget. One metric could be to determine a percentage of spend from R&D that should be applied to the Product Security team. Another is to scale headcount proportionately with a pre-defined ratio – e.g. 100:1 Developers-to-ProdSec (NB: this ratio is not a recommendation but an example). By agreeing on a ratio, the discussion isn’t the dollar amount of the Product Security budget, but more strategically about whether the ratio is correct for the organization. While the ratio can be used to scale up when the team grows, it can also be used to scale the team down when the number of engineers decreases. The ratio itself serves as a proxy for product complexity and velocity for which the Product Security team needs to account and stay ahead of. Also feel free to tell your CFO that those resources can now be capitalized just like the development teams.

• Platform Security -> COGS: Connecting the Platform Security team to COGS measures will help the Platform Security team with the growing complexity of an environment. Examples of scaling factors could be the number of cloud providers, number of regions, percentage of cloud or datacenter spend, etc. The key is to select a scaling factor that is representative of the size, velocity, and complexity of the environment and technologies being secured to properly fund staffing and tooling.

• GRC -> CAC: Part of the GRC program can be tied to the CAC stream. For example, obtaining compliance certifications/attestations (e.g. SOC2, ISO 27001, FedRAMP, etc) should be considered to be part of CAC since they allow the business to target certain desired customers. Likewise, if those customers are no longer desirable then that would allow for scrapping certifications. Establishing a customer trust portal could be another example as it is a branding/marketing exercise, but also a means of decreasing the sales cycle duration.

• Enterprise Security -> G&A: And now, the only part of the security budget which should be considered to be a percentage of IT spend. Securing the enterprise is directly linked, oftentimes, to the rest of the G&A costs and scales. If more employees are hired, or more SaaS products are procured, then it is reasonable to expect that the Enterprise Security costs will rise as complexity increases.

As you can see, there are ways of scaling the Security organizations in alignment with the business. By establishing the scaling factors, we can agree on the appropriate level of investment, and the board-level conversations are not around “do you have enough money?” but rather “have we altered our alignment and scaling factors?”. Also, an important note, the board does not allocate funds, but discussing scaling factors and risk/governance can be part of their oversight.

The other interesting byproduct is when a business undertakes M&A activities, it allows the corporate development team to quickly understand how much hiring will be needed for the Security team to properly align to the new resources or complexity being acquired.

Next Steps:

Meet with your Financial Planning and Analysis (FP&A) team, or your CFO, to understand how the budget is designed for the rest of the organization. If the Security budget is all G&A, then find ways to align parts of the program to the rest of the budgets. Then work with your CFO or FP&A to properly allocate the costs to those budget areas. You will be helping your finance team also achieve some of their own metrics by controlling G&A costs, which can look to be out of control if the entirety of the Security budget is under G&A.