Security Leaders Win Budget By Auditing Their Own Operating Model First

Security operations leaders asking for more money usually start with what the team lacks. Security spending keeps climbing across the industry, and a team that can show where the last allocation went has a better claim on the next one. Leaders who spend a few months tracking response times, false positive rates, and vendor performance walk into the same meeting with a record. The tracking also surfaces problems that no amount of funding would have fixed, and those months of tracking turn a request into a case.

Hem Asher, former Senior Manager of Information Security at Insurity, has built security programs at SaaS and technology companies across insurance, healthcare, and digital experience. At Insurity, he directed security operations, governance, risk and compliance, and third-party risk management, reporting to the CIO and CISO. At Contentstack, he led information security and IT across the United States and India, taking the organization through SOC 2 Type II and ISO 27001 certification. Both roles made him responsible for taking a security budget to executives and defending it.

"Once you have the right metrics, you look at your operating model. If it's the same operating model that you've had for the last five, six years, it might not align with what the business needs today. You kind of have to look at it in all angles and then work from there, but tracking metrics is the first part," says Asher. A team that has measured itself can say where its capacity goes, and the business can check the answer. Asher treats every later step as dependent on that record.

Metrics before the ask

Security leaders who can't demonstrate where their team's capacity is being consumed will struggle to make a compelling case for additional resources. Asher typically starts by establishing a metrics program that provides that visibility before making the case for additional investment. Many security groups reach that question with a sense of where the time goes and no record of it. Without that data, executives are left evaluating a largely subjective request. "There's always the basic KPIs that you need to track, like mean time to respond, mean time to detect and false positives and all that," Asher says. "But really you should align those metrics with what your business might need. Align those KPIs with requirements that your business has to meet."

Asher extends the same requirement to any provider carrying part of the work. An MSSP or MDR contract moves a share of the operation outside the team, and he wants those numbers collected on the same terms as the internal ones. He lets the program run before drawing anything from it, and he puts the point at which the data becomes useful in months. The wait gives a security leader something to hand a finance team. "Over a course of a couple months, I can typically start seeing data that shows me the performance and where it's at, which is a really good place to start in terms of improvement," he adds.

Naming the top risks

Operational metrics answer how a team is performing. Asher pairs them with a separate assessment of business risk that runs across the whole company and puts a cost on what a given system failing would do. "What I typically like to do is pretty much maintain a risk register for lack of better terms," says Asher. "Based on that you could go and assess all the risks that the business has, leveraging a certain framework that will identify what are your top 10, top 15, whatever you're looking for, risk for the business."

The full register is maintained by Asher's security team, while a ranked shortlist goes to the business. He assembles it from the assessment work before any of it reaches an executive. Remediations, budgets, and proof-of-concept work all trace back to the same document. "The first step really is to be able to show the business, hey, here's the top five risks," Asher explains. "We've assessed it across the business. We've talked to different leadership, we've talked to different business operational teams. Here is what we see."

Breach scenarios are the type risk a security team is expected to highlight. Asher widens the category once the conversation reaches leadership. "When people talk about presenting risks to the business, it's not only security risk, it's the risk of not accomplishing something," he notes. "And what are the trade-offs?"

Lean teams and priorities

Security teams describe themselves as short on people almost universally, and a third of security professionals report their organizations don't have the resources to staff adequately. Two teams carrying the same headcount can deliver very different amounts of work, and the difference rarely shows up in a hiring request. "You can have a lean team as long as you can prioritize the work that has to get done," Asher says. "At some point, if there's 20 things that are priority and that are critical, then you either have to add resources or you have to ask yourself, are each and every single one of these areas the real priority?"

Skill gaps, tooling gaps, and capacity limits are real, and Asher's answer is to name them to the business as delivery constraints with options attached. The decision that follows belongs to the business, since the trade-off between security work and everything else the company wants is a business trade-off. "That doesn't mean you'll get the answer you want or the budget you want," Asher explains. "It just means you've done your job as a security leader in letting the business know, here's where we're at, here's what we need."

Tuning before buying

Asher's audit starts with what the company already owns: the tools already in the stack, the solutions layered on top of them, and the processes connecting both all consume capacity that may not show up as a budget line. "Not everything is about just replacing vendor A, vendor B and being able to do more," says Asher. "A lot of it is have your tools been configured to be able to leverage them at the fullest capacity? Are there any processes that are probably failing that have nothing to do with technology? Do you have the right process for people to submit requests?"

A metrics program feeds the audit directly, since the numbers from the first step point at where the hours are going. Asher expects alert triage to account for a large share of them, and the two remedies he names both work on systems the company has already bought. "If you've tracked the metrics then you might find out that a lot of these are false positives," he notes. "Well, you should be going into your SIEM and tuning down the false positives. Does your SIEM offer any capabilities to automate the lower level alerts?"

Asher's sequence ends where most budget conversations begin. The steps leading up to it run on tools and processes already in place, so a team can produce the record before anyone approves a dollar. "Do all of that before you start asking for more money and show that you've done all of these things to optimize," Asher concludes. "Show it with numbers. Hey, six months ago we were here. Here's the data that shows six months later, after all of these tweaks that we've made, we're here, we have improved, and to make even more improvement now, we need to have XYZ in place."