Having read many people’s strong-held views on this topic I thought I’d add to the mix. Despite a lot of people now inevitably thinking “is this the hill you want to die on? - here we go…...
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 in all the debates about reporting 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, they don’t define the role archetype. If it is for independent risk management then a risk/other exec 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.
Organizations (large & small) seem to be coalescing on the structure that they have both roles. One in tech driving operations, engineering & testing, the other in the risk 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.
Incidentally, I spoke at an event recently in front a number of CIOs from large organizations. 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 (ambient control) 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 had independent risk functions to oversee risk appetite, including security. These CIOs felt a deep & 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.
Comments