Almost every regulated mid-market company has a data governance policy. It's usually a well-written PDF, approved by leadership and saved somewhere safe. It says customer personal data is classified and protected. It says every critical report has a named data owner. It says access to sensitive fields is limited to the people who need it.
Then a real question arrives. A regulator asks where a customer's personal data travels after it's collected. An auditor asks who owns the numbers in a regulatory return. A privacy team asks what data a new AI pilot is actually touching. And nobody can answer quickly, because the catalogue, the lineage and the ownership that would prove the policy simply don't exist outside the document.
That is the gap we work on at OrchV. Our position is simple: data governance is not a policy document. It's a set of controls that run on your data platform, every day, whether anyone remembers the policy or not.
A governance policy is a list of promises. A control is what keeps those promises when nobody is looking. The difference sounds small on paper, but it decides whether your team can answer a regulator in an afternoon or in a month.
To enforce a data policy, the platform has to know four things. It has to know what data exists, which is the job of a catalogue. It has to know how that data moves from source systems into reports, dashboards and models, which is lineage. It has to know who is responsible for each dataset, which is ownership. And it has to know how sensitive each field is, which is classification. When those four live only in a PDF and a few spreadsheets, the policy depends on people remembering it.
That might have been workable when a company ran a handful of reports from one warehouse. It doesn't hold up now. New pipelines get added every quarter, SaaS tools bring in new sources, and AI pilots pull data from places nobody documented. Every change moves the real data estate a little further from what the policy describes. This is also why so many AI pilots stall at privacy or risk review. Nobody can say with confidence what data the model is touching, so nobody will sign it off.
Data governance as a PDF vs as an enforced control
We made a related point in our earlier article, ****The Enterprise AI Stack Is No Longer Just About the Model****. The model is only one component. What decides whether an AI use case reaches production is everything underneath it: the data, the context it draws on, and the governance that proves that data can be used. A governance policy that exists only as a PDF is exactly the layer that keeps AI stuck at the demo stage.
Governed data under the enterprise AI stack
The gap shows up most painfully when evidence is due. In India it might be readiness under the DPDP Act. In Australia it might be Privacy Act obligations or, for regulated entities, APRA CPS 234. In North America it might be one of the growing list of state privacy laws. The trigger changes, but the routine looks the same. Someone traces where personal data flows by reading SQL and pipeline code. Someone else emails five teams to find out who owns a dataset. Classification gets rebuilt in a spreadsheet, and screenshots of access settings get pasted into a shared folder.
Run the numbers on your own team and they add up quickly. Say three data engineers and a compliance lead spend half their time on this for three weeks. That's roughly 240 person-hours in one cycle, and most regulated businesses face more than one cycle a year. Your figures will be different, but they are rarely small, and they come out of the same team that's supposed to be building new pipelines.
Then there's the delay. Privacy requests take longer to answer. Audit responses slip. AI pilots wait weeks for a privacy or model-risk sign-off that nobody can give without lineage.
The error rate is the quietest cost. Lineage drawn by hand is out of date the week after it's drawn. A classification spreadsheet misses the tables added since the last review. Two teams report the same metric from different sources and argue about which number is right. And because none of this work is kept up between cycles, every new request starts again from zero.
The manual compliance evidence cycle
The fix isn't a longer policy. It's putting the policy into the data platform itself.
In practice, that means a catalogue that lists the datasets in your priority domains and keeps that list current. It means lineage captured directly from your pipelines, so you can trace a field in a regulatory report back to the system it came from without reading code. It means every important dataset has a named owner and steward, recorded in the catalogue rather than in someone's memory. And it means classification tags that do real work: a field tagged as personal data is automatically masked or restricted on the platform, instead of relying on someone to remember the rule.
A catalogue on its own isn't the answer either. As we wrote in ****Your Catalogue Is Lying to You****, a catalogue kept up by manual tagging falls behind as soon as schemas start changing, and an inventory of tables is not the same thing as lineage. A catalogue tells you what data exists. Lineage proves where it came from and where it went. That's why we capture lineage from the pipelines themselves and keep ownership inside the catalogue, so the record stays current without anyone having to remember to update it.
Access control and security sit inside this, not beside it. We treat classification, least-privilege access and control evidence as part of the same build. That way the controls are engineered in from the start rather than retrofitted after an audit finding.
Once this is in place, compliance evidence stops being a project. The catalogue, the lineage and the access logs are the evidence, generated by the platform whenever someone asks for it. We build on the platform you already run, whether that's Snowflake, Databricks, Fabric or Azure. Where a new licence would delay the start by a quarter, open-source catalogue and lineage tools can do the job just as well.
Our Data Governance baseline is a fixed-price, fixed-scope engagement with a defined end date. It's delivered by one POD, an Architect and Senior Developers, who own the outcome from the first week to the last. The aim is a working, enforced baseline across your priority data domains, not an assessment report.
In weeks one and two, we agree the scope with you. Together we pick the priority domains, usually the customer, finance or risk data your regulator cares about most. We then map the source systems, the current owners and the specific obligation you need to evidence, whether that's DPDP readiness or Privacy Act compliance.
In weeks three and four, we stand up the catalogue and capture lineage for those domains. Owners and stewards are named and agreed, and we set a classification scheme that fits your data and your regulator.
In weeks five to seven, we enforce. Classification tags are wired to access control and masking on your platform, and data quality checks go in where they matter. We also build an evidence view mapped to your regulatory obligation, so the proof comes from the platform rather than a spreadsheet.
In week eight, we hand over. We tune the controls, train your stewards to keep the catalogue current, and leave you with a runbook and a baseline your team owns.
The word "baseline" matters. We aren't trying to govern every dataset in the company in two months. We put your highest-risk domains under real, enforced control, and that gives you a pattern to extend. If you want ongoing support afterwards, we can run stewardship and catalogue operations alongside your team.
OrchV 8-week Data Governance baseline
The governance PDF still has a job. Regulators ask for it, and your people need a plain-language statement of how data should be handled. But it should describe controls that already run on your platform, not intentions that get checked once a year. When the policy, the catalogue and the access rules all say the same thing, an audit becomes a review instead of a scramble, and your AI pilots finally have the lineage they need to get signed off.
If your next evidence request means another round of tracing lineage by hand, there's a better use for those hours. Talk to us about the 8-week Data Governance baseline and turn your policy into controls you can prove. Reach us at **info@orchv.com**.
Tell us what you are working on, and one of our engineers will reply.