Modeling and Sizing Security Orgs

Part 1 (Probably)

One of the hardest things for leaders in the Security space is justifying team sizes and budget. So, I thought I’d share my (~500 word) perspective on this. As a preface to everything I’m about to share: My tenure in security leadership is limited to the relatively narrow space of “Tech”. I’m certain my insights can be useful in other sectors, but so far my experiences have been limited to B2B and B2C tech heavy business. If you want to apply this to finance or manufacturing - your mileage may vary. 

If you do, and it works - you’re welcome for my genius. 

If you do, and it doesn’t work out - I warned you.

Team Size

A rule of thumb I’ve used for many years is: “Security should be 3% - 5% of total engineering size.” 

Obviously this guidance has its limits. For Start-Ups, everyone starts with a “first security hire”, generally someone that has enough experience they can do a little of everything. But, you’ll want to wait to build a full-time security team until you’re between 150-300 people. Depending on your business model, industry sector, and funding level, you might decide to invest early and fund a security team before. If your organization is primarily focused on Enterprise Sales or Sales to governments and other regulated industries, you’re going to lean into Security early. If you sell Dog Toys, you can wait (maybe spend the extra time sending product samples to my dog). 

Well established organizations with well sized security organizations benefit from spending less time thinking about what they should build and when - and more time thinking about what business drivers they use to drive decisions about either growing or pulling back in certain areas.

Drivers of Scale

Let’s talk about some factors we need to consider that will drive your team size toward the higher or lower end of the 3% - 5% rule of thumb.

Industry Type

This is probably the biggest driver for how you size your team. Because the Industry your organization is focused on guides your risk tolerance, drives regulatory obligations, and shapes your customers expectations of your security program. Sure, most of us work in a sector where lives aren’t on the line. But, for example, If you’re in healthcare or the defense industry it’s a whole different calculus. The decisions you make are not just about the impact on margin or revenue. Similarly, if you work in a financial services organization you have very few “do-overs” available to you and MANY regulatory obligations.

Not only are regulated entities going to need to meet a higher bar from a compliance perspective, they're going to need specialized sales enablement teams that can manage nuanced customer questions. I like to call this function "Customer Security" (more on this in another post). When regulators dictate security requirements, they’re rarely proscriptive enough to easily implement, and even when clear requirements exist its never what a skilled technologist would choose. The overhead of meeting those requirements will likely require more people than an otherwise “optimal” security program.

Geographic Location

Location, Location, Location: Not just a strategy for Real Estate success. The locality and jurisdiction of your organization and/or where it conducts business is another great indicator of how (and when) you should build your security organization. Australia, India, and the US all have differing cybersecurity disclosure laws. China has VERY specific and unique cybersecurity rules for orgs that choose to do business there. All of these will affect the size, shape, and timing of your security program well before you even start doing basic detection work.

Revenue, Deal, and Customer Size

Some regulatory obligations kick in when your business crosses a certain threshold. The more successful your business, the more there is to protect. But, even before your organization is a run-away success, at a certain deal size, your customers expect evidence of a high level of maturity in your security program (SOC2, ISO 27k, etc). Similarly, when you sell to large enterprise customers or more mature organizations, regardless of the deal size, you’ll frequently find yourself on the business end of a slow moving inflexible third party risk management process. You can do a lot of things to lessen the burden of this over time, but the bottom line is that it takes people (with a diverse set of specialized skills) to manage this process and meet your customer and regulatory expectations.

Organization + Technical Team Size

I want to be clear, employees are not the enemy and your co-workers are not an obstacle to be overcome by the security team. Now, that being said: the reality is, the more humans you add to the equation, the more human error you'll encounter. It doesn’t matter whether your fellow humans are writing code, selling products, or cleaning bathrooms. The more people you have clicking links, the more people you have making bugs, the more people you have interacting with customers, the more your security team needs to do. The model for your team size needs to adjust to this reality. This means as the org grows your org needs to grow (non-linearly) to accommodate it (and vice versa).

In Conclusion

This is where I say organizational structure varies - wildly - in security. The way your security department is structured will differ even between companies of similar sizes and industries. My advice is to start with the 3-5% rule and adjust (up or down) accordingly. Feel free to use the insights here to drive the conversation with your leadership about “why” your org should be the size it is / needs to be.

Turns out there’s a lot to talk about here. We haven’t even covered how to organize your team, what scopes /teams you might want to define versus functions on those teams. What your overall boundaries on responsibility might be for security, or how you might work in Trust, Safety, Privacy and other security adjacent work. So, keep an eye out for more on this topic. And, as always, if you have a topic you’d like me to cover, put it in the comments.