Somewhere in most reorgs there is a slide that moves one box under another and calls it tidying up. The security leader who reported to the COO, or straight to the chief executive, now reports to the CIO. Sometimes the reverse. It is presented as efficiency: fewer direct reports for a busy CEO, a cleaner technology stack under one leader, a line that makes the org chart symmetrical. Nobody frames it as a change to the company's risk posture. It is exactly that.
I run security and DevOps for a fintech that serves more than 1,500 financial institutions, and I spend real time on the other side of the table from a board. From that seat one thing has become obvious. Where the security leader sits on the org chart is not an administrative detail. It is a control. It encodes who can say no, to whom, and how far bad news has to travel before it reaches someone accountable for it.
Get that line wrong and you have not saved the chief executive a direct report. You have quietly installed a conflict of interest and called it convenience.
The reporting line is a control, not an accident of the org chart
Controls are the things that change behavior under pressure. A reporting line is one of the strongest you have, because it decides whose incentives the security function inherits. The person a security leader reports to sets that leader's objectives, writes the review, and approves the budget. Escalate a problem that embarrasses your boss and you are escalating through the exact person the news is about. Under normal conditions that tension is invisible. Under pressure — a slipping launch, a breach in progress, a control that would delay revenue — it decides what gets said and what gets softened.
So the question a board should ask is not "who does the CISO report to" as a matter of hierarchy. It is sharper than that. When the interests of speed and safety collide, whose interests does the structure make the security leader serve? Answer that honestly and you have described a control. Leave it to whoever is redrawing the org chart this quarter and you have left a control to chance.
Reporting into the CIO buys tidiness and sells independence
The most common structure — the CISO reporting to the CIO — is also the one that most reliably creates the conflict. Not because CIOs are careless about security. Because of what the CIO is measured on. The CIO owns delivery, uptime, and the technology budget. The security leader's job is frequently to slow delivery down, to flag the thing that would extend an outage window, to spend money that produces no feature. Put the second function inside the first and you have asked one leader to referee a game they are also playing.
Governance has a name for this. The Institute of Internal Auditors' Three Lines Model separates the people who own and run risk from the people who provide independent oversight of it. A security function buried inside IT operations blurs that boundary: the same organization builds the systems, runs the systems, and attests that the systems are safe. Bank examiners have been explicit about the problem for years — the FFIEC's guidance recommends that the information security function be independent of IT operations, precisely so the person raising the risk does not report to the person whose deadline the risk threatens.
When I look at a CISO-under-CIO structure I am not looking for malice. I am looking for the specific conflicts the line encodes:
- The veto sits inside the thing it is meant to check. A security objection to a launch becomes an internal disagreement the CIO resolves, not an independent signal the business receives.
- Bad news is filtered by the person it reflects on. An incident rooted in an operational shortcut travels upward through the owner of that shortcut. The incentive to reframe is structural, not personal.
- The budget tradeoff is settled in private. Security spend competes with delivery spend inside one envelope, and the business never sees the tradeoff it is actually making.
- Independence rides on one relationship. A strong CIO who values security can make it work — until that CIO leaves, and the structure reverts to what it was always going to be.
None of these require anyone to behave badly. That is the point. A control you can only trust when everyone is well-intentioned is not a control. It is a hope.
CEO reporting is a design choice, not a trophy
The counter-move — have the CISO report to the chief executive — has been rising for a decade. Recurring surveys of security leaders still put CEO reporting in the minority; most CISOs continue to report into the CIO or CTO, though the share reporting higher keeps climbing. Inside the security community the CEO line is often treated as a status symbol, proof the function finally got its seat.
I would drop the trophy framing entirely. Reporting to the CEO is not a reward. It is a design choice with its own costs. It buys genuine independence — the security leader's veto is no longer adjudicated by the person whose deadline it threatens, and bad news reaches an accountable executive without a filter. It costs CEO attention, which is the scarcest resource in the company, and it can strand the security leader from the engineering context that makes the role effective. A CISO who reports to the CEO but cannot get an hour with the head of platform has traded one problem for another.
So the honest answer is that there is no universally correct box. There is a correct question: does the structure give the security leader enough independence to be believed and enough proximity to be effective? Both, or you have optimized one at the expense of the other. That tradeoff is a governance judgment. It should be made deliberately, revisited when the business changes, and owned by someone whose job is oversight — which is the part most companies skip.
Regulators already treat this as a board-level decision
Here is what surprises executives who think of the reporting line as an internal HR matter. The regulators who touch your business have already decided it is a board-level one. They did not mandate a specific box on the org chart. They did something more pointed — they made the board accountable for the oversight the reporting line is supposed to enable.
The pattern is consistent across regimes. Under the Gramm-Leach-Bliley Safeguards Rule, the qualified individual responsible for the information security program must report in writing, at least annually, to the board or an equivalent governing body. New York's DFS cybersecurity regulation requires a designated CISO who reports in writing to the senior governing body, and requires that body to have the expertise to exercise oversight. The SEC's disclosure rules push further into the boardroom: registrants must describe the board's oversight of cybersecurity risk and management's role, and disclose a material incident within four business days of judging it material. In Europe, DORA places ultimate responsibility for operational-resilience risk on the management body itself.
Read those together and the message is unambiguous. The reporting line exists so that a specific, accountable governing body hears the truth about risk directly enough to act on it. If the structure routes that truth through the very executive it might implicate, the board has not delegated oversight — it has outsourced it to a conflict. The board owns the outcome the reporting line is meant to produce. So the board should own the reporting line.
Personal liability changed the math
There is a newer reason the structure deserves board attention, and it is not abstract. The security leader now carries personal legal exposure in a way that was rare a few years ago. The SEC's 2023 enforcement action naming a public software company's CISO personally — much of which a court later pared back — put every security leader on notice that their own signature and their own disclosures can be litigated. Earlier, a former CISO at a large technology company was criminally convicted, as widely reported, for his role in concealing a breach from regulators.
Sit with what that does to a reporting line. You now have an executive who can be personally sanctioned for failing to escalate, reporting to someone whose incentive, in the worst moment, may be to keep the news contained. That is not a hypothetical tension. It is close to the fact pattern in the cases people cite. A structure that makes it hard for the security leader to escalate over the head of an operational boss is no longer just a governance weakness. It is a personal-liability trap for the one executive the law increasingly holds responsible, and a failure the board will have to answer for after the fact.
The fix is not heroics. It is a structural guarantee that the security leader has a direct, documented path to the board — a standing line to the audit or risk committee, an executive session without management in the room, a channel that does not depend on the goodwill of the person the bad news is about. That path is the control. The reporting line either builds it in or leaves it to courage, and courage is not a control either.
What the board should actually do
If you sit on a board, or you are the executive briefing one, treat the security leader's reporting line as a decision you own rather than a detail you inherit:
- Name the conflict out loud. Ask whose deadline the security veto threatens, and whether the current line makes the security leader report through that person.
- Guarantee a direct channel. Give the security leader a standing, documented line to the audit or risk committee, including a session with no other management in the room.
- Revisit the line when the business changes. A structure that fit at fifty engineers is a liability at five hundred, or after an acquisition, or after your first material incident.
The box on the org chart is the cheapest control you will ever install and one of the most consequential, because it decides whether the truth about risk reaches you early enough to matter.
I would genuinely like to hear how others have handled this — especially anyone who moved the reporting line and watched what changed, or watched a well-meaning structure fail the first time speed and safety actually collided. Tell me in the comments.
