Most data governance programs start the same way: a compliance deadline forces a cleanup sprint, the spreadsheet gets fixed, and six months later the same errors are back. That cycle is the clearest sign that governance was treated as a project instead of an operating model.
In financial services, insurance, healthcare, and gaming, that distinction now has real financial and regulatory consequences. Data privacy law, industry-specific rules, and the first wave of AI governance requirements are converging on the same demand: prove where your data came from, prove it is accurate, and prove who can access it. Organizations that build durable governance capability answer those questions in minutes. Organizations that treat governance as a one-time cleanup answer them with a scramble.
This post is a companion to Data Infrastructure for Regulated Industries: Why It Wins, which covers the Informatica and MuleSoft technology stack behind KYC/AML, GDPR, and operational efficiency use cases. This post goes deeper on the governance and organizational side — the people, processes, and operating model that make that technology stack actually work.
Data governance is the ongoing discipline of managing data quality, lineage, and access so an organization can trust and prove what it knows about its data at all times. It matters most to compliance, risk, data, and IT leaders in regulated industries — financial services, insurance, healthcare, and gaming — who face overlapping privacy, sector-specific, and now AI-governance requirements. The decision this article helps with is whether to keep treating governance as a periodic cleanup or to build it as a permanent operating model with clear ownership. Vantage Point implements the technology (Informatica, MuleSoft, Salesforce Data 360) and helps design the operating model — stewardship roles, a governance council, and executive sponsorship — that makes the technology sustainable.
Data governance is the set of policies, roles, and controls that determine how an organization creates, maintains, protects, and uses its data. It answers three standing questions at all times, not just during an audit: Is this data accurate? Where did it come from and where did it go? Who is allowed to see or use it, and can we prove that?
Data governance is not a data cleanup, a one-time deduplication project, or a tool purchase. Migrating to a new CRM, merging duplicate records, or buying a data catalog are useful actions, but none of them are governance on their own — they're governance inputs that decay without ongoing ownership. A cleanup fixes today's data. Governance keeps tomorrow's data clean, with defined owners, defined metrics, and a recurring review cycle rather than an end date.
Every mature governance program rests on three interdependent pillars. Weakness in any one undermines the other two.
Data quality measures whether data is accurate, complete, consistent, and timely enough for the decision or compliance obligation it supports. A KYC record with a stale address, a duplicate customer profile split across two systems, or a claims record missing a required field are all quality failures — and each creates compliance exposure, not just inconvenience.
Data lineage documents where data originated, every transformation it passed through, and every system it landed in. It turns "we believe this number is correct" into "here is the exact chain that produced this number." GDPR's Article 30 recordkeeping requirement and the EU AI Act's data provenance requirement both depend on lineage being documented, not reconstructed after the fact.
Data access governance defines who can view, modify, or export specific data, under what conditions, and what gets logged when they do. This is the pillar regulators test most directly: not just "did you restrict access to sensitive data" but "can you show us the log."
| Pillar | Core question | Failure mode | Typical control |
|---|---|---|---|
| Data quality | Is it accurate, complete, and current? | Duplicate or stale records drive wrong decisions | Profiling, cleansing, matching, and standardization rules |
| Data lineage | Where did it come from and where did it go? | "We don't know why this number is wrong" | Automated, code-level lineage capture across ETL, SQL, and reports |
| Data access | Who can see it, and can we prove that? | Over-broad access, no audit trail | Role-based policies, field/record-level masking, access logging |
Regulatory pressure on data governance is not new, but the number of overlapping regimes — and the specificity of what each one requires — has grown substantially. Cross-industry organizations increasingly answer to several of the following at once.
| Regulation | Applies to | Core data governance requirement |
|---|---|---|
| GDPR (EU) | Any organization processing EU residents' personal data | Accuracy, purpose limitation, and storage limitation (Article 5); a documented Record of Processing Activities (Article 30) |
| CCPA/CPRA, enforced by the California Privacy Protection Agency | Businesses handling California consumer data | Consumer access, deletion, and correction rights; data inventories; risk assessments for automated decision-making |
| GLBA Safeguards Rule (US financial services) | Banks, lenders, insurers, and other financial institutions | A written information security program, a data inventory, and defined access controls |
| HIPAA Security Rule (US healthcare) | Covered entities and business associates | Administrative, physical, and technical safeguards, including access controls and audit logging of protected health information |
| MiFID II (EU financial markets) | Investment firms and trading venues | Accurate transaction reporting and multi-year record retention with demonstrable data quality |
| EU AI Act, Article 10 | Providers and deployers of high-risk AI systems | Documented data governance covering training data relevance, representativeness, and error rates, plus provenance |
| NIST AI Risk Management Framework | Any organization managing AI risk (voluntary in the US) | Govern, Map, Measure, and Manage — including data provenance and quality controls across the AI lifecycle |
The common thread across all seven is documentation, not aspiration. Every one of these regimes asks an organization to produce evidence — a report, a log, a lineage graph — on demand. Policy statements without operational proof do not satisfy any of them.
A timing note: the EU AI Act's high-risk obligations under Annex III were originally set for August 2, 2026. The European Commission's "AI Omnibus" simplification package — in force since July 2026 — deferred that deadline to December 2, 2027 (Annex III) and August 2, 2028 (Annex I). Article 50 transparency obligations were not deferred and took effect on schedule. The deadline moved; the underlying data governance requirement did not. Confirm current status against the Commission's own AI Act pages before relying on any single date.
Governance capability tends to progress through five recognizable stages. Most organizations in regulated industries are further behind than they assume.
| Stage | What it looks like | Typical blocker |
|---|---|---|
| Ad Hoc | No formal ownership; issues are discovered by accident, usually after something breaks | No shared understanding that governance is a discipline, not a task |
| Reactive | Issues get fixed after an audit finding, incident, or regulator request; governance is firefighting | No dedicated budget, role, or process — fixes happen, then decay |
| Defined | Written policies exist; data owners are named; a catalog of critical data elements exists | Policies exist on paper, but enforcement is inconsistent day to day |
| Managed | A governance council meets on a schedule; stewards actively enforce policy; quality and lineage are monitored with metrics | Requires real executive sponsorship and dedicated steward time, not a side-of-desk assignment |
| Optimized | Governance is built into system design; quality and lineage checks run automatically; AI systems inherit governance controls by default | Requires sustained investment and genuine cultural buy-in across teams |
Most organizations plateau at Reactive. They have processes for responding to problems, but nothing that prevents the next one. The jump from Reactive to Defined — and from Defined to Managed — is where most programs stall, because it requires two things at once: technology that can enforce policy automatically (a catalog, quality rules, access controls) and organizational change that assigns real ownership to real people. Buying a data catalog without naming stewards produces an unused catalog. Naming stewards without giving them tooling produces well-intentioned people doing manual work that doesn't scale. Both have to move together.
Each pillar of governance maps to a specific part of the technology stack. None of the three tools below is a complete governance solution by itself — together, they cover quality, lineage, integration governance, and access in a way no single platform does alone. For a deeper comparison of what each platform does and doesn't cover, see Data 360 vs. Informatica vs. MuleSoft: What Each Does.
Informatica covers data quality and lineage at the source. Its data quality tools profile, cleanse, and standardize records, while its data catalog uses the CLAIRE AI engine to automate metadata discovery and classification. Its lineage capability parses code directly — SQL, stored procedures, ETL jobs, and BI reports — to build automated, column-level lineage rather than relying on diagrams that go stale.
MuleSoft covers integration and API governance — whether data moving between systems follows any consistent rule at all. Anypoint API Governance applies governance rulesets to APIs, integration flows, AI agents, and MCP servers across their full lifecycle, from specification at design time to gateway-enforced policy at deployment, with a dashboard showing conformance across the whole portfolio.
Salesforce Data 360 covers policy-based access governance on unified customer data: field-, object-, and record-level policy enforcement; AI-assisted tagging that labels data as GDPR-, HIPAA-, or PII-relevant; dynamic data masking; Data Spaces for independent governance boundaries by business unit or region; and Unified Lineage for tracing how data objects connect upstream and downstream. A built-in Data Subject Rights workflow handles GDPR- and CCPA-style access and deletion requests directly.
Together, these tools give a regulated organization something a policy document alone cannot: enforcement at the point where data is created, moved, or accessed.
Technology enforces policy. It does not decide what the policy should be, resolve disputes between teams that define the same field differently, or keep the program funded when priorities shift. That is the job of the operating model — the three roles every Managed-stage governance program has in place.
Executive sponsor. A named executive — typically a CDO, CIO, Chief Compliance Officer, or COO — owns governance as a standing business priority, not an IT initiative. Without this role, governance loses funding and authority the first time it conflicts with a delivery deadline.
Data governance council. A recurring, cross-functional group — compliance, IT, data, and business-unit representatives — that sets policy, resolves definitional disputes (what counts as an "active customer"?), and reviews governance metrics on a set cadence. The council is where policy gets made; stewards are where it gets enforced.
Data stewards. Named individuals, usually embedded in business units rather than centralized in IT, who own data quality and access decisions for a specific domain — customer data, claims data, trading data. A council without stewards produces policy no one implements. Stewards without a council produce inconsistent, siloed rules with no shared standard.
An organization with governance software but none of these three roles will find that quality regresses, lineage gaps go unnoticed, and access reviews lapse — the technology works exactly as configured, but nobody is accountable for keeping it current.
AI is making governance urgent in a way that data privacy law alone did not. A model trained on inconsistent, undocumented, or poorly-sourced data produces outputs with the same problems, just harder to trace back to their source. Regulators are starting to require proof of the opposite directly.
The EU AI Act's Article 10 requires that training, validation, and testing data for high-risk AI systems be relevant, sufficiently representative, and, to the best extent possible, free of errors, with documented characteristics and provenance. That is a data governance requirement written directly into AI law — it does not ask whether a model is accurate; it asks whether the data behind it was governed. The compliance deadline for standalone high-risk systems has been deferred to December 2027, but the requirement itself has not changed.
The NIST AI Risk Management Framework reinforces the same point on a voluntary basis in the US. Its four functions — Govern, Map, Measure, and Manage — depend on documenting what data an AI system was built on and how its risk changes as that data changes. An organization that cannot produce lineage for its training data cannot meaningfully execute Map or Measure.
The practical implication: AI governance is not a separate program from data governance — it's data governance applied to a higher-stakes category of system. Organizations with documented data quality, lineage, and access controls can extend them to AI. Organizations without that foundation will be building both at once, under regulatory pressure. For more, see Building a Data-First Operating Model in the Age of AI.
Vantage Point is a senior-led consulting partner for Salesforce, HubSpot, MuleSoft, and the broader data ecosystem. We implement the technology stack this post describes — Informatica for data quality and lineage, MuleSoft for integration and API governance, and Salesforce Data 360 for policy-based access — and, just as importantly, help design the operating model around it: steward role definitions, governance council charters, and executive sponsorship structures that keep the technology effective after go-live.
Our compliance and security solutions turn regulatory requirements like GDPR, HIPAA, and GLBA into automated, auditable controls rather than manual checklists. Our system integration and data migration services connect the systems that data quality and lineage depend on without a disruptive big-bang replacement. And our Salesforce implementation and advisory services make sure Data 360 governance policies are configured correctly from the start rather than retrofitted after an audit finding.
If your organization is evaluating where it sits on the governance maturity curve, Vantage Point can help assess the gap between current state and a Defined or Managed program, and build a phased plan that sequences technology and operating-model changes together.
Data governance is the ongoing set of policies, roles, and controls that keep data accurate, traceable, and appropriately access-controlled at all times — not just during a cleanup or an audit. It is a standing operating discipline, not a project with an end date.
Data quality (is the data accurate, complete, and current), data lineage (where the data came from and how it changed), and data access (who can see or use it, and whether that access is logged and auditable). All three need to work together; strength in one does not compensate for weakness in another.
Overlapping regimes — GDPR, CCPA/CPRA, sector rules like GLBA, HIPAA, and MiFID II, and now the EU AI Act and NIST AI RMF — all require organizations to document data provenance, quality, and access controls on request. The requirements compound rather than replace one another.
It's a five-stage progression: Ad Hoc, Reactive, Defined, Managed, and Optimized. Most regulated organizations sit at Reactive — they respond to problems after they occur but have no system that prevents recurrence. Advancing requires governance technology and defined organizational ownership at the same time.
Both. Technology like Informatica, MuleSoft, and Salesforce Data 360 enforces policy automatically, but someone has to define that policy, resolve disputes between teams, and keep it current as the business changes. That's the role of data stewards, a governance council, and an executive sponsor.
It applies to providers and deployers of high-risk AI systems used in the EU regardless of where the company is headquartered, similar to how GDPR applies extraterritorially. The high-risk compliance deadline was deferred to December 2027 (standalone systems) and August 2028 (embedded systems) by the 2026 AI Omnibus amendment, but the underlying data governance requirement is the direction of travel, not a canceled obligation.
Name an executive sponsor and identify the two or three data domains with the highest regulatory exposure — customer identity and consent data are common starting points. Catalog where that data lives, assign a steward per domain, and stand up a lightweight governance council before investing heavily in tooling. Technology accelerates a defined operating model; it cannot substitute for one.
Ready to assess where your organization sits on the governance maturity curve? Talk to Vantage Point about a governance readiness assessment covering data quality, lineage, access controls, and AI governance readiness.
Vantage Point is a boutique CRM consulting firm helping businesses transform with Salesforce, HubSpot, and AI. Our senior-only, US-based team has delivered 400+ engagements for 150+ clients with an average rating of 4.71/5.0. Learn more at vantagepoint.io.