Why Every Cybersecurity Leader Needs Financial Literacy

I stumbled into financial literacy quite by accident while working in cybersecurity, and it's been an unexpected ally ever since.

While cybersecurity often fixates on threats, the latest product category acronyms, and who is acquiring who, grasping finance is an overlooked key to success in making security teams more effective business partners.

People are often surprised when I tell them that I (along with many others), in technical fields like cybersecurity, have a decent grasp of finance fundamentals. And I’m not talking about cyber risk quantification here, either. I have strong opinions about that field that I won’t cover in this piece. No, I’m talking about the financial and business languages that other teams outside of cyber use to get work done.

It's not something we often talk about, but I learned quite a bit about finance when working in a very technical security function at a large company.

The organizational setup was unlike anything I'd seen before or since in that the security functions were split out across multiple other organizations by domain. In this unique setup, my security engineering team straddled the CISO, IT Engineering, and IT Operations organizations. We acted as an internal service provider, requiring us to learn the business language, norms, and financial terms of each group to get work done effectively.

My team, the security engineering team, had the unique position of being called upon by all three groups to evaluate, design, and advise on security solutions. The CISO and CTO were peers, both reporting to the Chief Information Officer. We also had the freedom to create new ideas to secure the company (which was the most fun!).

The security engineering team was another engineering team within the broader IT group, and my team had to fall closely in line with the rest of the IT norms and expectations. As a result, it was an engineering team first that just so happened to have worked on security technologies.

This meant we were an engineering team first, with a focus on security technologies. Our job was to act as a "service provider" to the CISO organization, our main but not only "customer." We had to learn the business language, norms, and expectations of several different groups to get work done.

We had to think practically about problem-solving and budget allocation in a different way than I've seen other cybersecurity programs be run. Budgetary resources weren't infinite (as is often the norm at large, heavily regulated companies), and neither was our attention. So we began to learn and use financial concepts like Total Cost of Ownership (TCO), CapEx, OpEx, payback period, and run rate in our discussions about which projects to pursue and in what order.

It was the one and only organization I worked at where we actively reduced security spend while increasing security capabilities, attack coverage, and compliance. When it came time to take on a new body of work or bring in a new set of capabilities, it was an easier conversation to have with all of the parties involved.

We learned how to frame the business case for approval from the business sponsors (CISO organization), the financial case to the project management office, and the technological case to the enterprise architecture group.

Here’s exactly how we did it:

We learned that the enterprise architecture group really cared about the TCO of any technology in the company. Thinking about TCO requires you to think not only about just buying something new but also about the internal costs and time required to deploy, operate, and even retire the technology when it was time to move on to the latest and greatest thing. It’s

Balancing innovation, making sure technology teams considered operational efficiency, and weaving the long-term value of technology into the enterprise were at the core of what this team cared about.

An unspoken truth of the tech industry: Buying technology is easy; making it live up to its promises takes relentless time, focus, and effort.

After getting squared away with the enterprise architecture team, we had alignment that:

1. The technology even made sense to bring into the organization.

2. We knew how we would acquire and implement the technology.

3. We had clearly accounted for the cost of implementing and running the new technology.

From here, we could more easily move to the financial aspect of the project management front. Now that we had the ability to talk about how the project would work from a financial aspect in terms of a cost capitalization standpoint.

Operating Expenses (OpEx) and Capital Expenses (CapEx) are two of the main levers that project managers and finance teams use to control costs for each project and drive efficiency.

• OpEx = The recurring costs needed to keep the business running. This includes employee salaries (typically), recurring licenses, subscription models, and utility bills to keep places running.

• CapEx = The longer-term investments in physical or intangible assets, like new servers, new software licenses, or new office buildings.

Companies have to use a mixture of both of these levers on any given project so they can see if it makes financial sense to invest in at that given time.

For most companies, there is no static rule for which expense categorization is preferred. Much of this comes down to the timing of the year (especially if you are at a publicly traded company with quarterly result expectations), the other technology initiatives going on at the same time, resource constraints, and the general make-up of favoring full-time employees vs. contractors.

You don’t have to know all the ins and outs of how this is all decided at your company, but you need to know which set of circumstances are in favor when you go up to pitch your project.

Having the right mix really matters, and having close connections with your financial counterparts can let you know ahead of time how best to frame up a new project. This can also include asking for new full-time employees (FTE) or contractors as a part of the overall project ask.

With the financial and architectural aspects sorted out, the business case basically writes itself. You’ve got alignment, you’ve got a plan to pay for it, and you know how you’ll get to the value creation part. Approaching new work in those different stakeholder purviews made getting our projects approved and funded a layup (easy bucket 🏀).

Getting those different bodies aligned using the language they understood paved the way for our engineering team to do the fun work of solving security problems.

Understanding each group's business and financial language unlocked new efficiencies and collaboration opportunities for the security engineering team.

Today, more security practitioners and leaders are leaning into the business side, wanting to be taken seriously in their roles. It all starts with communicating and listening to how the business speaks and thinks.

As George Bernard Shaw said,

Learning the jargon that made the company tick enabled genuine communication and collaboration.

It's all about learning the art of organizational communication and understanding how to work with it instead of resisting or ignoring it. I carry the lessons I learned in that role into every job I've had since.

The main takeaway?

Fluently speaking the language of different business functions enables security teams to drive impact faster and better. Learning financial literacy and what it means at your company is a great place to start for security practitioners who want to be seen as business enablers first.