Notifications
Clear all
Topic starter
19/08/2026 4:07 pm
TL;DR: Traditional DLP cannot inspect Parquet, Avro, ORC, or Feather at the scale and structure used in modern data lakes, leaving PII and credentials hidden in shared analytics stores, according to Sentra. The governance issue is not file volume alone, but the mismatch between data engineering access patterns and control models built for emails and documents.
NHIMG editorial — based on content published by Sentra: Data lake format scanning and the visibility gap in modern data lakes
Questions worth separating out
Q: How should security teams scan data lake files that use columnar formats?
A: They should use schema-aware scanning that can interpret Parquet, Avro, ORC, and related formats natively.
Q: Why do data lakes create more access risk than traditional file shares?
A: Data lakes concentrate large amounts of sensitive information behind shared storage and broad IAM roles.
Q: What breaks when sensitive data is hidden inside lakehouse formats?
A: Classification breaks first, then policy enforcement follows because the security stack never sees the true contents of the file.
Practitioner guidance
- Map file formats to scanner capability Inventory which critical datasets are stored as Parquet, Avro, ORC, or Feather, then verify that your scanning stack can parse each format natively before you rely on it for compliance reporting.
- Review IAM roles attached to lakehouse access Identify every human and non-human identity that can read shared buckets or external tables, then reduce broad read access to the smallest viable set of roles and service accounts.
- Separate masking from downstream copies Check whether masked source records remain unmasked after ETL and replication, because a successful control at ingestion can still fail if copied datasets inherit raw fields.
What's in the full article
Sentra's full blog post covers the operational detail this post intentionally leaves for the source:
- How the tabular reader handles Parquet, Avro, ORC, and Arrow IPC at scan time
- Examples of schema-aware classification for nested fields and misleading data types
- The mechanics of batch processing large datasets without loading entire files into memory
- Where column-level intelligence improves detection precision in analytics and ML workflows
👉 Read Sentra's analysis of data lake scanning gaps and sensitive data exposure →
Data lake scanning gaps: what IAM and DSPM teams need to know?
Explore further
19/08/2026 4:40 pm
Data lake security is now an identity problem as much as a data problem. When shared storage becomes the default landing zone for production copies, the effective control point shifts to IAM, service-account scope, and entitlement review. Schema-aware scanning is necessary, but it does not replace the need to question which humans and NHIs can reach the data once it is classified. Practitioners should treat data discovery and access governance as a single programme, not separate tools.
A question worth separating out:
Q: How do organisations reduce exposure from analytics and ML data pipelines?
A: They should combine data classification with pipeline identity governance. That means reviewing service accounts, limiting standing access, and tracking where raw data is copied so the same controls apply to both the dataset and the non-human identities moving it.
👉 Read our full editorial: Data lake file formats expose a DLP blind spot for sensitive data
