I talk to IT managers at mid-market companies every week. Companies with 200, 500, maybe 1,500 people. They all know their master data is a mess. They all want governance. And they all tell me the same thing: "We don't have the headcount for a data governance team."
They're right that they can't build the kind of governance program Gartner writes about. The kind with a Chief Data Officer, a governance council, a steering committee, and a team of six data stewards. That model costs $500K+ per year in salaries alone. It was designed for banks and pharmaceutical companies, not for a logistics firm running three DBAs and an ERP that's been in production since 2014.
But they're wrong that governance requires all that. The version that works at mid-market scale is smaller, cheaper, and frankly more practical.
Governance is just three questions answered clearly
Strip away the frameworks and maturity models, and governance comes down to three things:
Who owns this data?
When the supplier list has duplicates, whose phone rings?
Who can change it?
Can anyone edit a cost center, or does finance approve those?
How do you know what changed?
When a product classification shifts and the BI report breaks, can you trace it back in five minutes?
If you can answer those three questions for your most important data domains, you have governance. Maybe not the kind that wins awards at data management conferences. But the kind that stops the same supplier from getting created four times in your ERP.
Use the people who already know the data
The enterprise model hires data stewards as a job title. Mid-market companies can't afford that, and honestly most don't need it. The people who know your supplier data best already work in procurement. The person who understands cost center hierarchies sits in finance. The product master? That's someone in operations or product management.
These people are already doing informal governance. When the ERP has bad data, they get called. When someone needs a new supplier created, they get an email. When the quarterly report looks wrong, they're the ones digging through records to figure out why.
The difference between informal and formal governance is this: informal governance relies on tribal knowledge and email chains. Formal governance gives those same people actual tools. Permissions that restrict who can edit what. Validation rules that reject bad data before it enters the system. Approval workflows that route changes through the right person. An audit trail that answers "who changed this?" without digging through backup tapes.
The steward role is a hat someone wears for two to four hours a week. It is not a full-time position. A procurement manager who spends 30 minutes reviewing supplier change requests each morning is doing more governance than most enterprise programs achieve with twice the headcount.
Start with one domain, not a grand strategy
The biggest mistake I see: mid-market IT teams try to govern everything at once. They draw up a roadmap covering customers, suppliers, products, locations, employees, cost centers, and materials. Then they stall, because governing eight domains simultaneously requires eight domain owners, eight sets of validation rules, and eight conversations with business stakeholders who don't have time for meetings about "data governance maturity."
Instead: pick the one domain that hurts most. Usually suppliers or customers. Set it up properly. Show the business what "governed data" looks like in practice. Then expand.
A realistic first-domain rollout
Four weeks to have one domain governed. Not perfect. Not comprehensive. But working. The second domain goes faster because the process is already established and the tool is configured.
The tool does the enforcement, not the people
Here's the part that trips up small teams: they assume governance means more meetings, more process documents, more overhead. And with the wrong tools, it does. If your "MDM tool" is a shared Excel file on SharePoint, governance means emailing people not to edit certain columns and hoping they listen.
A proper MDM tool flips that. The rules live in the system. A junior clerk cannot edit a supplier bank account because the permissions model does not let them. A new product cannot be created without a valid category because the validation rule rejects it. A cost center rename goes through the finance lead for approval because the workflow is configured that way.
Nobody needs to remember the rules. Nobody needs to be reminded. The system handles enforcement. People handle judgment.
What "good enough" governance looks like
I am not pretending mid-market governance is the same as what a regulated bank runs. It's not. And it shouldn't be. Here is what "good enough" looks like for a 500-person company:
Ownership
Nobody owns supplier data. Everyone edits it. Nobody cleans it.
Procurement owns it. Three people can edit. Changes to bank details require approval.
Validation
Any value in any field. Duplicates everywhere.
Required fields enforced. Duplicate check on name + tax ID. Domain attributes for country/currency.
Audit
"Who changed this?" Answer: nobody knows.
Full field-level history. Weekly review of sensitive changes.
Process
Email requests, verbal approvals, hope.
Submit change, owner reviews, approve or reject with comment.
None of this requires a governance council or a maturity assessment. It requires one domain owner who cares, one MDM tool that enforces rules, and an IT team willing to spend a few hours setting it up.
Why most governance initiatives die
I have watched this pattern repeat at least a dozen times. A company decides they need data governance. They hire a consultant. The consultant delivers a 60-page framework with a maturity model, a RACI matrix, and a three-year roadmap. Management nods. IT is assigned to "implement the governance program." Six months later, the framework is in a drawer, the RACI matrix was never updated, and the data is exactly as messy as before.
The initiative dies because it was designed around organizational change instead of tooling. It assumed that if you document enough processes and assign enough roles, behavior changes. It doesn't. Behavior changes when the system makes the right thing easy and the wrong thing hard.
A validation rule that blocks a missing tax ID does more for data quality than a 40-page governance charter. An approval workflow on bank account changes does more for fraud prevention than a quarterly data quality review meeting.
The mid-market advantage
Large enterprises spend years standing up governance programs because they have thousands of data producers, dozens of source systems, and political dynamics that make domain ownership a negotiation exercise. Mid-market companies have none of that. You probably know the five people who touch your critical data by name. Getting them in a room takes 15 minutes, not six months of committee scheduling.
That's a real advantage. Use it. The smaller the organization, the faster governance can move from concept to working system.
Common questions
Do you need a dedicated team for data governance?
No. Most mid-market organizations (100 to 2,000 employees) run data governance successfully without a dedicated team. The key is assigning clear ownership of specific data domains to people who already work with that data daily — finance owns cost center hierarchies, procurement owns supplier records, HR owns employee classifications. An MDM tool with built-in permissions and approval workflows enforces the rules so you do not need a full-time governance staff.
How do you start a data governance program with limited resources?
Start with one high-pain data domain — usually suppliers or customers. Assign an owner (the person who gets called when that data is wrong). Define who can edit, who approves changes, and what validation rules apply. Put the data in a central system with audit logging. Measure the before and after: hours spent on manual fixes, duplicate records, failed integrations. Expand to the next domain only after the first one is stable. Most mid-market teams cover their three or four critical domains within six months.
What is the difference between data governance and data management?
Data management is the technical work: storing data, moving it between systems, backing it up, running ETL jobs. Data governance is the organizational layer on top: who owns the data, who can change it, what rules apply, how changes are approved, and how quality is measured. You can do data management without governance (most companies do), but you cannot do governance without some form of management. An MDM tool combines both — it manages the data centrally while enforcing governance rules like permissions, validation, and approval workflows.
What does a data steward do in a mid-market company?
In a mid-market company, a data steward is usually someone with a different primary job title — a senior buyer, a finance analyst, an operations lead — who also owns the quality of a specific data domain. They review change requests, resolve duplicates, define validation rules, and serve as the point of contact when downstream systems have data quality issues. They spend perhaps two to four hours per week on stewardship, not forty. The MDM tool does the enforcement; the steward provides the judgment.
Governance without the overhead
Primentra gives your existing team the tools to govern data properly: permissions, validation rules, approval workflows, and a full audit trail. It runs on SQL Server, deploys in a day, and costs €7,500 per year flat. No per-user fees, no consultants needed. The 60-day trial includes everything.