I was recently asked the question, “Where does Security belong in an organization?”
It is an intriguing question, and one that I think about quite often. Currently most CSOs report to the CIO or CTO. In a few, rare cases, they report to the Chief Risk Officer (CRO) or Legal. I hear security professionals expressing the belief that the CSO should report directly to the CEO in order to make their voices heard and make security a priority in the organization.
Where does the CSOs role come from?
Decades ago, IT security consisted of rudimentary tools. Firewalls were one of the first bastions and “network security” became synonymous with “security”. As attacks evolved, security broadened, as did the tooling to protect against them. At the same time breaches also became more public, costly, and embarrassing. Security professionals began clamoring for organizations to take security more seriously. There was a strong belief that security risks were lost on managers and executives.
With this perceived disconnect, various organizations attempted to step in and remedy the problem. Government regulation (Sarbanes-Oxley, banking regulations), industry regulation (PCI, ISO 27001, SOC 2) appeared in an effort to mandate security risk mitigation.
In the midst of these movements, security professionals began to clamor that they “need a seat at the table” – a reference to needing a direct audience with the CEO and board-of-directors. While some regulations mandated the creation of “Chief Security Officers” and “Chief Privacy Officers” with accountability, none have (yet) stated a mandatory reporting structure.
It is in this landscape that we pose the question, where should the CSO report in an organization. I would put forward that where the CSO should report may not seem obvious for some reasons not often considered.
“Risk and Opportunity are two sides of the same coin.”
Security’s role is to help the organization realize the opportunity its pursuing by not falling into traps that can destroy the opportunity. If you think about how security operates, you might think, at face value, the preceding statement fits with what you think security does today. However, there is some subtlety in the statement that might be overlooked. Consider the word opportunity, and how the goal of security is “…to help the organization realize the opportunity…”. How often have you heard a security team say, “…over my dead body…”, “…that will never happen…” or something similar that reflects an outright resistance to a project, a change, or a technology. I’ve heard it said about Online Internet Banking in early 2000s. I heard it said about mobile payments in the early 2010s. My point isn’t that opportunities proceed despite security, but rather that they have proceeded by solving for security. Each of those technologies had detractors who looked for reasons it shouldn’t work, rather than creating solutions that made it possible for it to work.
You might ask what this has to do with where a CSO and their organization reports. I’ll give you a very simple answer – the CSO and their security group should exist in the structure the enables them to best collaborate with groups generating opportunities. Security should be just as embedded in building solutions the lead to opportunities as everyone else in the organization.
It is all about how to contribute
My view of where a CSO and their organization exists has much more to do with how they can collaborate and contribute the most in new initiatives. In my view, the CSO is there to contribute and collaborate on building success for an opportunity by understanding risk and how to mitigate it.
Based on that view, a CSO should:
- Ensure that new opportunities can resist the most likely threats that can disrupt them by examining and measuring the probabilities of threats and their impact, communicating that information to those building the opportunity, and working collaboratively to devise mitigation for those risks most likely to disrupt the opportunity. (If you say they must resist all threats, then we need to have a separate discussion on how every executive and manager decides to pursue an opportunity with no absolute certainty that the opportunity will succeed.)
- Ensure that security, regulatory, and compliance regimens can be met by creating solutions that meet the requirements of the regimens in ways that allow the opportunity to proceed. Help the organization design, build, and operate the opportunities in a way that meets the security, regulatory, and compliance regimens.
- Focus on early collaboration, early engagement, design, early testing, and early feedback. When the focus is made earlier in developing the opportunity, efficiency increases, and the flow of work becomes more rapid.
There is a question to all of this – who enforces “the rules” when a team, or opportunity does not follow the security, regulatory, or compliance regimens. In my opinion, that is up to the executive team, and board of directors. The CSOs role is to provide guidance, and insight, not to enforce or punish.
The CSO should:
- Measure compliance, identify security incidents and risks that can disrupt the opportunity, and refine designs with a focus on making the opportunity a success, and ensuring it stays that way.
The CSO should not:
- Play enforcer. This conflates the roles of auditor and of guide. Enforcement is an after-the-fact activity that too often occurs when evaluating a production environment, or a solution that is well on its way. Guidance occurs, and effective collaboration occurs when there is fast, early feedback to teams that are building the opportunities.
When security thinks of itself as an audit or enforcement function it separates itself from those creating opportunity. It creates an “us-vs-them” dynamic that is counter to building. What is needed is an “Us” approach that helps to create solutions that are secure, that meet regulatory and compliance regimens, and protect the opportunity from risks that can disrupt.
So where should the CSO report?
At the end of the day, where the CSO reports should be a reflection of where she contributes to the opportunities of the organization, rather than where she can wield the largest stick of punishment and enforcement.
I do not mind if the CSO exists outside the IT department, but only if they collaborate and contribute in opportunities and initiatives outside of IT. If the CSO is closer to a Chief Risk Officer and works with every business unit to identify, measure, and treat their risks – whether its identifying criteria for accepting or disqualifying job applicants, measuring impact of workplace safety, or devising strategies to ensure continuous availability of business operations. A CRO should report at an executive level, but care should be taken not to simply conflate the role of CSO and CRO. The role and responsibilities of a CRO within a financial services organization is much broader than the skills of most CSOs.
If the CSO is only focused on IT issues, then that CSO should remain within the IT organization, and report to the CIO. Their role is to identify and prioritize security risks need to be addressed for the sake of the success of the opportunity and collaborate with the rest of the organization on the design, building, and implementation of mitigations against these risks.
CSOs should not lose sight of their role, or that they are one of many parts to making opportunities in an organization. Security issues are only one of many risks that can make an opportunity fail! While breaches can cause losses, delayed projects cause losses in sunk costs and lost opportunities. This should by no means diminishes the role of the CSO as their work helps an opportunity succeed as much as any other part of the organization. But let’s not inflate the importance of security over the need for an organization to take risks, experiment, and pursue new opportunities. For the CSO, that should be an opportunity to help the organization take these chances in ways that balance risk and opportunity.
And if you really want me to give a hard opinion, I do not believe it is necessary for a CSO to report to the CEO. My view is that a CSO is an informer, a designer, and a collaborator. They can communicate to a CEO, but they are not the sole mouthpiece of risk and enforcement.
