What is a data lake and how do you keep one secure?

A data lake is a central store that keeps raw data in its original format, structured or not, until someone needs it. Unlike a warehouse, it does not force a schema on write. That flexibility is its strength and its main security problem, because no one decides up front who may see what.

How is a lake different from a warehouse?

A warehouse loads cleaned, modelled tables. The schema is decided first, so access rules attach to tables and columns that people understand.

A lake takes files as they come: logs, exports, images, documents, event streams. Structure is applied when the data is read. That makes ingestion cheap and exploration fast, and it means a folder can hold customer records next to public web logs without anything marking the difference.

Why do lakes go wrong?

Three patterns repeat.

Everything lands, nothing is labelled. Teams copy production extracts into the lake for analysis. Months later nobody remembers which files contain personal data.

Access follows the storage account. If the lake sits in one account and a broad role can read all of it, then the weakest analyst credential is an access path to everything.

Copies multiply. Each analysis writes derived files. Deleting a person's record at the source does not delete it from the five derived datasets.

NIST SP 800-53 gives the control families that apply. Access control (AC), audit and accountability (AU), media protection (MP) and system and communications protection (SC) all matter. Least privilege, in particular, is hard to apply to data nobody has classified.

What controls matter most?

Start with classification at ingestion. Tag each dataset with a sensitivity label and an owner when it arrives, not afterwards. Without that, every later control is guesswork.

Then separate zones. A common layout uses a raw zone with tightly restricted access, a curated zone with reviewed datasets, and a sandbox for experiments with synthetic or masked data.

Use attribute based access control where it fits. NIST SP 800-162 defines it as authorization decided by evaluating attributes of the subject, object and environment against policy. For a lake, that means a rule such as "analysts in the finance group may read datasets tagged internal, not restricted" instead of hundreds of folder permissions.

Encrypt data at rest and in transit, and keep keys outside the lake's own permission boundary. Log reads, not only writes, because exfiltration looks like a lot of reads.

A constructed example

An online retailer's lake holds order exports, support chat transcripts and web logs. A support export includes customer names and addresses. It was copied into a shared analytics folder for a one off project.

Under the controls above, the export would arrive tagged restricted with an owner. Analysts would reach it only from a masked view. When a customer asks for erasure, the owner can follow lineage records to every derived file and delete them. Without tags and lineage, the team would be searching file names and hoping.

How to check or apply this

1. List every dataset location in the lake and who can read it today.
2. Sample ten datasets and check whether each has a label and an owner.
3. Search for personal data in raw files with a discovery tool before you trust any label.
4. Split raw, curated and sandbox zones, and cap who can read raw.
5. Move to group or attribute based access rules and remove direct user grants.
6. Turn on read logging and alert on unusual volume.
7. Record lineage so that deletion and breach scoping can follow copies.
8. Set retention for each zone and enforce it automatically.

Quick check

Sources

• NIST SP 800-53 Rev. 5, Security and Privacy Controls
• NIST SP 800-162, Guide to Attribute Based Access Control

Last reviewed: 18 October 2026.