Vendor Data Lake Exposure

A healthcare technology vendor had strong data security across their application systems , role-based access controls, field-level encryption, audit logging, quarterly access reviews. Three years prior, the data engineering team had built a central data lake in AWS S3, fed by replication jobs from every application database. The intent was to enable analytics, product metrics, and machine learning without impacting production systems. Over three years, the data lake had grown to contain the complete history of every customer record, every transaction, every clinical note, and every integration event ever processed by the vendor. The access controls on the data lake had been set by the data engineering team at creation: read access for anyone in the data-engineering and product teams, which had grown from eight people to forty-seven. Nobody had conducted an access review of the data lake since it was created. The data lake contained the most comprehensive sensitive data repository in the vendor's environment. It had the weakest access controls of any system the vendor operated.

What is the Vendor Data Lake Exposure Problem, Really?

A data lake is a centralized repository designed to store large volumes of raw, unprocessed data from multiple sources , application databases, event streams, API logs, external feeds , in its native format, enabling flexible analytical queries without the schema constraints of a traditional relational database. Data lakes are valuable precisely because of their design characteristics: they ingest everything, they store it cheaply, and they provide broad query access that enables exploratory analytics, machine learning, and product intelligence that is impossible in tightly governed production systems. Those same design characteristics , comprehensive ingestion, cheap storage, broad access , make data lakes a significant data security risk when they contain sensitive customer data.

The governance gap arises from the tension between the data lake's analytical purpose and the governance requirements of the sensitive data it contains. Data lakes are designed by data engineers optimizing for analytical flexibility , they want data scientists, analysts, product managers, and ML engineers to be able to query freely without access bottlenecks. Data governance programs are designed by security and privacy teams optimizing for access restriction , they want sensitive data accessible only to those who need it for specific authorized purposes. These goals are structurally in conflict, and in most organizations the data lake was built by the data engineering team before the data governance team was involved, creating a comprehensive sensitive data repository that was operational before its governance requirements were defined.

The aggregation problem makes data lake exposure categorically different from individual database exposure. A customer record in an application database contains the data for that specific transactional context. A data lake that ingests from every application database contains every transactional record for every customer across the vendor's entire history , a comprehensive profile that is more sensitive than any individual source system because it combines data from multiple contexts into a unified, queryable dataset. The value of that aggregated dataset to an attacker is proportionally higher than any individual source system. The governance rigor applied to it is typically proportionally lower.

Vendor data lake exposure concentrates around five specific risk patterns:

• Broad default access , data lakes provisioned with read access for entire teams or departments rather than role-specific, need-to-know access controls calibrated to data sensitivity
• No field-level security , data lakes that provide table-level or bucket-level access without field-level restrictions, exposing all fields including sensitive ones to any user with table access
• Comprehensive historical accumulation without retention governance , data lakes that ingest everything and delete nothing, accumulating years of sensitive data history with no automated retention enforcement
• Absent audit logging , data lakes where query activity is not logged or where logs are not reviewed, making it impossible to detect anomalous data access patterns
• ML training data exposure , customer data in data lakes used as training inputs for machine learning models without explicit authorization, data minimization, or anonymization

Why this matters

Vendor data lake exposure matters for TPRM because it represents a concentration of sensitive data at a point in the vendor's architecture that is specifically designed to be broadly accessible. A breach of a vendor's data lake does not expose a single application's data , it exposes the aggregated history of every application system that feeds into it. For a vendor serving hundreds of enterprise customers, a data lake breach can be a multi-customer, multi-year data exposure event of a scale that no individual application database breach would produce.

The internal threat dimension is particularly significant for data lakes. External attackers must compromise the vendor's perimeter to reach application databases. Data lake access is typically available to dozens of internal users , data engineers, data scientists, product analysts , many of whom have never had their access reviewed and some of whom may have left the organization while retaining access credentials. The broad internal access that makes data lakes analytically valuable makes them high-value targets for insider threats and credential compromise that bypasses external security controls.

The ML training data dimension is increasingly significant as vendors incorporate machine learning into their product offerings. Customer data in a vendor's data lake may be used as training data for ML models , either explicitly as a feature improvement program or implicitly because the data lake is the most convenient source of labeled training examples. Without explicit contractual prohibitions and technical controls preventing customer data from being used in ML training pipelines, a vendor's data lake creates a pathway for customer data to become embedded in model weights that are shared across the vendor's customer base.

Where most teams get this wrong

The most consistent failure is not asking whether the vendor operates a data lake or equivalent central analytics repository that aggregates data from the primary application systems being assessed. TPRM assessments that comprehensively evaluate application database security may never discover that all those databases feed into a central repository with fundamentally different access governance. The data lake is an internal analytics infrastructure decision that vendors rarely volunteer in security assessments because it is not the system of record for the contracted service.

The second failure is treating data lake security as a data engineering concern rather than a data security concern. In most vendor organizations, data lakes are built and operated by data engineering teams whose primary governance concern is data quality and pipeline reliability. Data security governance , access controls, audit logging, retention policies, field-level encryption , is applied to application systems through security team oversight. Data lakes are frequently outside that oversight because they were provisioned by a different team before security governance processes extended to analytics infrastructure.

• Not asking whether a data lake or central analytics repository exists , application database assessment without discovering the aggregated analytics copy
• Data lake excluded from security assessment scope , SOC 2 and vendor assessments scoped to production application systems that explicitly exclude analytics infrastructure
• No access control assessment for data lake , broad team access never reviewed against data sensitivity requirements
• No audit logging requirement for analytics infrastructure , query activity in data lakes not logged or not reviewed
• ML training data use not assessed , no question about whether customer data in the data lake is used as ML training input

What good looks like

Mature vendor data lake governance programs apply data security standards to analytics infrastructure with the same rigor as application systems , implementing attribute-based or row-level security that restricts access to sensitive fields, maintaining audit logs of all query activity, enforcing retention policies that prevent indefinite sensitive data accumulation, and prohibiting the use of identifiable customer data as ML training input without explicit authorization.

• Attribute-based or row-level security on data lake , access controls that restrict sensitive fields and rows based on user role and need-to-know, not just table-level access
• Audit logging for all query activity , every data lake query logged with user identity, timestamp, and dataset accessed, with anomaly detection on unusual access patterns
• Retention policies enforced on data lake , automated deletion of records that have exceeded retention periods rather than indefinite accumulation
• Anonymization or pseudonymization for analytics , sensitive customer data anonymized or pseudonymized before ingestion into the data lake where analytics use cases do not require identification
• ML training data authorization , explicit customer authorization required before customer data is used as ML training input, with data minimization and anonymization applied
• Data lake included in SOC 2 and security assessment scope , analytics infrastructure assessed under the same security standards as application systems

Tooling

Governing data lake security requires tools specifically designed for the analytical infrastructure context , access control, audit logging, and data masking in cloud data lake environments.

Cloud Data Lake Security , AWS Lake Formation, Azure Purview, Databricks Unity Catalog

AWS Lake Formation provides column and row-level security for S3-based data lakes, enabling fine-grained access controls that restrict sensitive fields to authorized users while allowing broader access to non-sensitive data. Azure Purview provides data governance and classification across Azure data estate including data lakes. Databricks Unity Catalog provides unified access control and audit logging for Databricks-based data lakes. For TPRM practitioners, asking whether the vendor's data lake uses Lake Formation or equivalent fine-grained access controls surfaces whether field-level security exists or whether access is at the broader table or bucket level.

Data Masking for Analytics , Tonic.ai, Gretel.ai, Immuta

Data masking and synthetic data platforms transform sensitive customer data before it enters the data lake , providing analytics-suitable data that preserves statistical properties without containing identifiable personal information. Immuta provides policy-based data access controls that can dynamically mask sensitive fields based on user role, enabling the same dataset to serve different access tiers without maintaining multiple copies. For TPRM practitioners, asking whether the vendor applies masking or anonymization to sensitive data before data lake ingestion surfaces whether the analytics use case requires identifiable data or whether privacy-preserving alternatives are feasible.

Data Lake Audit and Monitoring , Securiti, Cyera, Laminar

DSPM and data lake monitoring platforms provide continuous visibility into data lake access patterns , detecting anomalous queries, identifying sensitive data that is broadly accessible, and alerting on access policy violations. For TPRM practitioners, asking whether the vendor monitors data lake query activity for anomalous access patterns surfaces whether the data lake is observable or effectively a blind spot in their security monitoring.

Governance challenges

The governance challenge with data lake security is the scale and flexibility tension. Data lakes contain data from many source systems in varying formats, queried by many users with varying analytical needs. Applying consistent field-level security across this heterogeneous environment requires classification of every field, definition of access policies for every user role, and enforcement at the query layer , a governance investment that data engineering teams typically have not made because it was not part of the original data lake design brief.

For TPRM programs, the practical governance approach is to include data lake existence and access governance as a standard question in vendor assessments for any vendor who processes sensitive customer data at scale. The existence of a data lake is not itself a risk , it is a common and legitimate architectural pattern. The access controls, audit logging, and retention governance that apply to it determine whether it represents a well-governed analytics capability or a comprehensively accessible repository of every sensitive record the vendor has ever processed.

• Add data lake existence to vendor assessment questions , does a central analytics repository exist that aggregates data from the application systems being assessed
• Ask about data lake access controls specifically , field-level security, access review cadence, and whether the access model has been reviewed against data sensitivity requirements
• Require audit logging for data lake query activity , not just infrastructure logging but query-level audit with user identity and dataset access
• Ask about ML training data authorization , whether customer data from the data lake is used as ML training input and what authorization process applies
• Include data lake in SOC 2 scope requirements , analytics infrastructure included in security assessment scope, not carved out as operational infrastructure

If you are a small team

Add one question to your vendor assessment for any vendor who processes sensitive data at scale: do you operate a central data lake or analytics repository that aggregates data from your application systems, and if so, who has access to it and has that access been reviewed against the sensitivity of the data it contains? That question will surface the existence of data lake infrastructure that your application database assessment never reached, and the answer will tell you whether the most comprehensive copy of your customer data in the vendor's environment is governed with equivalent rigor to the primary systems you assessed.

• Ask whether a data lake or central analytics repository exists before concluding the application database assessment
• Ask how many users have access to the data lake and when that access was last reviewed
• Ask whether customer data in the data lake is used as ML training input
• Ask whether the data lake is within the scope of the vendor's SOC 2 or equivalent security audit

What to require

Ask directly:

"Do you operate a data lake or central analytics repository that contains data from the application systems you use to process our customer data , and if so, what access controls apply to it and when was access last reviewed?"

"Is customer data in your data lake used as input for machine learning model training , either for your own product improvements or as general training data , and if so, what authorization and anonymization processes apply?"

"Is your data lake included in the scope of your SOC 2 or equivalent security audit, or is it excluded as operational or analytics infrastructure?"

Expect as evidence

• Data lake existence confirmation with access control description
• Access review evidence , when data lake access was last reviewed and what the current access population is
• ML training data use confirmation and authorization process
• SOC 2 or equivalent scope confirmation , data lake included or explicitly excluded with explanation

A vendor who responds to the data lake question with 'we use analytics infrastructure to support our product' has confirmed existence without describing access. Ask specifically how many people can query the data lake and what the last access review found. The analytics platform designed for exploration has the access controls that serve exploration. Those controls may not serve your data's sensitivity.

How to evidence it

Data lake governance is increasingly addressed in GDPR's data minimization and storage limitation principles as applied to analytics infrastructure, and in sector-specific guidance on the governance of analytical data stores. Demonstrating due diligence requires evidence that analytics infrastructure was assessed alongside application systems.

• Vendor assessment records documenting data lake existence, access governance, and ML training data use questions
• SOC 2 scope review confirming whether analytics infrastructure is included
• Data lake access control documentation for highest-risk vendor relationships
• ML training data authorization confirmation

Key Takeaway

The data lake was built for discovery. It ingests everything, retains everything, and provides broad access because that is what makes it analytically valuable. Those same properties make it the most sensitive data repository in the vendor's environment , a comprehensive, historically complete, broadly accessible copy of every record from every system the vendor has ever operated. The application databases have strong controls because they were designed for transactional processing under security oversight. The data lake has weaker controls because it was designed by a data engineering team for analytical flexibility before security governance extended to analytics infrastructure. Assessing the application database security without asking about the data lake is assessing the store window while the warehouse behind it is unlocked.

More on Privacy

• Cross-Border Data Flow Risks
• Data Access Logging Gaps
• Data Access Privilege Creep