This is the second part of a look at reporting lines in organizations. You can click here to read about when Security reports directly to the CEO.
Navigating the complex security landscape in the bustling tech hub of Silicon Slopes, particularly within startup ecosystems, is akin to charting unexplored terrain. Having spent considerable time in the heart of Utah’s tech scene, I’ve observed a prevailing trend that deserves our collective scrutiny – the elusive realm where security finds its home within an organization.
In the intricate dance of startup dynamics, decisions about reporting structures often hinge on the intuitive guesses of founders and co-founders.
Picture this: the visionary CTO or the tech-savvy CIO leading the charge, driven by their vast experience. But is this traditional approach truly aligned with the evolving nature of cybersecurity?
When one doesn’t understand what security does, it’s easy to assume it’s all the technical stuff, so it should go with the technical team. In startups, this often means the Engineering team responsible for building your widget(s), usually led by the CTO (Chief Technology Officer) or the CIO (Chief Information Officer). This was the most common place for security to fall in the past, but this has been shifting. For a long time, security has been seen as an IT problem, and it just isn’t.
Join me in exploring the nuances of this pivotal juncture where security, technology, and organizational strategy converge.
When is This Reporting Line a Good Thing?
The big advantage to this reporting line is the leadership team certainly understands what’s happening technically and typically already has the ear of the board to make changes. It’s also a good relationship because the CIO/CTO and their departments are usually responsible for building technical systems and awareness around those, and building business relationships with all the various departments.
What is the Problem With This Reporting Line?
The clear and obvious problem with this reporting structure is a conflict of interest. These teams are responsible for bringing the product to market, which always needs to be faster. If there’s a vulnerability or security issue with the product, it’s very easy for the CTO/CIO to hear the drum of Go-To-Market much louder than the whine of the security team.
If the perception is that implementation of the security controls may take more time or money to implement, the security considerations may not be provided equal weight.
Todd Fitzgerald, CISO Compass
Another source of conflict of interest is the drive to maintain 24/7 uptime. The IT department will be very unhappy to take a system down for a vulnerability patching update.
How do you think a CTO will respond when the security team performs a need-to-know review of access controls and determines that the IT or Engineering teams have privileges that are too high? Will risk mitigation and reduction win the day, or will speed and convenience take the prize?
What if IT Doesn’t Deal With Something We Have to Do?
Some of the security leadership concerns will fall outside of IT. They may require the security team to create additional business relationships, which the CIO/CTO must consider but likely won’t. I’m talking about Physical Security, Contracts, Personnel Security, and Privacy.
Fundamental Differences in Perspective
In Security, we often think about threats and prepare for incidents that are foreign ideas to IT and Engineering. It’s the mindset of these teams to take the path of least resistance to attain their goals that the Bad Guys™ are counting on. When one team looks at an item and sees what’s wrong and needs fixing, and the other team looks at the same item and says it’s achieving the objectives: push it live, wherein is the objectivity found to make a business decision? This is going to be a hard challenge for a CTO/CIO if they’re truly trying to serve the needs of their direct reports.
This blog post has been interesting to write, as I’m currently interviewing with two organizations where I would be a Director or VP, and reporting to the CTO. I’ve had this reporting line before, and it was difficult, for all the reasons I’ve listed above. There are things happening with the SEC and requirements for the CISO to have a direct line to senior management, but we don’t see a lot of SEC-beholden startups around here. This is one of my problems with Silicon Slopes (lack of maturity as a cultural and corporate problem across the business landscape), but that’s a gripe for another blog post.
How Are YOU Navigating This Reporting Line?
If Security is going to report to the CIO/CTO departments, security leadership (CISO, VP, or Director) should not be any further down than a direct report. The farther the security leadership is from the CEO/Board, the harder it is to make change happen.
If you have or currently report to the CTO or CIO, what challenges are you facing, and how do you deal with them effectively? What are you doing in your org? Let’s discuss.
0 thoughts on “Executive Perspectives Pt 2: Reporting to Information Technology”