Who Owns the Data, Really? Whoever the Error Hurt

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

"Who owns the data?" has a tidy answer on paper: a data owner, a steward, a named box on a governance chart. There is a second way to ask it, and I trust it more. When a record is wrong, whose job does fixing it become? Asked how the steward's role looked when I first met it, I started at the beginning, and the beginning answers that second question:

In my experience, Data Stewardship started with Power Users in the various groups who identified and corrected data errors in their systems that originated in upstream systems. Auditors frequently flagged the issues and it became the responsibility of those groups to fix the issues.

That answer, like every account of my own below, is an undated pattern from one career; the dated sources in this piece are set beside it, not mapped onto it. Two facts sit in that answer, and the rest of this piece hangs on the distance between them. The errors began in one place, in the upstream systems that produced the data. The work of correcting them landed somewhere else, with people in the groups whose systems received the damage. Nobody designed that arrangement. The first stewards were the people who noticed, and noticing made the cleanup theirs. When an auditor then wrote the problem down, the obligation to fix it attached to the same people, the ones standing next to it.

So here is the answer I will defend to the question in the headline. In practice, ownership of data has been settled after the damage rather than before it: the fix has often gone first to the group the irregularities hurt and, when that group lacked the knowledge or the bandwidth, has frequently been pushed back up the pipe to other groups. That is why stewardship has never stayed put. Even where a master data programme later wrote stewardship into its plan, the duty was expected to be absorbed on top of existing jobs rather than given hours of its own. The frameworks that put the owner at the source are right about where the fix belongs. What they describe is a decision that the businesses in my record did not make in advance.

Where the errors were found, and where they were made

The field has a name for the first arrangement. Thomas Redman calls the extra steps a department takes to cope with errors created upstream a "hidden data factory" [1], and his description of the people inside one could be a portrait of those first power users. Decision makers and others "must accommodate it in their everyday work," he writes, and "many individuals simply make corrections themselves to complete the task at hand"; they "don't think to reach out to the data creator" [1].

Why would the correcting happen downstream rather than at the source? Partly because downstream is where an error becomes visible. Richard Wang and Diane Strong, in the study that gave the field its consumer-centred definition, defined data quality as "data that are fit for use by data consumers," and argued that consumers have "a much broader data quality conceptualization than IS professionals realize" [10]. If quality is judged at the point of use, the point of use is where a defect is discovered, and the people who discover it are the people it hurts. A record that is wrong in a way nobody downstream cares about is, on that definition, not yet a quality problem at all.

The trouble is that the knowledge needed to fix an error does not live where the error is noticed. Yang Lee and Diane Strong studied the three roles in producing data, the people who collect it, the people who keep it and the people who use it, and report that collectors who understand why the collection process works as it does produce better data, and that the collectors' understanding matters more than that of the data's custodians [2]. Put the two findings side by side and the shape of the first stewardship is plain. The error is seen at the end of the pipe. The understanding that would prevent it sits at the start. A power user in an affected group has the first and not the second, and is doing a job that cannot be finished from where they sit.

Then the auditor. One standard shows the general shape of what an audit hands over, as an example, with no claim about which audits flagged these issues: the PCAOB's standard for an audit of internal control over financial reporting at US public companies tells the auditor to "communicate, in writing, to management and the audit committee all material weaknesses identified," and to communicate to management "all deficiencies in internal control over financial reporting" [8]. Read what that does and does not do. It says who must be told. It does not say which department must fix anything; that is management's decision. In my account, when auditors flagged the issues, the decision was to make the fix the responsibility of the groups that had the problem in front of them. The audit made the obligation formal. It did not move it upstream.

When the fix outgrew the job

The power users did not keep it. Next in the same answer, I described a turn about time, not skill:

IT got involved when some of the Users raised that the scope of the problem was beyond their ability to correct directly—it took too much time away from the ‘real job.’

The quotation marks around "real job" carry the whole complaint. The correcting had never been anybody's job. It was something done on top of one, by people measured on something else, and at some size the work on top stopped fitting. I drew the same line more bluntly when asked, about strategy rather than stewardship, how to tell early whether an organisation can carry out what it has just approved. I ended that answer on stewards:

This is a constant problem when it comes to Business Data Stewards whose responsibility includes Data Stewardship instead of being Data Stewardship.

That sentence separates two kinds of steward, and the history above is made almost entirely of the first kind. A steward whose responsibilities include stewardship has another job that gets measured and a stewardship duty that gets squeezed, and which of the two gives way under load is no mystery. Budgets show the same squeeze. Asked whether the worry was fair that a capital budget can pay to build master data while nothing is set aside to run it, I said it was well founded, and named what happens in many cases instead:

Your concern about capital budget paying for the project but no operational dollars for ongoing support is well founded. In many cases--as we've discussed previously--operational expenses are expected to just be absorbed into the standard budget as existing employees and resources are expected to shoulder MDM and Data Stewardship responsibilities in addition to their current work.

"In addition to their current work" is the power user's position written into a budget. A duty that is expected to be absorbed has no hours of its own, so the people carrying it can only do it in the time their measured job leaves over. When the scope of the problem grows past that, the duty has to go somewhere. In my account it went to IT. If IT came to the fix as the keeper of the systems rather than as the people who collect the data, Lee and Strong's finding above puts the knowledge it most needed still upstream of it [2].

How the role was designed: accountability named in advance

Over roughly the last two decades, the field has written down again and again who should answer for data before anything goes wrong. What they share is the thing my history lacks: each places accountability in advance. The appendix sets them side by side.

Start with the audit regime, because it is the one with consequences. Section 404 of the Sarbanes-Oxley Act requires each annual report to carry management's report on internal control over financial reporting and its assessment of that control [21]. For an issuer that is an accelerated or large accelerated filer and not an emerging growth company, it also requires the registered accounting firm to attest to and report on that assessment [21]. How the statute shaped master data as a category is an earlier piece's subject, and I will not re-argue it. What matters here is whom the regime names. The statute's text does not mention data, data quality or stewards [21]. It names management as the accountable party, in advance, and leaves to management the question of which group inside the company does the correcting.

The academic designs began from a complaint about where accountability had landed. Kristin Wende, writing in 2007, opened a model of data governance with the observation that "companies have assigned accountabilities for DQM mostly to IT departments," an approach she said "ignored the organisational issues that are critical to the success of DQM" (DQM being data quality management) [3]. Her answer was a set of roles arranged in a responsibility matrix: an executive sponsor, a data quality board, a chief steward, and two kinds of steward, the business data steward who works "directly with representatives from business" and the technical data steward focused on "data representation in IT systems" [3]. What I notice in her model is the split itself. The designed answer gave the steward two halves, one on each side of a line the work in my account crossed without anybody deciding it should.

Vijay Khatri and Carol Brown, in 2010, took "the Weill and Ross framework for IT governance as a starting point" and named "five interrelated decision domains: Data principles; Data quality; Metadata; Data access; and Data lifecycle," asking of each who makes the decisions, the "locus of accountability for decisionmaking" [14]. Theirs is a framework of decisions, not of steward roles. Roles appear in it as "examples of organizational positions that may be given accountability," each domain's accountability sits "somewhere on a continuum between centralized and decentralized," and in their discussion of data principles "IS professionals play the role of data stewards" [14]. Read as a design, that splits the work in advance: business owners carry an important role in managing data quality, and the IS stewards surface the issues for them [14].

Some companies built such designs in practice, and that deserves conceding rather than burying. Boris Otto's 2011 comparison of two large telecommunications companies found that one "has followed a more project-driven, bottom-up philosophy" while the other "favors a rather constitutive, top-down approach," and concluded that "the individual organizational design is context-contingent" [15]. In the first, the data quality effort "started in 1997 with an initial project" and grew into a programme; the second "decided to set up organizational units solely addressing the issue of data quality management" [15]. Both are deliberate. Large organisations can and do settle the holder before the next error, and my history is one practitioner's experience, not a census of how every organisation has done it.

Banking supervisors wrote the allocation into an expectation. The Basel Committee's principles for risk data aggregation and risk reporting, published in January 2013, run to fourteen principles [12]. Banks identified as globally systemically important in 2011 or 2012 "must meet these Principles by January 2016" [12]. Under the second principle, "roles and responsibilities should be established as they relate to the ownership and quality of risk data and information for both the business and IT functions" [12]. The word steward does not appear in the document [12]. Ten years after publication, the Committee's progress report on 31 globally systemically important banks, designated between 2011 and 2021, found them "at different stages in terms of alignment," with "significant work remaining at most banks to fully adopt the Principles" [13]. That is the outside datum this piece would most want. The Principles that wrote that allocation down in advance, for both the business and IT functions, were a decade later still not fully adopted at most of the banks the Committee assessed [13]. Naming the holder ahead of time did not, by itself, finish the work.

The profession's own body of knowledge moved the same way. DAMA International says the second edition of its DAMA-DMBOK was "originally published in 2018" and that a revised edition was "released in March 2024" [16]. The revision, which DAMA calls a maintenance release, defines a data owner as "a business person accountable for decisions within a domain" [17]. That definition is enough for the point: accountability is assigned to a named business person, by domain, ahead of time.

Data mesh took ownership out of the central team altogether. Zhamak Dehghani's 2019 article distinguished domains that "naturally align with the source, where the data originates" from those that "align closely with the consumption," and allowed for "a shared and newly reified domain dataset for multiple consumers to use" [18]. Her 2020 principles asked for "distribution of responsibility to people who are closest to the data," and said that "the accountability of data quality shifts upstream as close to the source of the data as possible" [5]. Even this design is not purely an at-source answer, since domains aligned with consumption own data too [18].

The strongest rival to my story is the chief data officer. If stewardship had only bounced, there would be no office that holds data accountability on purpose, and there plainly is one. NewVantage Partners reported in January 2022, from 94 Fortune 1000 or leading organisations, that appointment of a chief data and analytics officer had risen from "just 12.0% in 2012 when this survey was first conducted to 73.7% in 2022" [19]. That is a deliberate central allocation made at scale, and it is the best evidence against reading the period as reaction alone. The same release reported that 59.8% of organisations described the role as nascent, still evolving or subject to turnover, and that "91.9% in 2022" of executives pointed to culture as the greatest impediment to becoming data-driven, against 8.1% who named technology [19]. Its successor survey said in January 2024 of the role that "turnover has been high and tenures short" [20]. The office is a settled allocation. Whether the fix travels with it is a question these survey releases do not ask, and an office whose holders keep changing is a poor place to look for an answer that has stopped moving.

Why would designs that settle the question in advance sit beside a practice that settles it afterwards? It is not that the designs forget the work. Three of them provide for the hours as well as the holder: the Basel principles ask the board and senior management to "ensure that adequate resources are deployed" [12], Otto's second company set up organisational units solely for data quality management [15], and data mesh gives each domain "data product developer roles" [5]. Where an organisation did those things, the holder and the hours were both settled before the damage, and nothing in my record argues with that. Others, as cited here, allocate the decision and say nothing of the hours: Khatri and Brown's roles are positions that "may be given accountability" [14], and DAMA's owner is accountable for decisions within a domain [17]. What no design can do is pay for itself. Whether the hours arrive is decided afterwards, in an operating budget, and in the organisations in my record where no operating budget was set aside, the ongoing duty was often named and then expected to be absorbed into existing jobs. The work of correcting an error arrives with the error, shows up where the error shows, and, where no hours were funded in advance, goes to whoever has time for it. That is my reading of the gap, not a claim any of these sources makes: not a lack of design, but hours that were never budgeted.

Set beside one another, the designs agree about where the fix belongs. Redman's prescription for the hidden data factory runs the same way as Dehghani's: the department suffering the errors should reach out to the department creating them, explain what it needs, cite examples and share measurements, and the creating department should find and remove the root causes [1]. I agree with them about where the fix belongs. An error is cheapest to stop where it starts, and the people who produce data are the ones who know why it is produced the way it is, which is where Lee and Strong's finding points [2]. The at-source answer also assumes a source the organisation controls, and not every source is one: a vendor's feed, data that customers enter themselves, or a system that arrived with an acquisition may have no producer inside the building to hand the fix to. Robert Seiner, from a very different school of governance, does not confine stewardship to the source at all: he argues that "everybody in the organization is a Data Steward" and that "people that define, produce, and use data must be held accountable for how they define, produce, and use the data" [4]. He proposes that most programmes, which "assign or hire people to be data stewards," should instead be "identifying or recognizing these people based on their existing levels of authority associated with their data domains" [4]. That is close to where my history starts.

Regulation outside banking draws the same kind of outer boundary. The General Data Protection Regulation, adopted in 2016, requires personal data to be "accurate and, where necessary, kept up to date," and makes "the controller", in the usual case the organisation, responsible for that principle [9]. Like the auditing standard above [8], it names who answers for an error outside the building and leaves the inside question to whoever allocates the work.

The analysts do not claim the deliberate version is common. Gartner predicted in 2024 that "by 2027, 80% of data and analytics (D&A) governance initiatives will fail due to a lack of a real or manufactured crisis," and described teams that "operate governance reactively" [6]. That is a forecast, not a measurement, and Gartner's remedy is governance tied to business outcomes rather than anything about stewards. But its premise is the telling part: in the firm's own view, governance moves when something forces it.

So the designs and my record differ in one respect, and it is the respect that answers the headline. Each design above places accountability before the next error. In my record, practice settled the holder after it: the fix often went first to the group the error hurt, and was frequently pushed on when that group ran short of knowledge or hours.

Bounced, not handed over

Here is what I said came after IT:

Over time, the responsibility for Stewardship has bounced around based upon the requirements of the business, regulatory changes and technological capabilities.

Three drivers, named together: what the business needed, what regulators required, and what the technology could do. I named them together, and nothing in my record says which of them moved stewardship most. What they share, on my reading, is that each changes the cost of a fix or the cost of leaving an error alone, and each arrives from outside the stewardship arrangement rather than from a decision about it. A new requirement can make a different group the one that is hurt. A new rule can make a class of error expensive. A new capability can make some fix cheap for whoever holds the tool. In a business that settles the holder after the damage, any of the three is enough to move it.

"Bounced" is the word I would keep. A handover has a sender, a receiver and a moment when responsibility passes from one to the other; a bounce has none of those. It moves because it hit something. This publication has argued, from my answers, that a master data programme reveals who owns data rather than settling it, and that putting one layer in order exposes the unordered layer above it. Stewardship's history is the same argument run over time instead of across one programme. Holders kept the fix until something showed it was in the wrong place.

Reactive, and pushed back up the pipe

I closed that answer with the verdict this piece is built on, a pattern from my own record rather than a measured rate:

In short, business has been reactive to data issues rather than proactive and has often allocated responsibility for correcting the problem to the group impacted by the irregularities. They’ve frequently pushed it back up the pipe to other groups because of limitations in knowledge or bandwidth.

There are three claims in that answer, and they are not equally obvious. The first is that the business was reactive: stewardship was arranged in response to data issues rather than ahead of them. The frameworks above would not dispute that as a description; they were written because it is so. The second is the allocation: the fix going first to the group the irregularities hurt. That is the answer to the headline question, and it is the one I would most like a reader to test against their own organisation. Ask who fixed the last bad record, and who has been asked to stop the next one, and see whether the answer is the group that produced the data or the group it damaged.

I went looking for a measurement that would show me wrong: a survey finding that most organisations place stewardship with the people who produce the data, and decide that before anything breaks. I found none that asks the question that way. The nearest is a December 2024 Forrester data snapshot whose public summary reports that the data organisation is the most common owner of data quality, at 42% [11]; I have read the summary, not the report. A central data organisation is a deliberate allocation, and often a sensible one, but it is not the source either. So the nearest number I can find neither counts against the claim nor proves it. It says where data quality sits, not when or why it was put there.

The sharper objection is that I am describing immature organisations: a mature programme designates stewards from the start, and Otto's second company did something close to that [15]. Designation, though, is not the same as hours. In my experience a master data implementation plan does carry a first round of stewardship and classification as a core part of the work, and expects the support role afterwards to bring new sources into the existing entities without a capital request. The ongoing duty is the part that, in many cases, is expected to be absorbed by existing staff on top of their jobs. A steward named on the first day with no time of their own is a designed allocation that behaves, under load, like a reactive one.

Put that way, the objection can return as a truism: programmes without hours or money do worse, and nobody needs a history to know it. That is not the claim, and when it was put to me I answered it directly:

It's not that underfunded programs underperform, it's that underfunded programs impact other programs that are funded. Underfunding or under-budgeting foundational projects introduces cracks that need to be filled with time and money spent by the programs that are funded, so they rebuild the foundation instead of the additions for which they were approved.

That is what turns a budgeting choice into an answer about ownership. If an unbudgeted foundation hurt only its own programme, the cost would stay where the gap was made. On my record it does not. The cracks are filled by the funded programmes that build on the data, with time and money from budgets approved for something else. The group the error hurt pays for the fix because it is the group that needed the data to be right. The plainest case in my record is something as ordinary as a client list:

Customers who generate lists of clients (and this goes for all of them) have found themselves spending time and budget from other projects correcting the underlying data instead of correcting the reports. This has led more than one client to changing the business logic in the report more than once during the course of the same project as underlying data errors were corrected. If they started with accurate data, they would only need to go through the exercise once and the project could complete that much earlier and cheaper.

Each correction upstream changed the data the report stood on, so the report's logic was rewritten to match, more than once in the same project. On my reading, that is Redman's hidden data factory with a project code on it [1]: the correcting is real work, it is done by the people the errors hurt, and it is charged to work that was approved for something else. The data was corrected during the project rather than before it, and nothing in that account moved the fix ahead of the damage.

The third claim is what makes the arrangement unstable, and it needs care, because the best-known source on the subject seems at first to cut against it. Redman's downstream workers do not push anything back up. They "simply make corrections themselves," and they "don't think to reach out to the data creator" [1]. My answer says the impacted groups frequently did push it back up. The two describe different points in the same story. The first stage of my history has the shape of Redman's hidden factory: power users correcting, quietly, at their own cost. The pushing starts when that stops being possible, when the scope outgrows what a group can correct directly or the time it can spare from the real job. And it goes back up for the two reasons I gave. The group the error hurt does not know why the upstream system produced it, which is Lee and Strong's finding seen from the other end [2], and it has no hours set aside to find out, which is the absorbed duty of the section before.

That sounds like what Redman prescribes, and it differs in the one respect that decides the outcome. His department B goes to department A with requirements, examples and measurements, and A owns the root cause from then on [1]. The push I described is not that. It is a group handing back a job it was given and cannot finish, and the job lands wherever the next driver can make it stick. Redman's version moves the ownership to the source. The reactive version moves the task, and the ownership keeps travelling.

The latest bounce

Which brings the history to now. My answer gave the present a single line:

Right now, we’re seeing an attempt to shift it to AI.

The word that matters there is "attempt." The interest is real. Gartner predicted in June 2025 that "by 2027, 50% of business decisions will be augmented or automated by AI agents for decision intelligence," and its analyst Carlie Idoine added in the same release that such agents "aren't a panacea, nor are they infallible" and "must be used collectively with effective governance and risk management" [7]. A forecast about decisions is not a report that stewardship has moved.

What the history above does offer is a way to read the attempt. If the business is still reactive, then, on my reading, handing the fix to AI is the next allocation by the same reactive logic: the fix goes to whatever can absorb it now, because the knowledge and the hours are short where the error is felt. That would make AI the newest holder of a job that was never assigned at the source, and it would inherit at least the first of the two limits. An AI given the fix downstream sits in the power user's seat. It can see the error, and the reason for the error is still upstream. Whether it eases the second limit, the hours, is a fair question, and it is not the same question as whether the fix is now in the right place. How a steward should work with what an AI proposes is a separate subject again, and I will leave it for its own piece. The question here is only who is being handed the fix, and on this history the holder is still settled after the damage, not before it.

Who owns the data, then

Back to the two ways of asking. The governance chart answers with a title. The history answers with a pattern: the fix has often gone first to the group the error hurt, and when that group ran short of knowledge or bandwidth it has frequently been pushed on, to IT among others and now, by attempt, to AI. In my record, neither stage was settled before the damage, and the cost of settling it late did not stay with the programme that went without. It was paid by the funded work that came after it.

That is what the experience changes about the frameworks' answer. They are right that the owner of data belongs where the data is made [5] [1]. Read as a description of how ownership has actually been allocated, they would be wrong, and the gap is not a fault in the frameworks. Putting the owner at the source is a decision made before the damage, and the businesses in my record made the decision after it, often one injured group at a time. A reader who wants to know who owns their data does not need a new model to find out. They need to look at who fixed the last error, whether that group made it, and whether it has the knowledge and the hours to stop the next one. If the answers are a downstream group, no and no, then the data is owned by whoever it hurt, and the fix is about to move again.

Appendix: the designs side by side

The designs cited above, read for three things: whether each names the holder before the error, where it puts that holder, and whether it provides for the hours. "Not stated" means the passages this piece cites do not provide for hours; it is not a claim about the whole work.

• Sarbanes-Oxley Act, Section 404 [21]. In advance: yes. Holder: management, which decides which group inside the company does the correcting. Hours: not stated.
• Wende (2007) [3]. In advance: yes. Holder: roles in a responsibility matrix, from an executive sponsor and a data quality board to business and technical data stewards. Hours: not stated.
• Khatri and Brown (2010) [14]. In advance: yes. Holder: accountability for five decision domains, set on a continuum between centralised and decentralised. Hours: not stated; roles are positions that "may be given accountability".
• Otto (2011), first company [15]. In advance: yes, bottom-up, from an initial project in 1997. Holder: a data quality programme grown from that project. Hours: not stated.
• Otto (2011), second company [15]. In advance: yes, top-down. Holder: organisational units set up solely for data quality management. Hours: yes, in those units.
• BCBS 239 (2013) [12] [13]. In advance: yes, for banks designated globally systemically important in 2011 or 2012, by January 2016. Holder: "both the business and IT functions", with the business owner responsible for correct entry. Hours: yes, "adequate resources". A decade on: not fully adopted at most of the banks assessed [13].
• General Data Protection Regulation (2016) [9]. In advance: yes. Holder: the controller, in the usual case the organisation, which allocates the work inside. Hours: not stated.
• DAMA-DMBOK (2018; revised 2024) [16] [17]. In advance: yes. Holder: a data owner, "a business person accountable for decisions within a domain". Hours: not stated.
• Data mesh (2019, 2020) [18] [5]. In advance: yes. Holder: domains, aligned with the source or with consumption. Hours: yes, "data product developer roles" in each domain.
• The chief data officer [19] [20]. In advance: yes, an office appointed on purpose, in 73.7% of the organisations surveyed by 2022. Holder: a central office. Hours: not stated; the 2024 release reports that "turnover has been high and tenures short".

References

[1] Thomas C. Redman, "Bad Data Costs the U.S. $3 Trillion Per Year," Harvard Business Review, 22 September 2016. Read 2026-10-10 in full, through a rendering fetch of a reproduction (hbr.org itself was refused at the proxy); not stored locally. Cited for the hidden data factory, the three sentences quoted about downstream correction, and the reach-out-to-the-source prescription. https://hbr.org/2016/09/bad-data-costs-the-u-s-3-trillion-per-year (read at https://dataladder.com/wp-content/uploads/2019/07/Bad-Data-Costs-the-U.S-3-Trillion-Per-Year.pdf)

[2] Yang W. Lee and Diane M. Strong, "Knowing-Why About Data Processes and Data Quality," Journal of Management Information Systems 20, no. 3 (2003): 13–39. Read 2026-10-10 at the abstract only, through a rendering fetch of the journal's article page; the paper was not read. Cited for the three roles and the finding that collectors' knowing-why matters more than custodians'. https://jmis-web.org/articles/602

[3] Kristin Wende, "A Model for Data Governance – Organising Accountabilities for Data Quality Management," ACIS 2007 Proceedings, paper 80 (2007), pp. 417–425. Read 2026-10-10 in full (figures as captions only), through a rendering fetch; not stored locally. Cited for the sentences quoted on p. 417 and p. 421 and the role list on pp. 420–421. https://aisel.aisnet.org/acis2007/80/

[4] Robert S. Seiner, "It's all in the Data: Everybody is a Data Steward (Get Over It)," TDAN.com, undated on the page. Read 2026-10-10 in full, through a rendering fetch; not stored locally. Cited for the three phrases quoted (the third re-read verbatim 2026-10-10). https://tdan.com/?p=20003

[5] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020. Read 2026-10-10 in full, through a rendering fetch; not stored locally. Cited for the two phrases quoted from the domain-ownership and data-as-a-product principles. https://martinfowler.com/articles/data-mesh-principles.html

[6] Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," press release, Stamford, Conn., 28 February 2024. Read 2026-10-10 in full, through a rendering fetch; not stored locally. A forecast, cited as one. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

[7] Gartner, "Gartner Announces the Top Data & Analytics Predictions," press release, Sydney, 17 June 2025. Read 2026-10-10 in full, through a rendering fetch; not stored locally. Cited for the AI-agents prediction and Carlie Idoine's two quoted phrases. https://www.gartner.com/en/newsroom/press-releases/2025-06-17-gartner-announces-top-data-and-analytics-predictions

[8] Public Company Accounting Oversight Board, AS 2201, "An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements," paragraphs .78 and .81. Read 2026-10-10 through a rendering fetch, the first 100,000 of 134,277 characters (the paragraphs cited are inside that span); not stored locally. https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201

[9] Regulation (EU) 2016/679 (General Data Protection Regulation), adopted 27 April 2016, Article 5(1)(d) and 5(2). The adoption date was read on EUR-Lex on 2026-10-10; the EUR-Lex text fetch returned the recitals only, so the operative text of Article 5 was read on an unofficial consolidated mirror (https://gdpr-info.eu/art-5-gdpr/), through a rendering fetch; not stored locally. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng

[10] Richard Y. Wang and Diane M. Strong, "Beyond Accuracy: What Data Quality Means to Data Consumers," Journal of Management Information Systems 12, no. 4 (Spring 1996): 5–33. Read 2026-10-10 in full (tables as placeholders) at the MIT Total Data Quality Management programme's copy, through a rendering fetch; not stored locally. Cited for the definition and the sentence quoted. https://web.mit.edu/tdqm/www/tdqmpub/beyondaccuracy_files/beyondaccuracy.html

[11] Forrester, "Responsibilities And Task Ownership Are Spread Across Data, IT, And Lines Of Business," data snapshot, 19 December 2024. Read 2026-10-10 at the public summary only, through a rendering fetch; the report is paywalled and was not read. Cited for the summary's figure that the data organisation most commonly owns data quality (42%). https://www.forrester.com/report/responsibilities-and-task-ownership-are-spread-across-data-it-and-lines-of-business/RES181881

[12] Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting (BCBS 239), Bank for International Settlements, January 2013. Read 2026-10-10 in full through a rendering fetch of the BIS full-text file; not stored locally. Cited for the number of principles, paragraph 14 (G-SIBs by January 2016), Principle 2, paragraph 28 (resources deployed, re-read verbatim) and paragraph 34 (roles for the business and IT functions; the business owner's data-entry duty), and the absence of the word steward. https://www.bis.org/publications/201301-guidelines-principles-effective-risk-data-aggregation-and-risk-reporting.pdf

[13] Basel Committee on Banking Supervision, Progress in adopting the Principles for effective risk data aggregation and risk reporting, 28 November 2023. Read 2026-10-10 at the publication's summary page only, through a rendering fetch; the full report was not read. Cited for the two phrases quoted and the count of 31 banks. https://www.bis.org/bcbs/publ/d559.htm

[14] Vijay Khatri and Carol V. Brown, "Designing Data Governance," Communications of the ACM 53, no. 1 (January 2010): 148–152, doi:10.1145/1629175.1629210. Read 2026-10-10 in full through a rendering fetch of a copy hosted by Khon Kaen University (the ACM page could not be fetched); not stored locally. Cited for the phrases quoted on pp. 148–152. https://hs-cims-v2.kku.ac.th/uploads/files/646e37d9d9d78_1629175.1629210.pdf

[15] Boris Otto, "Organizing Data Governance: Findings from the Telecommunications Industry and Consequences for Large Service Providers," Communications of the Association for Information Systems 29, article 3 (August 2011): 45–66. Read 2026-10-10 in full through a rendering fetch; not stored locally. Cited for the phrases quoted from the abstract and the two cases. https://aisel.aisnet.org/cais/vol29/iss1/3/

[16] DAMA International, "Body of Knowledge" (DAMA-DMBOK) page. Read 2026-10-10 through a rendering fetch; the DMBOK itself was not read. Cited for DAMA's own statement of the two edition dates. https://dama.org/content/body-knowledge

[17] DAMA International, "DAMA-DMBOK Revision" page. Read 2026-10-10 through a rendering fetch; the revised book was not read. Cited for "maintenance release" and the definition of a data owner. https://dama.org/dama-dmbok-revision/

[18] Zhamak Dehghani, "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh," martinfowler.com, 20 May 2019. Read 2026-10-10 in full through a rendering fetch; not stored locally. Cited for the three phrases quoted on source-aligned, consumer-aligned and shared domains. https://martinfowler.com/articles/data-monolith-to-mesh.html

[19] NewVantage Partners, "NewVantage Partners Releases 2022 Data And AI Executive Survey," press release, Business Wire, 3 January 2022. Read 2026-10-10 through a rendering fetch of the release; the full survey report was not read. Cited for the sample, the appointment figures quoted, the share describing the role as nascent or subject to turnover, and the culture and technology figures. https://www.businesswire.com/news/home/20220103005036/en/NewVantage-Partners-Releases-2022-Data-And-AI-Executive-Survey

[20] Wavestone, "2024 Data and AI Leadership Executive Survey," news release, 9 January 2024. Read 2026-10-10 through a rendering fetch of the release page; the report itself could not be fetched. Cited for the phrase quoted on turnover and tenure. https://www.wavestone.com/en/news/2024-data-and-ai-leadership-executive-survey-41/

[21] Sarbanes-Oxley Act of 2002, section 404, codified at 15 U.S.C. § 7262 (Management assessment of internal controls). Read 2026-10-10 in full through a rendering fetch of the Legal Information Institute's text; not stored locally. Cited for what subsections (a), (b) and (c) require and for the absence of the words data, data quality and steward. https://www.law.cornell.edu/uscode/text/15/7262