These are my thoughts on the different phases that a Security team may go through from inception to a mature state. My experience range from teams that are a few years in and less than 10 people to 50+ people. I have been one of the founding Security engineers for a Security program. I’ve been a part of large and small teams in different stages of a Security team’s journey. I’ve also done a rotation on a Compliance team for 6 months and all the Security team’s I’ve been a part of also owned IT Security.
Early, growth, and late stage can be used to describe a Security team, but which metric you use to measure that or determine the general stage can vary. For example, you can use the total number of employees, size of the Security team, financial factors (ie. revenue), etc.
I’ve also found that even though a company may be public, a Security team may still be scaling because organizations are usually not ready to really invest in their Internal Security until they’ve reached certain financial stability. This tends to happen around Series C or D and after they’ve passed 50 - 70 mil in revenue. Security teams in companies that have just IPO-d may still be in the early or scaling stages, and not yet in the iterating and maturing phase.
For the purpose of this, we can generally say the below. The size of the Security team is the biggest factor that shows how much the company is investing in building this function. These are rough outlines and are not hard and fast definitions:
Early:
0 - 10 Security team members
Typically Series A - C, 0 - 50 mil revenue, 0 - 100 employees
Introducing and performing aspects of a Security program
Growth:
10 - approx. 13 Security team members
Can be Series C - D, 50 - 60 mil revenue, 100 - 500 employees
Some aspects of a Security program are managed, others are reactionary or individual events
Late stage:
13+ Security team members
Can be Series D, 60+ mil in revenue, 500+ employees
Security program has now evolved to define and mature core aspects
A map of Security program stages is described in this spreadsheet. In this spreadsheet, I am focusing on the Security programs that are often considered a core function. This not meant to be an exhaustive list. This spreadsheet can be used to evaluate where your Security program lands or if you are a first time CSO, this can help figure out how to grow in the different areas. A lot of this will be dependent on your organizations culture, risk tolerance, risk appetite, industry, etc.
There are factors that cannot be included in here in a meaningful or effective way. A different risk profile will mean that you may want to invest or build up a certain function more than something else.
Ultimately, you were hired to make judgement calls and hopefully this helps in those moments. As a CSO you assume responsibility and accountability for how the Security program develops and becomes a true partner for risk management. However, there are things that are out of your control (overall growth of the company, investment from the exec team, etc), so recite the Serenity prayer and continue to focus on what you can do.