Where Should Data Sit?

Let’s start with the confusion. It is real, and it is a clue. Ask ten organizations who owns data infrastructure and you get a tour of the alphabet: the CTO, the CIO, the CFO, the CFAO, the COO, a CDO, a CDAO, a Chief AI Officer, a Chief Innovation Officer, sometimes a Chief Impact Officer, occasionally a CPO. Several of those titles mean different things at different organizations. The acronym soup is not a trivia problem; it is the symptom. The field has not agreed what this function is, so it has not agreed who should own it. Every organization improvises.

So set the title question aside. It is the wrong question, and answering it first is how organizations end up improvising. Ask the prior one. What does data infrastructure need from its place on the org chart? Answer that, and the seat stops being a matter of taste.

I first met this argument in a narrower form: the monitoring-and-evaluation data of mission-driven organizations, the data that tells a funder whether a program worked. That data usually belongs to a technology or digital-products team, and it gets bent toward that team’s priorities rather than the evaluators’. The fix there and the fix here are one argument at two scales. Data should not be owned by a function whose incentives point somewhere else. What follows is that argument at full-organization scale.

The four reasonable answers

There are four defensible places to put data infrastructure. Each deserves its honest case before I argue against it.

Under the CTO or CIO. The case is strong. Data runs on technical infrastructure: pipelines, warehouses, access controls, uptime. That is engineering, and engineering muscle lives under the CTO. Put data where the people who can build and run the plumbing already sit. The cost shows up later. Under the CTO, data gets read as a system to keep running, and what gets resourced is what the CTO is measured on: reliability, security, uptime, incident response. The semantic layer, the part that makes data mean something to a program lead or a board, becomes nobody’s priority. The function slowly turns into a service desk, quick to answer a request and absent from the decision.

The CFO or CFAO option. Also a real case. Data is a governed, risk-bearing asset, and finance already runs enterprise reporting, has audit discipline, and treats numbers as things that must reconcile and withstand scrutiny. Few functions are better at custody. The cost is orientation. Finance looks backward by instinct, and it looks at compliance: the close, the audit, the filing. Under finance, the data function optimizes for the report being correct rather than the decision being better, and forward-looking operational work is always the thing finance will get to later.

Its own seat, a CDO or CDAO. This is the strongest alternative, and it should be conceded as one. Data is strategic enough to warrant a peer-level seat: uncaptured, visible, carrying a standing none of the embedded options confer. The role exists to solve the placement problem. The cost is the gap between a seat and traction. A CDO with a title but no integration mandate produces strategy (frameworks, roadmaps, decks) and not adopted systems, because nothing structurally obliges the other functions to change how they work. The seat becomes an island. And for most mid-size and mission-driven organizations the seat is unaffordable; prescribing it prescribes nothing they can act on.

Under the CPO, in service of the product. Where data is the product, or feeds it directly, this is correct and barely needs defending. Where data is not the product, it is the narrowest capture of all: the function answers the product’s questions well and the rest of the organization’s not at all.

All four placements share one flaw. Each puts data infrastructure inside a single function, and a single function bends data toward its own incentive. The executives aren’t at fault; it is what reporting lines do. A cross-functional capability owned by one function gets narrowed by it.

What the function actually needs

So name what data infrastructure needs from its place on the chart. Four things.

1. 01It needs to see across every function, because it serves all of them: programs, finance, operations, development, the executive team.
2. 02It needs to stay uncaptured. The moment it bends toward one function’s incentive, the other functions stop trusting it as theirs.
3. 03It needs traction. Sight is not enough; it needs the standing to make functions adopt shared definitions and use what it produces. Sight without traction is a research office nobody acts on.
4. 04It needs to report at the altitude where its decisions live. Data infrastructure’s daily work is the recurring operating decisions that run across functions, not the strategic decisions that sit with the CEO and the board.

No single-function seat provides all four. A function seat fails the second test the day it is created.

The seat that is left

The seat that’s left, once the four embedded options are set aside, is the one already accountable for how the whole organization runs together. Call it the integration seat. In most organizations, it is the Chief Operating Officer.

The COO is not a single function. The COO is the place the functions already meet, which clears the capture test, and the COO sees across all of operations, which clears the sight test. The third test is the one a standalone CDO cannot pass: the COO has the standing to make a shared definition stick. When the COO says every team will use one definition of an active client, teams use it. When a peer says it, they negotiate. Traction is a property of the seat, not the person. And the altitude matches: the COO’s job is how the organization operates day to day, which is where data infrastructure’s decisions live.

Why not put data under the CEO, then? More authority still. The answer is that authority is not the binding constraint. Altitude is. The CEO’s seat is strategy, the board, fundraising, the outside world. A data function reporting to the CEO tends to collect the title and not the operating attention; the CEO will not run the weekly cadence that turns a data function into an adopted one. It ends up high-status and under-used, an orphan with a good address.

There is one real exception, and it matters, because it describes most of the organizations I work with. Many organizations have no COO. In smaller and mission-driven organizations, the executive director or CEO is the operating integrator. There is no second seat. There, data infrastructure should sit with the CEO or ED, not because that office is senior enough, but because in that organization it is the integration seat. As the organization grows and adds a COO, ownership should migrate to it.

That is the principle, and it is worth stating without a single acronym in it:

Data infrastructure should report to the integration seat, never to a single-function seat.

That seat is the COO by default, the CEO or executive director where there is no COO, and ownership should move between them as the organization formalizes. The title changes from org to org, and over time. The principle does not. That is the real resolution of the acronym soup. The field keeps trying to settle a function question with a naming answer, and it never works, because the answer was never a name.

The principle is not anti-CTO. The CTO owns the pipes: the engineering of the platform, the security, the uptime, and owns them well. Data infrastructure, placed at the integration seat, owns the semantic layer and the decision-serving built on top of those pipes. Two functions, one clean handoff. Placing data at the integration seat does not take it away from engineering. It ends the pretense that the semantic-and-decision layer is an engineering by-product.

I have watched this from inside more org charts than most people get to. The same data capability, sometimes the same people, sat under a research division at one organization, under the business at another, under a COO at a third. At one, it was moved mid-year from one executive to another and renamed on the way. The capability did not change across those moves. Its reach did. Under the integrator it served the whole organization. Everywhere else it served whoever it reported to, and the rest of the organization learned to route around it.

The unicorn that isn’t

There is a hiring problem that looks unrelated to all of this. It isn’t.

Mission-driven organizations keep writing job descriptions for data leaders that read as impossible. One person who can architect the infrastructure, and carry real measurement depth, and run the analytics, and hold their own with the C-suite. Search committees circulate these, then sigh that the candidate is a unicorn and the role cannot be filled.

Most of the time, the unicorn is not a talent problem. It is a placement problem wearing a talent problem’s clothes. When data infrastructure is buried under IT, or scattered across programs, or housed in finance, the person hired to lead it has to personally span every layer the org chart failed to connect. They are the only integration the organization built. The role looks heroic because it is doing, in one body, the structural work a correct reporting line would have done for free.

Place ownership at the integration seat and the heroics subside. Full-stack capability stops being a unicorn requirement. It becomes a senior role supported by its position instead of compensating for the lack of one. The role was mis-housed, and the job description was billing one person for the org chart’s unpaid debt.

Where this is going

The field is slowly moving toward all of this. Data spent two decades under IT, a cost center with the lights kept on. The Chief Data Officer emerged to pull it up and out, and the title has since absorbed analytics and then AI, cycling through CDO, CDAO, Chief AI Officer. The direction of travel is real: data climbing from the basement toward the place decisions get made.

But the climb has mostly reached large enterprises. Mid-size and mission-driven organizations are still placing data by accident. And the churn of titles is the field, again, trying to solve a function problem with a naming solution.

Agentic AI is about to make the question impossible to keep improvising. Agents do not just inform decisions; they make them, and every agent needs a manager and an owner. An organization that never decided where its data infrastructure sits is now going to be asked where its agents sit, and who is accountable when one acts. The placement question does not get easier. It gets unavoidable.

The answer, when an organization finally faces it, will not be a title. It will be a decision about what the function is for: serving decisions across the whole organization. Once that is named, the seat is named with it — the one place already accountable for the whole organization running together. Put data there and it stops being a service desk, a compliance engine, or an island. It becomes the thing it was always meant to be. From fragmented to decision-ready, and that begins, before a single dashboard is built, with where the function sits.

Written May 2026 for the Analytic Bytes Library. An argued position piece; the honest case for each alternative is made in earnest before the argument lands.