This can be an emotive topic for many people. It is one, I’ve found, colored more by dogma than nuance (as it seems with many things these days) and so it is often hard to have a reasoned debate about this. Since I first wrote this post not much has changed except that it seems even more the case that the people who are most adamant in their views on CISO reporting lines are people who have never actually been a CISO, part of a CISO‘s leadership team, nor have ever been part of a Board or executive team who have to deal with such matters. People who are or have been CISOs seem to mostly agree that what really matters is that what is needed is what works best for your organization, culture and security maturity state - not some fixed ideal.
So with that in mind, first, let’s get one thing out of the way: if people think the answer to an organization’s security issues are mostly determined by the reporting line of the CISO, then frankly there are bigger issues at play that need to be dealt with that are driving that fixation. The reality is, like every important concern, security has to be a shared goal - one role can’t carry this alone no matter where it reports.
In my view the issue that confuses matters in all the debates about reporting lines stem from the intermixing of two distinct roles for getting security right.
There is the role of embedding security into all products (technology, business process, services and so on). This is now a profoundly engineering-centric role in most organizations, being that most organizations are now or are becoming predominantly digitized. This role/team needs to be where products are built/maintained so the embedding is efficient (secure products not just security products), and that knowledge is current and security engineers are intimately tied to product mission. In short, this role is in IT / engineering.
There is the role of enterprise risk management. This role/team makes sure that the risk appetite of the organization, as set by executive leadership and the Board, is independently enforced and any variances are handled at a level above where a trade-off is occurring. In many organizations this is the role of a Chief Risk Officer (CRO) or similar and there will exist a team to independently assess and manage the risk appetite of a range of specific risk domains, including security. In short, this role is in the enterprise risk function.
The problem when people debate the CISO position, is that they don’t define the role archetype they are talking about. If it is for independent risk management then a risk/other executive reporting line is better, but if the archetype is for embedding security into product then an IT/Engineering line is likely better. I would argue that these two aspects of the role should be separate and which one you choose to assign the CISO label to is simply a matter of taste, culture and signaling. So if someone says, the CISO should report directly to the Chief Risk Officer, Chief Financial Officer, Chief Operating Officer or even Chief Executive Officer - first ask them do they mean CISO as in the role that integrates security into products or do they mean CISO as in the role that enforces independent risk oversight of the correct security posture. If the answer comes down to it’s a CISO driving engineering of security integration into products and that person reports to the CEO (except in certain types, usually smaller, organizations) then that is not only likely going to not enable the right person to fill a C-suite seat but also it will mean there is a profound lack of integration with the rest of engineering positioned elsewhere in the organization. In reality, organizations (large and small) seem to be coalescing on the structure that they have both roles in some form. One in technology / engineering driving operations, engineering & testing, the other in the risk, finance, or executive office function doing independent monitoring of risk appetite adherence. The first is often labeled CISO. I’ve also seen organizations call the risk role CISO but then find, often quickly, they need a head of product security/security engineering or other form of security team to drive the goal of embedding security into the fabric of the organization and its products.
Sometimes one person has both role archetypes and they resolve this by reporting to the CIO and having a dotted-line report to the Chief Risk Officer, or sometimes vice-versa. Often, they resolve the independence question of an IT / engineering positioning through an independent risk committee to direct the prioritization of funds to security so as to assure IT investment while still keeping the team in IT to ensure appropriate alignment to delivery.
There is a lot of commentary that the CISO and CIO roles are inherently in conflict and result in a lot of tension and difficulty in prioritizing the right security outcomes. This sometimes was the case many years ago but since a CIO‘s role is now as much in the “firing line” for security and other risk events as the CISO in recent years I’ve not found this to be the case. But let’s say it is, and the answer is to split the reporting relationship up so the CISO has a peer relationship or even authority over the CIO then do we all honestly think that will then create the harmony needed for the type of deep architectural collaboration needed such that security is embedded in products effectively. In most circumstances I’ve seen or heard of such separation of conflict into peer organizations actually heightens the animosity. Incidentally, I regularly speak to CIOs about this topic as well as CISOs. The repeated pattern from CIOs is that the majority had CISOs (the engineering archetype) reporting to them or were in the process of making that change. These organizations had decided that the goal of embedding security into everything they do as early possible in the design lifecycle was so critical it had to be a core part of the IT mission and so the CISO was critical to support the CIO in doing that. Many also had independent risk functions to oversee risk appetite, including security. These CIOs felt a deep and personal accountability to get security right and to get it right by also addressing other needs like flexibility, productivity, customer experience and efficiency.
Bottom line: don’t overly focus on the CISO reporting line. Think of which aspects of which roles need to be in which places to best fit the goals, culture and risk appetite of the organization - to serve customers, employees and the world-at-large. Be ok with it evolving and changing as those goals mature and if you do find yourself or others looking to make the CISO reporting line the biggest enterprise security concern then let that be a signal that there’s probably something deeper that needs resolving first. Risk governance, prioritization, transparency and pursuing the goal of secure products not just security products requires deep security and IT collaboration - that’s the goal. The CISO reporting line or other organization matters should fit with that goal in any organization - not be the goal itself.