TL;DR: One of the most common questions I receive is “Who should the CISO report to?”. My answer is “it depends and there is no universally right answer.” However, there are definitely failure modes that need to be avoided if the security program is going to succeed.
We live in a world where companies come in different sizes, shapes, missions, cultures, obligations, etc which means that making broad generalizations about anything is difficult. Security professionals tend to have a very strong feeling about where security should report. However, I would say that, based on my experience, it entirely depends on the organization and the leadership team. Would I recommend the CISO sit as an equal to the rest of the executive leadership team? Absolutely. Are all companies ready for it? The answer is usually not.
I would like to start by first countering the argument that security cannot report to the CTO/CIO because it is a conflict of interests. I was once a firm believer that this was a guaranteed failure mode but I have come to a more nuanced view about this position. Straw-man arguments that it’s the fox guarding the hen house or some other applicable idiom is an easy way of dismissing a nuanced decision.
Security’s effectiveness in an organization isn’t compromised simply by reporting to the CTO/CIO. Rather, security becomes less effective if the relationship is not properly defined. I completely agree with the premise if the CISO is represented by the CTO/CIO or if the CTO/CIO dictates the security budget or if the organization dictates that security is only a technology concern. However, if those risks are properly addressed then the CISO’s position can actually be stronger and more effective under the CTO/CIO because security may be more aligned with the core risks. This alignment can certainly be the case in a software product company but likely far less so in a more sales-oriented or financial services company.
Digging into the failure modes of the CIO/CTO reporting relationship highlights some of the characteristics an organization should look for in their CISO:
- Representation of security by proxy: The CTO/CIO is rarely in a position to represent the breadth and depth of the security program, much less while also representing all of their business priorities. Think of the CTO/CIO presenting for 15 minutes to the board. I would venture to guess about 14 minutes would be spent addressing product development, milestones, metrics, etc; if there is any time left over then a quick security metric may be presented rather than a risk discussion. Furthermore the CIOs visibility across the organization is also usually more limited than the breath that a security team needs to cover.
- Lack of budgetary control: Security must maintain a degree of autonomy and impartiality. In order to accomplish this, security must be the owner of its budget at all times. If the CISO does not have the ability to defend their own budget to the leadership team then their budget will always be at risk of being impacted by the priorities of others. The worst failure mode would be if headcount or budget were taken from security to instead augment staff or invest in other areas. Part of why security is often times put in such odd places in the organization is to protect their budget.
- Pigeonholed security team: Security always runs the risk of being limited as only being a technical function. As we discussed previously, security is interdisciplinary in every way and needs a security leader that can break outside of that mold. Where security reports can dictate the starting point of the security program, and it becomes the CISO’s job to expand that thinking.
Understanding these failure modes makes it a bit clearer as to why it would be easier to end up in one or more of the failure modes under a CTO/CIO than any other reporting structure. Avoiding the organizational pitfalls is the key to success.
All of that being said, security should report into the part of the organization where risk is highest to truly impact the thought process. If the risk is regulatory, then it could make sense for security to report to the CEO or board, and may even be mandated by the regulation. If the risk is product related then being part of the product development lifecycle as a member of the CIO/CTO’s organization may make more sense. If the risk is more people-based then the COO may be a better choice. In the end it does not matter where security reports as long as it maintains the following autonomies:
- Budgetary
- Representation upward, laterally, and downward
- Freedom to work across the organization at all times