A data governance framework is the set of rules, roles and processes that decides who owns each piece of company data, how it is defined, what quality it must meet and who may access it. The aim: everyone trusts the same number. Start small: name an owner, write a definition and measure quality for a handful of critical fields.
Three different revenue figures in one meeting
In the monthly management meeting, the sales director quotes one revenue figure, finance quotes a lower one, and production planning offers a third based on shipments. Nobody is wrong. Each is reading the "revenue" field in their own system: one counts orders, one counts invoices, one counts delivery notes. The first half hour goes on arguing about the number, and the decision slips to next month.
Customer records tell the same story. One company appears three times in the ERP under slightly different spellings, the CRM is missing its tax number, and the address used for e-invoicing is out of date. We looked at that problem in detail in our guide to data quality and duplicate records. Cleaning duplicates is a one-off job; stopping them coming back is a governance job.
Data governance is often treated as something for banks and large groups. In practice the problem does not depend on size. A 40-person manufacturer and a 400-person logistics firm both ask the same question: "Who produced this figure, how was it calculated, and how do we know it is right?"
What distrust in data costs
Having data is not the same as trusting it, and international research puts numbers on the gap:
In a survey of 565 data and analytics professionals by Drexel University's LeBow College of Business and data software company Precisely, 76% named data-driven decision-making as the top goal of their data programmes, yet 67% said they don't fully trust the data their organisation uses. (Drexel LeBow & Precisely, 2025 Outlook: Data Integrity Trends and Insights)
In the same survey, respondents named a lack of data governance, cited by 62%, as the top data challenge holding back AI initiatives, and only 12% said their data is AI-ready. The obstacle to an AI project is usually not the model but the data underneath it, a point we also make in where to start with AI in your business.
The financial effect of bad data is not small either. Data quality expert Thomas C. Redman, writing in MIT Sloan Management Review, "Seizing Opportunity in Data Quality" in 2017, estimates the cost of bad data at 15% to 25% of revenue for most companies. That is an expert estimate rather than a measurement, but once you add up wrong shipments, rejected invoices, rework and delayed decisions, the direction it points in is hardly surprising.
In Türkiye the basic infrastructure is still being put in place. According to the TurkStat ICT Usage in Enterprises Survey 2025, 28.3% of enterprises with 10 or more employees used ERP software and only 6.5% used business intelligence (BI) software. For a business just starting to report properly, that is an opportunity: set the rules first and you greatly reduce the clean-up later.
What data governance is, and what it is not
Data governance is neither a piece of software nor a department. It is the arrangement that decides how decisions about data get made. Separating it from the terms it is often confused with helps at the start:
| Discipline | The question it asks | Typical output |
|---|---|---|
| Data governance | Whose data is this, what are the rules, who decides? | Ownership list, data policy |
| Data quality | Is the data accurate, complete and current? | Quality rules and a scorecard |
| Data management | How is data stored, moved and backed up? | Data warehouse, ETL, backups |
| Data security | Who can reach the data, and how? | Role and permission matrix, access logs |
| KVKK compliance | Is personal data processed lawfully? | Inventory, privacy notices, retention policy |
Governance sits above these and steers them. A data warehouse and ETL pipeline brings data together technically, but it is governance that decides which system is the master for "customer".
A data governance framework in 7 steps
The steps below are designed for a mid-sized business without a full-time data team. You do not need to do them all at once; the first three alone make a noticeable difference.
- Pick the critical data fields. Do not start with everything. List the 10 to 20 fields argued about most in management meetings: customer, product code, revenue, order status, stock quantity. It makes sense to do this alongside setting your KPIs; if you do not measure it yet, you do not need to govern it yet.
- Give every field an owner. The owner is the business manager accountable for the field's definition and quality, not IT. Customer records belong to sales, product master data to production or purchasing, supplier and customer accounts to finance. Bringing that master data together into one record across systems is the work of master data management (MDM).
- Write the business glossary. For each critical term: a one-sentence definition, the calculation rule, the source system and the update frequency. For example, "Revenue = excluding VAT, net of cancellations and returns, by invoice date". Technical definitions of tables and fields (type, length, allowed values) live separately in a data dictionary; we explain how the two connect in data catalog and data dictionary.
- Set quality rules and measure them. Mandatory fields, format rules (a Turkish company tax ID has ten digits), uniqueness (no second record with the same tax number) and timeliness. Track the error rate for each rule every week.
- Define access by role. Who reads, who edits, who deletes? Permissions go to roles, not individuals, and a leaver's access closes on their last day. The document side of this is covered in our guide to file sharing permissions, and the boundaries for users building their own reports in self-service analytics governance.
- Flag personal data separately. Which fields are personal data, which are special category data, and how long are they kept? This must match your KVKK personal data inventory; our data retention and disposal policy guide explains how retention periods are set.
- Agree how changes and disputes are handled. Creating a field, changing a definition or settling a "which number is right" dispute between two departments needs a named decision-maker. A short monthly data council meeting is enough for most businesses.
Roles: who does what?
- Data owner (business manager): approves the definition, sets the quality target and approves access requests.
- Data steward (practitioner): monitors quality day to day and corrects, or gets corrected, bad records. Do not confuse this internal role with the "data controller" under KVKK: the natural or legal person that determines the purposes and means of processing, which in most cases is the company itself.
- IT / system administrator: applies the rules in systems, keeps access logs and runs the integrations.
- Data council: a small group of owners that resolves disputes and sets priorities.
Definitions must hold not only in month-end reports but on live screens too. If a "late order" is calculated differently on a live panel than in the month-end report, the two will contradict each other; we cover that trap in our guide to real-time reporting. The same principle applies to field data: the quality of any route optimisation project depends on customer addresses coming from a single, correct source.
Where data governance meets KVKK
KVKK, Law No. 6698 on the Protection of Personal Data, is Türkiye's main data protection law and was largely modelled on the EU's earlier data protection framework. Together with its secondary regulations, it expects a data controller to know why personal data is processed, who it is transferred to and how long it is kept. Those facts underpin privacy notices, and organisations required to register with VERBİS must also maintain a personal data inventory and a retention and disposal policy. That is exactly what data governance asks for anyway: an owner, a purpose and a retention period for every field. Running the two exercises separately means maintaining two versions of the same inventory.
In practice, adding three columns to the data dictionary is enough: is it personal data, what is the purpose, what is the retention period? Your KVKK compliance programme inventory and your reporting dictionary then draw on the same source. AI projects that touch personal data need a separate assessment on top; we cover that in our guide to AI and KVKK.
How we do this at Digital Bridge
We do not hand over a binder of policies and walk away; we build the rules into the systems people actually use. A typical engagement runs like this:
- Discovery and requirements analysis. We review your systems (ERP, CRM, production, spreadsheets) and the reports management relies on, then map where the most disputed figures come from and how they are calculated. This is the starting point of our data governance and quality service.
- A pilot area. We usually start with customer or product master data. Owners are named, the business glossary is written, quality rules are defined and the error rate appears on a scorecard. Because the pilot is measurable, the decision to expand is made on evidence.
- Integration and a single source. We build checks that apply quality rules at the moment of entry, matching between systems and a shared reporting layer. Where reports draw on several sources we design a data warehouse, and we automate data flows between systems through system integrations.
- KVKK alignment. We map the data dictionary to your personal data inventory and, where needed, prepare retention, disposal and privacy notice processes through our data protection compliance consultancy.
- Making it visible. Once definitions are settled, the data goes onto a management dashboard (BI), so everyone in the meeting looks at the same figure.
Business email and documents are part of access governance too. Our own product, Smart360, manages SmartMail and SmartFiles under a single identity: when someone changes department their access changes across every product, and a leaver's access closes in one step. It is a concrete example of enforcing a permission rule in the system rather than on paper.
Data is only one dimension of an organisation's overall digital maturity; for the seven-dimension method, see our article on digital maturity assessment.
Your next step
There is one thing you can do this week: write down the three figures argued about most in management meetings, and for each one note its source, calculation rule and the person responsible. The empty cells show where governance work should begin. Bring that list to us through our contact page; we will review your systems with you and propose the first pilot area and its scope in writing. For more guides on this subject, see our Data & Analytics hub.