Third-Party Data Is Still Your Governance Problem

Data Governance Series | Article 15 of 20

Governing the Information That Drives the Enterprise

Enterprises increasingly make decisions using data they did not create.

Credit information.

Market intelligence.

Customer enrichment data.

Threat intelligence.

Geolocation data.

Economic indicators.

Healthcare information.

Identity verification data.

Supply-chain information.

Industry benchmarks.

Public datasets.

Partner data.

Commercial data feeds.

SaaS platforms.

APIs.

And increasingly, information produced or enriched by artificial intelligence.

The data arrives from somewhere else.

The consequences do not.

If a third-party dataset is inaccurate, outdated, unlawfully collected, poorly documented, improperly licensed, biased, incomplete, or inappropriate for the intended use, the enterprise may still be accountable for what happens next.

A contract can transfer certain obligations.

It cannot transfer reality.

When your organization uses external data to make a consequential decision, that data becomes part of your governance problem.

The Data Supply Chain Has Expanded

Most enterprises no longer operate primarily on information created within their own boundaries.

Modern digital operations depend upon complex data supply chains.

A customer record may contain information from:

the customer;

internal systems;

a credit bureau;

a marketing provider;

a fraud service;

an identity platform;

a data broker;

public records;

and AI-generated enrichment.

A cybersecurity platform may combine:

internal telemetry;

vendor threat intelligence;

public vulnerability information;

commercial reputation feeds;

third-party asset data;

and machine-generated risk scores.

A supply-chain system may depend upon:

supplier data;

logistics providers;

weather services;

economic data;

geopolitical intelligence;

and external risk ratings.

The resulting enterprise decision may appear internal.

Its evidentiary foundation may be distributed across dozens of organizations.

That changes governance.

Procurement Is Not Data Governance

Organizations often govern third-party data primarily through procurement.

The vendor is evaluated.

Security reviews are completed.

Privacy terms are negotiated.

A contract is signed.

Service levels are established.

The vendor becomes approved.

That process is necessary.

But approving the vendor does not establish that every piece of data supplied by the vendor is trustworthy, appropriate, or fit for every enterprise use.

Vendor governance asks:

“May we do business with this provider?”

Data governance asks:

“May we rely on this information for this purpose?”

Those are related questions.

They are not the same question.

A trustworthy vendor can still provide data that is inappropriate for a particular decision.

The Vendor Is Not the Provenance

Ask an organization where a dataset came from and the answer is often the vendor’s name.

“We get it from Provider X.”

That identifies the supplier.

It does not necessarily establish provenance.

The vendor may have obtained the information from:

another provider;

a data broker;

public records;

web scraping;

customer submissions;

government sources;

commercial partners;

statistical estimation;

machine learning;

or multiple downstream suppliers.

The enterprise may know who delivered the data without knowing who created it.

That distinction matters.

Provenance should help answer:

Where did this information originate?

How was it collected?

Was it observed, reported, derived, or generated?

When was it collected?

What transformations occurred?

Who attested to its accuracy?

What evidence supports it?

What restrictions apply?

The name on the invoice cannot answer all of those questions.

Third-Party Data Has Its Own Supply Chain

A vendor may itself depend upon vendors.

That creates a data supply chain behind the data supply chain.

Imagine purchasing a commercial risk score.

The provider combines:

public records;

financial information from another supplier;

location information from a data broker;

industry statistics;

a proprietary algorithm;

and machine-generated classifications.

The enterprise receives one number.

Risk Score: 72

It looks simple.

The provenance may be extraordinarily complex.

What does 72 mean?

Which inputs produced it?

How current were they?

What assumptions were embedded in the calculation?

What happens when an upstream provider changes?

Can the score be challenged?

Can it be reproduced?

Can it be corrected?

Can the enterprise explain why it relied upon it?

A single field can conceal an entire governance architecture.

Contractual Assurance Is Not Evidentiary Assurance

Contracts matter.

Representations and warranties matter.

Data processing agreements matter.

Service-level agreements matter.

Audit rights matter.

But contractual assurance should not be confused with evidentiary assurance.

A vendor may contractually promise that data meets certain requirements.

The enterprise still needs enough evidence to determine whether those requirements are being met.

That evidence might include:

data quality metrics;

provenance documentation;

source descriptions;

collection methodologies;

validation processes;

refresh schedules;

error rates;

change notifications;

audit reports;

control attestations;

incident histories;

and correction procedures.

The question is not whether the vendor promised quality.

The question is whether the enterprise can demonstrate why reliance was reasonable.

Quality Problems Travel Downstream

Poor-quality third-party data rarely remains isolated.

It enters enterprise systems.

It is joined with internal records.

It feeds analytics.

It appears in dashboards.

It influences models.

It becomes AI context.

It drives decisions.

It may create new derived information.

The original defect can become increasingly difficult to identify.

Consider an incorrect customer attribute supplied by a third party.

It enters the CRM.

A segmentation model uses it.

An AI assistant retrieves the segmentation.

A recommendation engine adjusts an offer.

A customer service agent relies on the recommendation.

The customer experiences the consequence.

By then, the original third-party data point may be nearly invisible.

That is why third-party data needs lineage.

The Enterprise Needs to Know Where External Data Goes

Third-party data governance should not end at ingestion.

Organizations need to understand downstream use.

Which systems consume the data?

Which reports depend upon it?

Which models use it?

Which AI systems retrieve it?

Which decisions rely upon it?

Which derived datasets contain it?

Which customers or employees may be affected?

This is impact analysis.

If the vendor later reports an error, the enterprise needs to answer:

“What did this data influence?”

Without lineage, the answer may require weeks of investigation.

With lineage, the organization can identify the blast radius.

Data Quality Needs Contractual and Operational Controls

Third-party data quality cannot be managed solely through contract language.

It needs operational monitoring.

Quality dimensions may include:

accuracy;

completeness;

consistency;

timeliness;

validity;

uniqueness;

coverage;

and fitness for purpose.

But the appropriate thresholds depend upon use.

A dataset used for exploratory market analysis may tolerate uncertainty.

The same dataset used to make automated customer decisions may require substantially stronger assurance.

Governance therefore needs to connect:

Data Quality → Intended Use → Decision Consequence

There is no universal quality threshold.

There is only quality sufficient for a particular purpose.

Freshness Is Part of Quality

Third-party data often has another hidden problem: age.

A provider may update a dataset daily.

That does not mean every underlying field is current.

Some attributes may have been collected yesterday.

Others six months ago.

Others years ago.

The enterprise may receive a fresh file containing stale facts.

That distinction is easy to miss.

AI makes it more consequential.

A model does not necessarily know that one field represents current information while another reflects a historical observation.

Freshness therefore needs provenance.

When was this fact actually established?

That may matter more than when the vendor delivered it.

Legal Acquisition Does Not Guarantee Permissible Use

A dataset can be lawfully acquired and still be inappropriate for a particular purpose.

Licensing terms may restrict:

redistribution;

model training;

profiling;

commercial use;

automated decision-making;

derivative products;

geographic use;

or retention.

Privacy requirements may impose additional restrictions.

Consent may apply to one purpose but not another.

Sector-specific rules may affect certain uses.

Third-party data governance therefore needs to understand not merely:

“Are we allowed to possess this data?”

but:

“Are we allowed to use it this way?”

AI makes that question increasingly difficult because the same dataset may support many unforeseen uses.

AI Expands Purpose Faster Than Contracts Do

An organization may have licensed a dataset years before generative AI entered the enterprise.

The agreement may have contemplated:

analytics;

reporting;

customer service;

research;

or operational processing.

Then someone connects the dataset to an AI system.

Can it be used for RAG?

Can embeddings be created?

Can it be included in prompts?

Can it be used for fine-tuning?

Can AI generate derivative information from it?

Can those derivatives be retained?

Can they be shared with customers?

Can an agent act upon them?

The original contract may not answer these questions clearly.

AI can create new data uses faster than procurement cycles can renegotiate them.

Governance needs to close that gap.

“Publicly Available” Does Not Mean Governance-Free

Public data presents another misconception.

If information is publicly accessible, organizations may assume it can be used without significant governance.

That assumption is dangerous.

Public information can still be:

incorrect;

outdated;

misleading;

context-dependent;

copyrighted;

restricted by terms of use;

sensitive when aggregated;

or inappropriate for certain decisions.

Public availability tells you something about accessibility.

It does not establish quality, authority, provenance, legality of every reuse, or fitness for purpose.

An enterprise AI system can combine public information at a scale that fundamentally changes its sensitivity.

Governance still applies.

Data Brokers Increase Opacity

Commercial data brokers can provide enormous amounts of information about individuals, households, businesses, devices, locations, and behavior.

The enterprise may receive highly structured data without understanding the complexity behind it.

Where was each attribute obtained?

Was it directly observed?

Self-reported?

Purchased?

Inferred?

Estimated?

Modeled?

How old is it?

How accurate is it?

Can the subject correct it?

Can the provider explain it?

This is where the distinction from Article 9 becomes important.

Observed, reported, derived, and generated data are not epistemically equivalent.

A third-party attribute should not acquire greater authority merely because it arrived in a professionally formatted API response.

Derived Data Needs Transparency

Many vendors do not merely supply raw information.

They supply conclusions.

Scores.

Ratings.

Classifications.

Propensity measures.

Risk indicators.

Predictions.

Recommendations.

Those outputs may be proprietary.

That can create tension between intellectual property and governance.

The vendor may say:

“Our methodology is confidential.”

The enterprise may still need enough transparency to determine whether reliance is appropriate.

For consequential uses, “proprietary” cannot become synonymous with “unexaminable.”

The organization may not need the vendor’s source code.

It may need sufficient evidence regarding:

inputs;

methodology;

limitations;

validation;

error rates;

known biases;

change management;

and appropriate uses.

Black-box data products create governance obligations even when they are not marketed as AI.

AI-Generated Third-Party Data Needs Explicit Provenance

The external data supply chain is increasingly becoming machine-generated.

Vendors may use AI to:

enrich records;

classify entities;

summarize documents;

extract attributes;

score risk;

identify relationships;

fill missing values;

or generate synthetic information.

The enterprise may not know which fields were directly sourced and which were machine-inferred.

That distinction should not disappear.

A field produced by an AI model should carry provenance indicating that it was generated or inferred.

Otherwise, machine inference can enter enterprise systems looking indistinguishable from observed fact.

Once stored, it may acquire institutional authority.

That is exactly the kind of governance debt AI can amplify.

Third-Party Data Can Contaminate Enterprise AI

Suppose external data enters a knowledge base.

The RAG system retrieves it.

The AI generates an answer.

That answer is saved into an internal system.

Later, another AI retrieves the generated answer as enterprise information.

Now the chain looks like:

Third-Party Data → Enterprise RAG → AI Inference → Internal Record → Future AI Context

The original external information has become embedded in institutional knowledge.

If the source was wrong, the error can propagate.

If provenance was lost, the enterprise may no longer know the information originated externally.

This is how third-party data can become internal fact without ever being independently verified.

Correction Rights Matter

What happens when third-party data is wrong?

Can the enterprise challenge it?

Can the vendor correct it?

How quickly?

Will corrected data propagate?

Will downstream enterprise systems update?

Will derived scores be recalculated?

Will AI embeddings be refreshed?

Will cached outputs disappear?

Will previously generated records be corrected?

Third-party data governance needs a correction architecture.

Otherwise, the enterprise may discover an error without having a reliable way to remove its consequences.

Vendor Changes Can Create Governance Drift

Third-party data products change.

Vendors:

add sources;

remove sources;

change methodologies;

modify scoring algorithms;

alter refresh schedules;

introduce AI;

change subprocessors;

expand geographic coverage;

redefine fields;

or adjust licensing terms.

The product may retain the same name.

The underlying data may be materially different.

Governance therefore cannot be based solely on the initial vendor review.

Material changes should trigger reassessment.

The enterprise needs to know when the data product it approved is no longer the same product.

Data Dependency Creates Concentration Risk

Enterprises can become deeply dependent upon particular external data providers.

A vendor feed may support:

fraud detection;

customer onboarding;

regulatory reporting;

pricing;

risk management;

AI systems;

and operational decisions.

That creates concentration risk.

What happens if:

the vendor fails;

the feed stops;

quality deteriorates;

the provider changes methodology;

the contract ends;

the vendor is acquired;

a regulator challenges the data source;

or the enterprise loses the right to use the information?

Data governance should identify critical external data dependencies just as technology governance identifies critical systems and vendors.

Third-Party Data Needs an Owner Inside the Enterprise

One of the most important controls is surprisingly simple.

Every significant third-party dataset should have an accountable internal owner.

Not merely a vendor manager.

Someone accountable for the enterprise’s use of the data.

That owner should understand:

why the data exists;

which decisions depend upon it;

what quality is required;

what restrictions apply;

how provenance is established;

where the data flows;

what happens when it changes;

and when the organization should stop using it.

External origin does not eliminate internal accountability.

It makes internal accountability more important.

Build a Third-Party Data Inventory

Organizations often maintain vendor inventories.

They may also maintain application inventories.

AI governance programs are increasingly building AI inventories.

A mature data governance program should know which significant external datasets the enterprise depends upon.

A third-party data inventory might include:

provider;

dataset;

internal owner;

business purpose;

source provenance;

data classification;

quality requirements;

refresh frequency;

permitted uses;

prohibited uses;

AI retrieval status;

AI training status;

retention requirements;

critical downstream systems;

decision dependencies;

contract expiration;

and correction procedures.

This turns external data dependency into something governable.

Tier Third-Party Data by Consequence

Not every external dataset requires the same scrutiny.

A weather feed used to adjust marketing content does not carry the same consequence as external data used for:

credit decisions;

employment decisions;

clinical decisions;

fraud determinations;

regulatory reporting;

cybersecurity response;

insurance underwriting;

or autonomous actions.

Governance should be proportional.

One practical approach is to tier third-party data according to:

sensitivity;

decision consequence;

regulatory exposure;

degree of automation;

substitutability;

provenance confidence;

and organizational dependency.

Higher-consequence data receives stronger assurance.

Measure Third-Party Data Governance

Organizations can make this visible through metrics.

Examples include:

percentage of critical external datasets with accountable owners;

percentage with documented provenance;

percentage with defined quality thresholds;

percentage with explicit AI-use permissions;

number of external data quality incidents;

time required to propagate corrections;

number of critical decisions dependent upon single-source external data;

percentage of third-party derived attributes labeled as inferred or generated;

number of material vendor data changes requiring reassessment;

and percentage of high-consequence third-party data with tested contingency plans.

These are governance measures.

They tell leadership whether external data dependence is understood and controlled.

Third-Party Data Belongs in AI Governance

AI governance programs often focus heavily on:

models;

vendors;

use cases;

bias;

security;

privacy;

human oversight;

and monitoring.

The third-party data supply chain needs equal attention.

A well-governed model can still produce poor outcomes from poorly governed external data.

A trusted AI vendor can still consume questionable data.

A compliant use case can still depend upon information whose provenance cannot be established.

A human reviewer can still make a bad decision when the evidence is wrong.

AI governance therefore needs to ask:

What external information does this system depend upon?

Where did it originate?

Why do we trust it?

What restrictions apply?

What happens when it changes?

And what evidence demonstrates that our reliance remains reasonable?

Governance Follows the Decision

There is a broader principle underneath all of this.

Organizations often think governance follows ownership.

If we created the data, we govern it.

If someone else created it, they govern it.

That model no longer works.

Governance should follow reliance.

If your enterprise relies upon information to make a consequential decision, you need sufficient governance over that information to justify the reliance.

You may not control how the data was originally created.

You can control whether you accept it.

How you validate it.

How you classify it.

Where you use it.

What decisions depend upon it.

How you monitor it.

When you stop trusting it.

And what evidence you preserve.

The source may belong to someone else.

The reliance belongs to you.

Boardroom Takeaway

Executives should resist the assumption that third-party data risk is primarily a vendor-management issue.

The enterprise may outsource collection, enrichment, scoring, hosting, or analysis.

It does not outsource the consequences of relying upon the resulting information.

Leadership should ask:

“For the external data driving our most consequential decisions, can we demonstrate where it came from, why we trust it, what we are permitted to do with it, and what happens when it is wrong?”

If the answer is no, the organization does not merely have a vendor problem.

It has a governance problem.

Because third-party data may come from outside the enterprise.

Accountability for using it does not.

Coming Next

Article 16: Data Governance Needs Evidence, Not Policies

Most organizations can produce data governance policies, standards, committees, ownership models, and control frameworks.

The harder question is whether they can demonstrate that governance is actually happening.

The next article examines the difference between documented governance and evidenced governance—and why organizations increasingly need to prove who made data decisions, what controls operated, which exceptions were accepted, what quality was measured, and whether governance requirements were actually enforced.