← all posts

July 6, 2026 · 5 min read

Data quality is a governance problem, not an IT problem

Technical teams can test and repair data. The business still has to decide what is fit for a decision, how old is too old, and who accepts the risk.

In June 2018, the Federal Reserve objected to a major bank's capital plan. Not because the bank was undercapitalized. Because of material weaknesses in the data capabilities and controls supporting its capital planning, along with the assumptions used to forecast revenue and losses under stress. Under the Fed's framework, that objection meant the bank couldn't make planned dividend payments or share buybacks. A data problem became a constraint on the actual movement of money.

That's the tell that data quality isn't an IT category. Calling it "technical debt" quietly files it under work that can wait. It can't wait when the data feeds a forecast, a capital plan, a compliance decision, or an automated system, because the people who can actually decide what the business is willing to risk aren't the people maintaining the pipeline. A technical team can tell you a table is complete and internally consistent. Only the business can tell you whether that's good enough for this decision.

What accountability looks like

Governance research is specific about this: it defines the problem in terms of decision rights, not job titles. Who defines what "fit for use" means for a given dataset. Who approves access. Who owns the metadata. Who's actually accountable when someone has to accept an exception instead of fixing it. The owner of a customer metric is not automatically the person who maintains the database, because ownership follows the decision the data drives, not the server it happens to sit on.

  • A named business owner defines what fitness for use means for each decision-critical dataset.
  • A technical owner maintains the pipeline, tests, lineage, and remediation workflow.
  • Exceptions record the impact, expiry date, and person who accepted the residual risk.
  • Quality issues are prioritized by the decisions they affect, not only by technical severity.

None of this is a new invention. It's already how serious financial controls work: PCAOB standards require auditors to test the accuracy and completeness of company-produced information, or the controls over it, precisely because "the system ran successfully" was never treated as proof the output was trustworthy. The Fed's objection to that bank's capital plan is the same principle showing up as a supervisory consequence instead of an audit finding.

No reorganization is required to start. The first governance improvement is naming one person who can actually answer, today, without checking with three other teams: "is this dataset fit for this decision?" If nobody can answer that in under a minute, that's the gap, not the dashboard.

Clean your data.
Trust your forecasts.