Should the CISO report to the CIO or the CEO?

Either can work, and either can fail. What decides it is whether three things are true regardless of the box on the chart: the CISO can brief the board and the audit committee directly, without the message passing through someone whose projects the message might slow; the CISO has written authority to stop or delay work that creates unacceptable risk; and the security budget is ring-fenced so it can't be reallocated to an IT overrun without a conversation at the top. If those hold, reporting to the CIO is fine and often practical. If they don't, reporting to the CEO is a title, not a fix.

The honest case for each

Reporting to the CIO keeps security close to the systems it protects. Patching, identity, cloud configuration, and network design are IT decisions, and a CISO inside that structure can influence them daily rather than by escalation. The weakness is the conflict of interest: the CIO is measured on delivery and uptime, and security findings slow both. A CIO who filters the CISO's board message, consciously or not, is the commonest reason this structure fails.

Reporting to the CEO (or COO, or general counsel) gives the CISO independence and a seat where business decisions are made. The weakness is distance: a CISO two levels above the engineering teams can end up writing policy that nobody implements, and a CEO with twelve direct reports may give security twenty minutes a quarter. Independence without engagement produces a well-documented programme that doesn't change anything.

What the oversight guidance actually asks for

Board guidance doesn't prescribe a reporting line. It prescribes access. NACD's handbook tells directors to establish oversight structures and ensure the board has access to cybersecurity expertise, which in practice means the CISO sees the board directly and the board has somewhere independent to go with questions (National Association of Corporate Directors & Internet Security Alliance, 2026). New York's financial regulation requires the CISO to report in writing to the board at least annually on the programme and its material risks, and that report is the CISO's, not the CIO's (New York State Department of Financial Services, n.d.). The SEC requires public companies to describe which management positions are responsible for cyber risk and how they report to the board (U.S. Securities and Exchange Commission, 2023). Under any of these, a CISO who only ever reaches the board through the CIO's slides is a disclosure problem waiting to happen.

The three things to secure, whichever line you pick

1. A direct path to the board. Written into the committee charter: the CISO briefs the audit or risk committee at least annually and can request time with the chair. Not "may be invited."

2. Authority to stop work. A documented right to halt a deployment, block a vendor, or require a fix before go-live when a defined risk threshold is crossed, with an escalation path if the business disagrees. Without this, the CISO is an adviser, and advisers get overruled quietly.

3. A protected budget. Security spend visible as its own line, approved at a level above the CIO, so that an IT overrun in Q3 doesn't absorb the detection project. NIST's framework treats resourcing as a governance outcome for exactly this reason: if leadership can't see what security is funded, it can't own the risk of what isn't (Pascoe et al., 2024).

The signal that the structure is wrong

Watch what happens to bad news. If the board hears about a serious finding only after it's been fixed, or only in a sanitised form, or not at all, the reporting line is filtering, whatever the chart says. The remedy isn't always a reorganisation. Often it's a charter amendment and a conversation with the CIO about what the CISO is expected to say in the room.

What I'd do next

Check the three conditions against your current structure in writing. If any one is missing, fix that one; moving the box is a last resort and takes a year to settle. If you want an outside view on whether your structure would hold up under a regulator's or an insurer's questions, request a briefing. On what the board should receive from whoever reports to it, see What a Cybersecurity Board Report Should Actually Answer.