Governance that ships beats governance that reviews

Data governance earned its reputation: committees, spreadsheets of data owners who left the company, classification schemes applied to three of nine hundred tables. The word still makes engineers flinch. Which is a shame, because the 2026 version is mostly code, and the code version works.

The structural shift is that enforcement moved into the platform layer. Catalogs now carry access control as a first-class feature; Apache Polaris, a top-level Apache project since February 2026, ships fine-grained access control against the Iceberg REST spec, and every commercial catalog competes on the same axis. Meanwhile contracts (reviewed here) enforce schema promises in CI, and audit trails fall out of the query engine rather than out of interviews.

the working pattern

Policy as code, enforced where the data is touched, reviewed like any other code. Tag the sensitive columns; let the tag drive masking automatically; grant access by role through the catalog, with an expiry. The governance artifact is a pull request, and the reviewer is someone who can read it. No step in that loop requires a steering committee, which is precisely why it happens.

what still fails

Ownership. Tools enforce decisions; they do not make them. A masking policy needs someone to decide what counts as sensitive, and the programs that stall in 2026 stall exactly there, in the meeting that was supposed to name an owner and named a working group instead.

the catalog is the new perimeter

The consequence of enforcement moving into the catalog is that the catalog choice became a security decision, which is not how most teams evaluated theirs. A catalog picked two years ago for its search box now holds the grant tables for the entire lake, and the questions that matter are the unglamorous ones: can a grant expire on its own, can a policy be tested before it applies, does the audit log record the denial as well as the access, and can all of it be exported the day you leave. We have started reviewing catalogs the way one reviews identity providers, because that is what they became while everyone was comparing lineage graphs.

The interoperability story helps more than any single feature. An open REST spec for catalog access means policy travels with the table rather than with the engine that happens to read it, and the same grant governs the warehouse, the single-node engine on an analyst's laptop, and the pipeline that feeds both. That one-policy-many-engines property is the entire practical argument for open catalogs, and it is a better argument than the vendor-freedom one, which tends to be theoretical until a renewal negotiation makes it concrete.

how to leave the committee behind

The migration we keep watching succeed is unheroic. Pick the ten most queried tables, tag their sensitive columns, wire the tags to masking, and set every existing grant on them to expire in ninety days. The expiry is the forcing function: access that matters gets re-requested through the new path, access that does not lapses silently, and the inventory nobody could compile in committee compiles itself. Then publish the numbers, policies enforced, grants expired, mean time to access. Governance programs die of abstraction; a weekly number about concrete tables is the antidote.

What the committee keeps is the one job code cannot do: deciding, with a name attached, what the organization considers sensitive and who may see it. That meeting should be short, sparsely attended, and binding. Everything else it used to discuss is now a pull request, and pull requests do not need a quorum.

the audit test

A fair way to score any governance program, committee or code: ask for the answer to "who accessed customer email addresses last Tuesday, and under which policy" and time the response. The committee program answers in weeks, with interviews, and the answer is a reconstruction. The code program answers from a log, in minutes, and the answer is a record. Auditors have noticed the difference, and so have the regulators who read their reports; evidence produced by enforcement infrastructure simply survives scrutiny in a way that evidence produced by recollection does not.

The same test doubles as a migration priority list. Whatever question your program cannot answer from a log today is the next thing to move into code, and the questions arrive in a predictable order: who can see this, who did see this, who approved that, and when does it expire. A program that can answer all four from infrastructure has finished the hard part, whatever its org chart looks like.

verdict

Governance as code: adopt, the tooling finally deserves the word. Governance as committee: the control it provides remains approximately the control a "wet paint" sign provides. Automate the enforcement, spend the meetings on ownership, and measure the program by policies enforced rather than policies written.