Every regulated company I’ve worked with has a data governance policy. Almost none of them can tell you, without a meeting, who owns the definition of “active patient” or “recognized revenue” — or which of the four systems that report it is the one you should believe.
That gap — between the policy that’s written and the governance that’s real — is where regulated businesses actually get hurt. Not by missing a document, but by discovering mid-audit, or mid-AI-project, that nobody can vouch for the numbers.
Governance became a compliance ritual
Somewhere along the way, “data governance” came to mean a set of artifacts: a policy PDF, a steering committee, a data catalog, a stewardship RACI. Regulated industries are especially prone to this, because compliance rewards the appearance of control — something you can hand an auditor.
The problem is that those artifacts describe governance. They don’t enforce it. What you usually find underneath:
- A catalog documenting fields nobody updated after the last migration
- A stewardship matrix where half the “owners” left two years ago
- A policy that says data must be classified — with nothing that stops it being copied unclassified
- A committee that meets quarterly to approve what teams already shipped
None of this is bad faith. It’s what happens when governance is owned by a policy function instead of built into the architecture.
In regulated industries, the stakes are operational
When definitions drift at an unregulated startup, you get a confusing dashboard. When they drift in a hospital, a bank, or a manufacturer under audit, you get a finding, a fine, or a six-month reconciliation.
I’ve seen a patient counted three different ways across the EHR, the billing system, and the research platform — each locally defensible, none reconciled. I’ve seen “revenue recognized” mean one thing in the ERP and another in the warehouse. I’ve seen PHI copied into an analytics environment because extracting it the compliant way was a project, so someone took the shortcut.
Governance that works is mostly invisible
The best-governed environments I’ve seen don’t have thicker binders. They have governance built so deeply into how data moves that people follow it without thinking about it:
- Every business concept is defined once, and the definition lives where the data is produced — not in a glossary that drifts
- Ownership is structural — a domain owns its data, its definitions, and its quality, and that shows up in the architecture, not a spreadsheet
- Classification and access are enforced by the platform — PHI can’t leave its boundary because the architecture won’t let it, not because a document says it shouldn’t
- Lineage is a byproduct of how pipelines are built, not a separate documentation exercise
Notice what’s missing from that list: a committee. Governance you have to convene a meeting to enforce is governance that has already failed.
So it’s an architecture decision
This is the shift most regulated companies need to make. Governance isn’t a program you run alongside the platform — it’s a property of the platform. Loose coupling, clear domain boundaries, definitions that live at the source, access enforced in infrastructure: those are architecture choices, and they’re what actually produce the outcomes the policy is asking for.
The policy still matters — auditors need it, and it sets intent. But a policy without an architecture that enforces it is a promise you can’t keep. In a regulated industry, that’s the most expensive kind.
Where to start
If your governance is mostly binder and mostly not working, the fix isn’t a bigger binder:
- Pick the three or four concepts that carry real risk — the patient, the transaction, the recognized dollar — and get to one definition, owned by one domain, enforced at the source.
- Make the compliant path the easy path. If the governed way is harder than the shortcut, people take the shortcut. Fix the friction, not the people.
- Push classification and access into the platform so the boundary holds when no one’s watching.
- Treat lineage as something the architecture emits, not something a team documents after the fact.
None of that requires a re-platform. It requires deciding that governance is an architecture responsibility — and sequencing the work.