Security Budgets: a strategy for managing security performance

Chris Brown states in the blurb for his new book, “Your job as CISO isn’t to secure the company,” just as it’s not the job of HR to manage your staff.

In the documentary Safety Differently, the head of safety at Origin talks about cutting the size of the team from 20-30 people down to 5, an 80% reduction. “I needed to do that because we actually needed to step out of managing safety performance, and while we were in there doing their job, it created no space for them to do their own job.”

The cybersecurity function can’t prevent breaches, but it can promote security performance. One strategy to accomplish this is an idea I first presented in a talk at SREcon, the Security Level Objective and Security Budget, which is based on the Site Reliability Engineering concepts of Service Level Objective (SLO) and Error Budget. The core concept of the SRE Error Budget is to find the right balance between features/functionality and reliability/performance. The goal is to find a key metric for performance over time that is just enough to keep your users happy. It is a negotiated commitment device that guides investment; when performance drops below the agreed upon level, the organization shifts resources from features to performance. It’s not meant to be absolute, but to establish a “budget” for creative work and experimentation that can be balanced against the need to create a product that is performant. A typical SLO will measure a ratio of “successful” transactions over a total number of transactions with a specific target for a success rate per week/month/year. Outages and other failures reduce the available “budget”.

In cybersecurity, incidents happen much less frequently; about once every 6-8 years or less for firms with an annual revenue of $10 billon or less (per the IRIS 2025). Because of this, we must find an alternative metric that’s correlated with success. For software engineering, one such metric is dependency currency: are you using the latest version of the libraries your code depends on? The evidence suggests that habitually updating software is the best approach to minimizing security vulnerabilities (along with configuration management, to a lesser degree), so a Security Level Objective related to this can form the basis of your Security Budget. It could simply be the percentage of libraries that are up to date, or a more security-focused metric like the number of vulnerabilities per application/service, or even the cumulative likelihood of a vulnerability being exploited in the next 12 months.

The specific metric chosen should be an indicator that all stakeholders agree is a reasonable measure of security performance, with a target aligned to the security goals of the organization, and periodically reviewed. An initial target might be “90% of project dependencies are up to date,” which could be revised to 95% in the first quarterly review. Falling below the target is a signal to the project team to spend time improving how and when dependencies are updated, including with automation, and not just “fixing what’s broken” and manually updating. The project team is now entirely responsible for this aspect of security; the security team’s role is to identify areas of risk, negotiate security targets aligned to organizational goals, and provide resources and tools that support the project team in meeting those goals. Conversely, when the project team is meeting its Security Budget, it’s free to focus on features & functionality (and sometimes performance..)

The Security Budget approach brings the role of the security team more in line with HR or Finance; Finance facilitates budget creation, monitoring of performance against the budget, identifies risks, and provides tools and support to individual teams to meet their budget, but ultimately it’s the team’s/department’s responsibility to meet the budget, or to change it when that’s appropriate.

How can cybersecurity teams get started with Security Budgets? Start by starting - identify an area of risk and negotiate a measurable and achievable target that internal stakeholders agree brings the risk to an acceptable level. It doesn’t have to be right the first time; in fact, there’s a good chance it will be wrong, so be sure to set up a periodic budget review to discuss performance and change the target if needed. The ongoing discussions and negotiations are what’s important.