Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Ten data governance examples by industry, covering banking, insurance, telecom and healthcare, with the control that fixes each problem and the evidence a regulator asks to see.
Updated on
Most articles about data governance examples describe a discipline and leave the reader to work out what it means for their business. That gap is the reason a bank, an insurer, a telecom operator and a hospital all read the same governance advice and none of them can act on it, because the thing that changes between them is not the principle, it is the artefact somebody will eventually ask them to produce.
This article takes the opposite approach. Ten examples, each set in an industry Decube works in, each written to the same three part shape: the data problem as it actually shows up, the control that solves it, and the evidence a supervisor or an auditor asks to see. Financial services and telecommunications carry the most weight, because that is where the questions arrive most often, and healthcare, insurance and retail follow.
If you need the underlying definitions first, data governance concepts covers ownership, stewardship, policy and the operating model in one place. This page assumes them and goes straight to the worked examples.
A governance example fails the moment it becomes a slogan. "Establish clear data ownership" is true everywhere and usable nowhere. The examples below are written to a fixed shape, and the shape is the point.
One test separates a real control from a slogan. Ask who is on the hook when it fails, by name, and ask what file gets opened to show it worked. If neither question has an answer, what you have is an intention.
The data problem. An Indonesian bank holds customer identity fields in core banking, in loan origination, in the mobile app and again in the data warehouse. Personal data has been copied into analytics tables that nobody classified, access was granted table by table as projects needed it, and when a regulatory return is questioned nobody can say which copy of the customer record fed the number.
The control. A classification register covering every table and column that carries personal or account data, with one accountable owner per data domain, and access granted by classification rather than by table name. New tables inherit a classification at creation or they do not get served. The register is not a spreadsheet somebody maintains quarterly; it lives in the catalog next to the data and it is refreshed automatically when a source changes.
The evidence. The classification register with an owner name and a date against each domain. The quarterly access review showing who could read classified columns and what changed. Lineage from the source system through each transformation to the figure that appears in the return, so a challenged number can be traced without a project.
What the supervisor is working from. OJK regulates the financial services sector in Indonesia and expects a supervised institution to apply risk management to its use of technology and data, which in practice means being able to say what personal data it holds, where it sits and who can reach it. Indonesias Personal Data Protection Law, Law 27 of 2022, sits alongside that and gives the same questions a legal edge. A bank that can answer both from one register answers them in an afternoon. A bank that cannot answers them with a project.
If you are choosing a platform to sit under this, our comparison of data governance platforms for banks works through the requirements a regulated bank should be testing against.
The data problem. Risk and finance report the same exposure from two different pipelines and produce two different totals. Both are defensible internally and neither can be defended externally, because no one wrote down which field is authoritative, what quality rule it has to pass, or what happens when it fails.
The control. A critical data element register. Name the fields the capital, liquidity and operational risk returns depend on. Give each one an accountable owner and one authoritative source system. Attach a quality rule with a threshold to each, run the rule on every load, and route a breach to a named person rather than to a mailbox. Then hold lineage from that source field to the reported figure.
The evidence. The register itself. The quality test results over time, which matter more than a point in time pass because a supervisor wants to see the control operating. The lineage graph from source to return. The incident log for breached thresholds, with what was done and how long it took.
What the supervisor is working from. APRA's prudential standard CPS 234 requires a regulated entity to classify its information assets by criticality and sensitivity and to maintain controls sized to that classification, which is why an information asset register is the first thing asked for. CPS 230 on operational risk management extends the same logic to critical operations and to the service providers behind them. For larger banks the Basel Committees principles for effective risk data aggregation, known as BCBS 239, set the expectation that risk data can be aggregated accurately and quickly, which is a lineage requirement in everything but name.
The data problem. An underwriting or claims model consumes features built from data whose source, refresh cadence and quality nobody documented. When a state regulator asks why a claim was declined or why a premium was set where it was, the answer available internally is a model score, and the inputs behind it cannot be reconstructed for the date the decision was made.
The control. A model input register that ties every feature to the source column it derives from, its refresh schedule and the quality rule it has to pass, versioned so the state of the inputs on any past date can be reproduced. Around it, a documented review before any model or feature change reaches production, and the same treatment for models bought from a vendor as for models built in house.
The evidence. The feature to source mapping with versions and dates. The model documentation, including what it was tested for and by whom. The record of testing for unfairly discriminatory outcomes. The vendor oversight file for any third party model, because buying a model does not move the accountability.
What the supervisor is working from. The NAIC model bulletin on the use of artificial intelligence systems by insurers, adopted in December 2023 and taken up by a growing list of states, sets the expectation that an insurer maintains a written programme covering governance, risk management controls and third party vendor oversight for the AI systems behind insurance decisions, and that it can answer regulator questions about how those systems work. Almost all of that programme is a data governance question wearing a model governance label, because a model you cannot explain is usually a model whose inputs you never governed.
The data problem. An automated decision, a credit limit, a price, a fraud hold, is made from attributes nobody has justified. Some of them are proxies for characteristics the firm would never use directly, and the firm cannot tell, because there is no list of what the decision consumes.
The control. An accountability record for every automated decision that affects a customer. It names an internal owner, lists the attributes the decision consumes, states a justification for each attribute, marks the ones that carry proxy risk, and records a fairness assessment done before launch and repeated on a schedule afterwards. The record is versioned, so the firm can say which version made a decision on a given day.
The evidence. The attribute inventory with a justification against each entry. The fairness assessment with its metrics, its date and its author. The approval record from whoever signed it off. The ability to reproduce a single customer decision on request, which is the test that quietly fails most often.
What the supervisor is working from. MAS published principles for fairness, ethics, accountability and transparency in the use of artificial intelligence and data analytics in the financial sector, known as FEAT, and followed them with an industry programme that turned the principles into assessment methodology. The practical effect is that a Singapore firm is expected to be able to explain a data driven decision rather than only to make it, and explanation is an attribute inventory problem before it is a model problem.
The data problem. Consent is captured in four places, the CRM, the app, the retail till and the call centre, and the marketing platform reads a copy that is a day or two old. A subscriber withdraws consent in the app on Monday and receives a campaign on Wednesday. Nobody was careless. The record simply had four homes and no owner.
The control. One consent record per subscriber identity, held as master data with a defined authoritative source and a publish path to every consuming system. Withdrawal propagates as an event rather than as a nightly batch. A freshness rule fails loudly when a downstream system falls behind, and a suppression check runs before any campaign is released rather than after a complaint arrives.
The evidence. The consent record with a timestamp and the channel it was captured in. The propagation log showing when each downstream system received a change, which is what turns "we honour withdrawals" into a provable statement. The suppression test results for each campaign, kept with the campaign.
The scale is what makes this hard rather than the rule. A rule that is trivial for ten thousand customers becomes an engineering problem at tens of millions, and the failure is always the same shape: the rule was right and the copy was stale.
The data problem. Call detail records, network event logs and location data accumulate faster than anyone reviews them. A retention policy exists in a document, expressed in years, and nothing in the platform enforces it. Meanwhile the same records have been copied into three analytics environments and a backup vault, none of which the policy author knew about.
The control. A retention schedule bound to the data itself rather than to a policy document. Classification drives a retention period per table, a deletion job runs on that schedule and records what it removed, and an exception register holds anything under legal hold with the reason and the release date. Derived copies inherit the retention of their source, which is the rule that most programmes forget to write.
The evidence. The schedule mapped to physical tables rather than to categories. The deletion job run history with row counts, because a job that ran and deleted nothing is a failure that looks like a success. The legal hold register. Proof that derived copies and backups are covered, which is where most retention programmes are actually breached.
The data problem. Clinicians need wide access in an emergency, so access is granted widely and then never reviewed. Over a few years the effective read population for the most sensitive records in the hospital becomes larger than anyone intended, and nobody notices because nothing broke.
The control. Role based access matched to the classification of the record rather than to the system it sits in. An emergency access path that is always available and always logged, so clinical urgency never becomes a reason to weaken the default. Access recertification on a fixed cycle, where a named manager confirms each person still needs what they hold and inaction removes access rather than preserving it.
The evidence. The role to classification matrix. The emergency access log with a reviewed reason against each event, which is the artefact that makes emergency access acceptable. The recertification record with dates and approvers. The read audit trail on sensitive records, retained long enough to answer a complaint that arrives months later.
What the supervisor is working from. The HIPAA privacy rule requires reasonable efforts to limit uses and disclosures of protected health information to the minimum necessary for the purpose, which is an access control obligation stated as a privacy principle. A hospital that cannot show the effective read population for a record set cannot show it met that standard.
The data problem. A research group or an AI team needs patient data, and the fastest route to it is a copy of production into an analytics environment. It happens once as an exception, and the exception becomes the pipeline. Later, when a patient asks what their record was used for, the honest answer is that nobody tracked it.
This is not hypothetical, and the live version of this article already carried a version of it: a large health system drew scrutiny for putting AI transcription into clinical settings without clear patient consent. The lesson generalises. Consent given for care is not consent given for model training, and the distinction has to be held in the data rather than in a policy.
The control. A de identified or masked serving layer as the only supported route to secondary use, with a documented method: either the identifiers listed in the safe harbour approach removed, or a qualified expert determination that the re identification risk is very small. Project level approval recorded before access is granted, and a purpose recorded against each approved dataset so the question of what a record was used for has an answer.
The evidence. The de identification method documentation and the list of fields removed or transformed. The expert determination if that route was taken. The approval record per project with its purpose. Lineage showing each analytics table derives from the de identified layer and never from production, which is the one piece of proof that cannot be assembled retrospectively.
The data problem. The same shopper exists three times: a guest checkout, a loyalty member and an app user. Personalisation reads the merged profile, but consent was given by only one of the three identities, and the merge silently promoted it to all of them. The business sees a better customer view. The privacy team sees an unlogged change of legal basis.
The control. Identity resolution with a written merge rule, versioned, owned by a named person. Consent held against the resolved identity, with the most restrictive consent winning on merge rather than the most recent. A crosswalk from the merged profile back to every contributing record, so a merge can be explained and reversed. Deletion follows the crosswalk, not the profile.
The evidence. The merge rule and its version history. The crosswalk. A deletion test showing a single request reached every contributing record including the ones in the analytics copies. The consent state of the resolved identity with the date and source of each element.
The failure mode here is worth naming because it is not obvious. A wrong merge in retail looks like a small personalisation error. The same wrong merge mixes two peoples purchase histories, their addresses and their consent choices, and in a jurisdiction with a data protection regulator that is an incident rather than a defect.
The data problem. An assistant or an autonomous agent is given warehouse access so it can answer questions, and it reads whatever its credentials allow. Nobody can say what it read, on whose behalf, or which tables produced a given answer. The access was granted once, to a service account, for a pilot.
The control. Agents registered as first class data consumers with their own identity rather than a shared service account. Their permission scope expressed against the classification register, so an agent inherits the same restrictions a person would. Every read logged with the agent, the requesting user and the purpose. Outputs traceable back to the tables behind them.
The evidence. The agent register with an owner per agent. The permission scope per agent, reviewed on the same cycle as human access. The read log. Lineage from an answer back to the source tables, which is what turns an AI output into something a risk function can sign off.
What the supervisor is working from. Obligations for general purpose AI models under the EU AI Act have applied since 2 August 2025 for models placed on the market from that date, the Commission's enforcement powers apply from 2 August 2026, and models placed on the market before 2 August 2025 have until 2 August 2027. The EU AI Act's Article 50 transparency rules were not changed and apply from 2 August 2026, and the Digital Omnibus, which entered force on 27 July 2026, did not move either of them. The Omnibus did shift the high risk obligations to 2 December 2027 for standalone systems and 2 August 2028 where the AI is embedded in a regulated product. A great deal of published guidance still quotes the older dates. If you are building the governance layer for this now, agentic AI data governance goes further into the control model.
The table below is the article in one view. It is also the fastest way to find the row that matches your own week.
| Example | The data problem | The control | The evidence a supervisor asks for |
|---|---|---|---|
| 1. Banking, Indonesia (OJK) | Personal data copied into unclassified analytics tables; no one can say which copy fed a regulatory return | Classification register in the catalog, one accountable owner per domain, access granted by classification | Register with owners and dates, quarterly access review, lineage from source to reported figure |
| 2. Banking, Australia (APRA) | Risk and finance report the same exposure from two pipelines and disagree | Critical data element register with an authoritative source, a quality rule and a threshold per field | The register, quality results over time, lineage to the return, incident log for breaches |
| 3. Insurance, United States (NAIC) | A model declines a claim and its inputs cannot be reconstructed for the decision date | Versioned model input register mapping every feature to a source column, plus documented change review | Feature to source mapping, model documentation, discrimination testing record, vendor oversight file |
| 4. Financial services, Singapore (MAS) | An automated decision consumes attributes nobody has justified, some of them proxies | Accountability record per decision: owner, attribute list, justification, proxy risk flags, fairness assessment | Attribute inventory with justifications, fairness assessment, approval record, reproduction of a single decision |
| 5. Telecommunications, consent | Consent lives in four systems and the marketing platform reads a stale copy | One consent record per subscriber identity, event driven propagation, freshness rule, suppression check before release | Consent record with timestamp and channel, propagation log per system, suppression test per campaign |
| 6. Telecommunications, retention | Network and call records accumulate past their retention period across copies nobody mapped | Retention bound to classification, automated deletion, exception register for legal hold, derived copies inherit retention | Schedule mapped to physical tables, deletion run history with row counts, legal hold register, backup coverage proof |
| 7. Healthcare, access | Emergency access grants became permanent and the effective read population grew unnoticed | Role based access tied to record classification, logged emergency access path, recurring recertification | Role to classification matrix, emergency access log with reviewed reasons, recertification record, read audit trail |
| 8. Healthcare, secondary use | Production data copied for research and AI, with no record of what a patient record was used for | De identified serving layer as the only route, documented method, project approval with a recorded purpose | Method documentation, removed field list, expert determination, per project approval, lineage from the de identified layer |
| 9. Retail and ecommerce | Identity merge promotes one consent to three identities without a logged change of legal basis | Versioned merge rule with a named owner, most restrictive consent wins, crosswalk to contributing records | Merge rule versions, crosswalk, deletion test across every contributing record, consent state with dates |
| 10. Every industry, AI agents | An agent reads whatever its shared service account allows and nobody can say what it read | Agents registered with their own identity, scope expressed against the classification register, every read logged | Agent register with owners, permission scope per agent, read log, lineage from an answer to its source tables |
The obligations below are the ones that turn into data work. They are summarised at the level the published instruments support, and the sources are listed at the end of this article.
| Supervisor or instrument | Market | What it means for your data | The artefact it turns into |
|---|---|---|---|
| OJK, with Law 27 of 2022 alongside it | Indonesia, financial services | Know what personal data the institution holds, where it lives, and who can reach it, under a risk management framework for technology use | Classification register with named domain owners and an access review record |
| APRA prudential standard CPS 234 | Australia, banking, insurance and superannuation | Classify information assets by criticality and sensitivity, and size controls to that classification | Information asset register, tied to the systems that hold each asset |
| APRA prudential standard CPS 230 | Australia, banking, insurance and superannuation | Identify critical operations and the service providers behind them, and manage the operational risk across both | Critical operation and service provider register, with the data each one depends on |
| Basel Committee principles BCBS 239 | Global, larger banks | Aggregate risk data accurately and quickly, including under stress, with a clear line back to source | Critical data element register and end to end lineage to the reported figure |
| NAIC model bulletin on AI systems | United States, insurance | Maintain a written programme for the AI systems used in insurance decisions, covering governance, risk controls and vendor oversight | Model input register, model documentation, testing record, vendor oversight file |
| MAS FEAT principles | Singapore, financial services | Be able to justify and explain data driven and AI driven decisions that affect customers | Attribute inventory with justifications, and a dated fairness assessment per decision |
| HIPAA privacy rule | United States, healthcare | Limit uses and disclosures of protected health information to the minimum necessary, and apply a recognised method when data is de identified | Role to classification matrix, access recertification record, de identification method documentation |
| EU AI Act | European Union, all sectors | GPAI obligations have applied since 2 August 2025 for models placed on the market from that date, with models on the market before it having until 2 August 2027 and Commission enforcement powers from 2 August 2026. Article 50 disclosure applies from 2 August 2026. High risk duties move to 2 December 2027 and 2 August 2028 after the Digital Omnibus | Agent and model register, permission scope, read log, lineage from output to source |
Every control above resolves to a dictionary entry somewhere, and a dictionary entry that carries only a field name and a description is decoration. A useful entry carries the attributes that access, quality and retention are granted from, which is why the entry looks different in each industry. Below is the same customer identifier field as three different dictionary entries.
| Attribute in the entry | Bank (Indonesia or Australia) | Hospital | Telecom operator |
|---|---|---|---|
| Business definition | The unique identifier for a banking relationship holder, one per legal person | The unique identifier for a patient across every episode of care | The unique identifier for a subscriber, distinct from the SIM and the account |
| Authoritative source | Core banking, never the warehouse copy | The patient administration system, never a departmental system | The CRM, with the app and the retail till as writers rather than owners |
| Classification | Personal data, restricted | Protected health information, restricted, and often a higher tier for behavioural and sexual health records | Personal data, restricted, with location derived fields treated separately |
| Accountable owner | Named head of customer data in retail banking | Named clinical information owner, usually with the privacy officer countersigning | Named subscriber data owner in the customer function |
| Quality rule and threshold | Uniqueness and completeness on identity fields, breach routed to the named owner | Uniqueness across episodes, with duplicate patient records treated as a clinical safety issue | Uniqueness against the consent record, checked before every campaign release |
| Retention | Set by financial records rules and by the customer relationship end date | Set by clinical records retention, typically far longer than commercial data | Set by the shortest of the commercial rule and the lawful basis for the derived records |
| Special attributes | Whether the field feeds a regulatory return, and which one | Whether the field survives de identification and by which method | Whether the field is consent bearing, and which consent record governs it |
The test for a dictionary is whether anything is granted from it. If access, quality and retention are still decided in three other places, the dictionary is a glossary and it will be out of date within a year.
This distinction is worth keeping because it decides who owns which problem, and because mixing the two is how governance programmes end up with two committees and one budget.
Information governance covers unstructured content: documents, contracts, email, recordings and the records retention schedule that sits over them. It is usually owned by legal, compliance or a records function. Data governance covers structured and semi structured data in databases, warehouses and lakes, and it is usually owned by a data function reporting to a chief data officer or an equivalent.
| Dimension | Data governance | Information governance |
|---|---|---|
| What it covers | Structured and semi structured data in databases, warehouses, lakes and streams | Unstructured content: documents, contracts, email, recordings, images |
| Typical owner | Data function, chief data officer or head of data | Legal, compliance or a records management function |
| Main artefacts | Classification register, data dictionary, quality rules, lineage, access model | Records retention schedule, classification taxonomy, legal hold process, disposal certificates |
| How retention is expressed | A period per table or dataset, enforced by a job | A period per record class, enforced by a records system and by policy |
| Where they meet | The same personal data appears in both, so classification and retention have to agree across the two | A legal hold on a matter has to reach the structured data, not only the document store |
The practical failure is always at the join. A legal hold is placed on a matter, the document store honours it, and the deletion job in the warehouse keeps running because nobody told it. Whichever function owns the join should be named, and the honest answer in most organisations is that nobody currently does.
A data governance strategy is a short set of decisions rather than a document listing principles: which data you will govern first, who is accountable for it, and what you will be able to prove by a date. The examples above give you the shape; the sequence below turns them into a plan.
Sequence matters more than ambition. One return, governed end to end with evidence a supervisor accepts, is worth more than a classification exercise across the whole estate that nobody can point at a decision.
Decube is a platform for the layer these examples all depend on, which is knowing what data you hold, whether it is fit to use, and where a number came from. Decube data governance covers ownership, classification, policy and the catalog surface that makes a classification register something people actually use rather than a spreadsheet that ages. Automated crawling keeps that metadata current once a source is connected, which removes the manual update cycle that kills most registers in their second year, and access to view or change data can be routed through an approval flow.
The evidence half is lineage and monitoring. Column level data lineage traces a value from the source system through every transformation to where it lands, which is the answer to the question an APRA or OJK supervisor asks about a reported number and the answer to the question a business user asks when a figure looks wrong. Alongside it, pipeline observability finds the breaks, and quality suggestions from Decube CoPilot propose the tests that turn a quality rule into a result somebody can read.
Decube holds GDPR, HIPAA, SOC 2 and ISO 27001 alignment, which matters when the platform itself becomes part of what a supervisor reviews. If you want to see what these examples look like against your own sources, you can request a demo.
The examples worth copying are described by control rather than by company name, because the control is what transfers. A bank builds a classification register and grants access by classification. Another bank builds a critical data element register with a quality rule and a threshold on each field behind its regulatory returns. An insurer builds a versioned model input register so an underwriting decision can be reconstructed. A telecom operator holds one consent record per subscriber and propagates withdrawal as an event. A hospital ties access to record classification and logs every emergency access. Each of those is a company example with the company name removed and the mechanism left in.
A data governance strategy is a short set of decisions about which data you govern first, who is accountable for it, and what you will be able to prove by a date. It is not a list of principles. The examples fit in as the delivery unit: pick a report or a regulatory return that somebody outside the data team already cares about, name one accountable owner for the data behind it, write down the evidence you will hand over when asked to prove the control ran, and build only the controls that produce that evidence.
The clearest scenario is one where two teams report the same number differently and neither can prove which is right. Risk and finance disagree on an exposure, marketing and the call centre disagree on whether a customer consented, or a research team and a privacy team disagree on whether a dataset is de identified. In each case the fix is the same shape: name the authoritative source, attach a quality rule and an owner to it, and hold lineage from that source to the number in dispute.
A data dictionary entry in a real programme carries more than a description. For a bank it records the field name, the business definition, the authoritative source system, the classification, the accountable owner, the quality rule and threshold, and the retention period. For a hospital it adds whether the field is protected health information and whether it survives de identification. For a telecom operator it adds whether the field is consent bearing. The dictionary becomes useful at the point where access and retention are granted from it rather than from a separate spreadsheet.
OJK supervises the financial services sector in Indonesia and expects a supervised institution to apply risk management to its use of technology and data. In practice that means being able to say what personal data the bank holds, where it lives, who can reach it, and how a reported figure traces back to its source. Indonesia introduced a Personal Data Protection Law, Law 27 of 2022, which asks the same questions with a legal consequence attached. A classification register with named owners, an access review record and lineage to the reported figure answers both.
APRA prudential standard CPS 234 requires a regulated entity to classify its information assets by criticality and sensitivity and to maintain controls sized to that classification, which is why an information asset register is usually the first artefact requested. CPS 230 extends the same logic to critical operations and the service providers behind them. For larger banks the Basel Committee principles known as BCBS 239 add the expectation that risk data can be aggregated accurately and quickly, which in practice is a lineage requirement.
The NAIC model bulletin on the use of artificial intelligence systems by insurers, adopted in December 2023 and taken up by a growing list of states, sets the expectation that an insurer maintains a written programme covering governance, risk management controls and third party vendor oversight for the AI systems behind insurance decisions, and that it can answer regulator questions about how those systems work. Models bought from a vendor are covered on the same terms as models built in house.
MAS published principles for fairness, ethics, accountability and transparency in the use of artificial intelligence and data analytics in the financial sector, known as FEAT, and followed them with an industry programme that turned the principles into assessment methodology. The practical expectation is that a firm can explain a decision that affects a customer, which means holding an inventory of the attributes the decision consumes with a justification against each, a dated fairness assessment, and the ability to reproduce a single decision on request.
The discipline is the same and the artefacts differ. A bank governs to prove a reported number is traceable, so its central artefacts are a critical data element register and lineage from source to return. A hospital governs to prove only the right clinician read a record and that secondary use was authorised, so its central artefacts are a role to classification matrix, an emergency access log with reviewed reasons, and de identification method documentation. The owner differs too: finance and risk in a bank, clinical governance and privacy in a hospital.
Data governance covers structured and semi structured data in databases, warehouses, lakes and streams, and it is usually owned by a data function. Information governance covers unstructured content such as documents, contracts, email and recordings, and it is usually owned by legal, compliance or a records function. They meet wherever the same personal data appears in both, so classification and retention have to agree across them. The common failure is a legal hold that the document store honours while the deletion job in the warehouse keeps running.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Book a 30-min demo with us and see how lineage, quality, governance, and compliance come together in a single platform.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)