Who Should the CISO Report To? CEO vs CIO Governance
Who Who should the CISO report to? Usually I hear, “They should report to the CIO; that’s where security sits.” Not so much anymore. That’s where security used to sit, back when a breach meant a defaced homepage and not a nine-figure regulatory fine. Cyber risk stopped being an IT problem a while ago, but org charts are still catching up.
So who should the CISO report to? CEO, CRO, Legal, or the CIO they’re supposedly there to keep in check? Let’s go through it properly, because the answer actually matters more than most governance debates I get pulled into.
The Problem With Reporting to the CIO
For a long time, tucking the CISO under the CIO made a kind of sense. Security needed to be woven into networks, databases, and the software stack, and the CIO owned all of that. Fine, in theory.
Here’s the conflict. A CIO is measured on speed and uptime: ship the feature, keep the lights on, hit the IT budget. A CISO’s actual job is to be the person who says “wait, we need to check this first.” One of these roles is built to move fast. The other is built to slow things down (long enough to verify they’re safe). Put one in charge of the other’s bonus and performance review, and you’ve built the conflict directly into the reporting line.
It gets worse in practice. When a CISO flags a genuinely serious architecture vulnerability, a CIO under deadline pressure has every incentive to soften how that gets described to the board, just out of self-preservation. And then there’s the audit problem: the CISO is meant to audit and enforce security policy over systems that the CIO’s own team built and runs. Asking someone to investigate their own boss’s department independently is a structural joke. It doesn’t matter how much integrity the individual has – individual integrity shouldn’t be necessary to make a control function work.
And yet a good third of organisations still run this exact structure. I’m not saying every one of them is broken. I’m saying regulators and boards are increasingly unwilling to take that bet.
Who Should the CISO Report to: The Four Reporting Lines
There isn’t one universally correct answer here. I’ve placed CISOs into all four of the structures below, and each one solves a different problem, which means each one also creates a different one.
Reporting to the CEO
This is the model I’d point most fintechs, banks, defence contractors, and cloud-native businesses toward, especially if the organisation is mid-overhaul on its cyber governance. Sitting the CISO on the executive leadership team next to the CFO and CRO sends a clear signal that security isn’t a cost centre being humoured; it’s core to the business.
The upside is real: the CISO gets unfiltered access to the CEO and the board, complete independence from IT execution, and enough political weight to actually enforce policy across business units that would otherwise ignore them.
The downside is just as real. CEOs are stretched across enormous portfolios, and if your CISO can’t translate a technical risk into a financial one in about ninety seconds, that direct line stops being useful; it becomes a meeting nobody prepares properly for. I’ve also seen this model create a “them versus us” dynamic with IT if the CISO doesn’t actively work at the relationship.
Reporting to the CRO or COO
This is where I’d steer heavily regulated players, financial services, insurance, super funds, anywhere with a genuinely mature risk and governance function already in place. Here, cyber risk gets treated as one line item inside enterprise risk management, sitting next to financial risk, operational risk, legal exposure.
It’s a natural fit, because the CRO’s whole function already exists to quantify and report risk up to the Audit & Risk Committee, and it keeps the CISO’s evaluation work separate from IT’s delivery work. The trade-off is bureaucracy: risk committees don’t always move at the speed an active incident demands, and I’ve watched genuinely urgent technical responses get stuck in a governance queue that was built for slower-moving risks.
Reporting to General Counsel
I’d recommend this one specifically for organisations facing serious litigation exposure, strict privacy obligations under GDPR, APRA, or Singapore’s PDPA, or an active regulatory investigation. The upside is that legal privilege and incident investigation reports can be protected under legal professional privilege, which matters enormously once lawyers are involved.
It also tends to lock down data privacy and vendor liability obligations tightly. But legal leaders, in my experience, usually don’t have the technical depth to properly evaluate architecture trade-offs or the security implications of an MLOps pipeline, and this model has a real risk of sliding into a tick-the-box compliance culture instead of active operational defence.
Reporting to the CIO or CTO, With Board Safeguards
This is the least governance-pure option on the list. But it can genuinely work for mid-market firms or lower-risk businesses where security and IT execution need to move in lockstep, and where the overhead of a fully separate function isn’t proportionate to the risk. It keeps tooling coordinated and avoids duplicated spend. The risk, obviously, is that vulnerabilities get quietly deprioritised to protect a launch date.
If your board insists on this structure and plenty do, usually for cost reasons, there’s one safeguard I consider completely non-negotiable: a direct, dotted-line reporting channel from the CISO straight to the Board Audit & Risk Committee, with explicit authority to raise issues to directors without needing the CIO’s sign-off first. Without that safeguard, this model isn’t a compromise. It’s just the old conflict of interest with better branding.
Regulators Have Stopped Treating This as an Internal Preference
This isn’t purely an org-design debate anymore; regulators have opinions, and they’re written into law. The SEC’s cyber disclosure rules require public companies to spell out board oversight of cyber risk and how executive management actually assesses and manages material threats. Australia’s APRA CPS 230 and CPS 234 demand explicit operational risk governance and independent testing of security controls at regulated financial institutions. Singapore’s MAS Technology Risk Management framework enforces board-level oversight of cyber hygiene and vendor supply chain risk.
The message underneath all three, if you strip out the legal language, is the same: a board can no longer claim it didn’t know, just because the information got filtered on the way up.
A Rough Guide
If you’re running a high-digital-risk business, fintech, or critical infrastructure- put the CISO on a direct line to the CEO. If you’re in heavily regulated financial services or insurance with a real GRC function already running, the CRO is usually the better home. Mid-market or early scaleup under roughly 200 people, and the CIO or COO can work, provided the board keeps direct access open. And if you’re dealing with active litigation or sit on a high-privacy platform, General Counsel is worth serious consideration.
Conclusion
There’s no single correct box on the org chart, but there’s one principle that stays true: the CISO needs independence, real executive authority, and a line to the board that nobody else gets to monitor or edit on the way through. Whichever reporting line you choose, if the CISO can’t quantify risk in dollar terms, push back on operational shortcuts, and get heard at the top without a filter, the reporting structure on paper doesn’t matter.
Getting this right starts with the person rather than the org chart. Whether you’re standing up an independent security function for the first time, hiring a permanent CISO, or bringing in an interim security lead to satisfy a regulatory deadline, it helps enormously to have access to security executives who’ve actually operated inside these structures before.
