DLP Fundamentals + Cloud-Native Tools — UprootSecurity Bootcamp

Every control so far has been about protecting data you know about, in places you manage. Data Loss Prevention (DLP) addresses a harder problem: sensitive data has a way of ending up where it shouldn't — a customer's full credit-card number in a support ticket, a spreadsheet of SSNs emailed to a personal account, PII copied into a public S3 bucket, secrets pasted into a chat. DLP is the set of controls that find sensitive data wherever it lives, classify it, and stop it from leaving through unauthorized channels.

For a GRC Engineer, DLP is how "we protect customer PII" becomes provable: you can't protect — or attest to protecting — data you can't find. This lesson covers what DLP actually does, the channels it watches, the cloud-native tools (Amazon Macie, Microsoft Purview), and the honest limits of the control.

Finding a full SSN pasted into a public support ticket

The two halves of DLP: discovery and prevention

DLP is really two capabilities that work together.

1. Discovery and classification — find and label the sensitive data. You cannot protect data you haven't located, so DLP tools scan data stores (object storage, databases, file shares, SaaS apps, endpoints) and identify sensitive content using:

Pattern matching — regular expressions and validated formats for structured identifiers: credit-card numbers (with Luhn check), SSNs, passport numbers, bank accounts.
Classifiers / ML — models that recognize less-structured sensitive content: medical information, financial documents, source code, credentials.
Data classification labels — tagging data by sensitivity (Public / Internal / Confidential / Restricted) so policy can be applied by label.

2. Prevention / enforcement — stop it from leaving inappropriately. Once data is classified, policies act when it moves through a monitored channel: block the action, quarantine the data, encrypt it, alert, or require justification.

The order matters: discovery comes first. A DLP program that jumps to blocking without first understanding what sensitive data exists and where generates noise and breaks workflows. Classification is the foundation everything else stands on.

DLP: discover and classify first, then enforce policy across the channels data moves through

The three states, three channels

DLP is often framed by the state of the data it protects, and each maps to where enforcement happens:

Data at rest — sensitive data sitting in storage. DLP discovers and classifies it (e.g., Macie scanning S3, Purview scanning data stores), flagging exposure like PII in a public bucket.
Data in motion — data crossing a network boundary: email, web uploads, API egress, cloud-to-internet traffic. DLP inspects and can block or encrypt it (e.g., email DLP blocking an outbound message containing card numbers).
Data in use — data being actively handled on an endpoint: copy/paste, USB transfer, printing, screenshots. Endpoint DLP enforces here.

A complete program covers all three, but most organizations start with discovery at rest (find the exposure) and email/egress in motion (the most common leak channels), then extend to endpoints.

The cloud-native tools

You'll most often encounter these in cloud environments:

Tool	Cloud	What it does
Amazon Macie	AWS	Discovers and classifies sensitive data in S3 (PII, credentials); flags public/unencrypted/shared buckets holding sensitive data.
Microsoft Purview	Azure / M365	Broad data governance + DLP: classification, labeling, and policy enforcement across M365 (email, SharePoint, Teams), endpoints, and cloud stores.
Google Cloud DLP / Sensitive Data Protection	GCP	Discovers, classifies, and can de-identify/redact sensitive data in storage and streams.

Alongside these sit dedicated/enterprise DLP suites and CASBs (cloud access security brokers) that enforce across many SaaS apps. The GRC point is the same as with KMS and secrets: the tool is interchangeable; the control is "we can find sensitive data wherever it lives and we have policy that acts when it moves inappropriately."

DLP is detective and corrective, not a silver bullet

Be honest about what DLP can and can't do. It is strong at catching the accidental and the careless — the well-meaning employee emailing a spreadsheet to the wrong place, the bucket that's sensitive and public. It is far weaker against a determined insider who can encrypt, rename, screenshot, or photograph data to evade pattern matching, and it produces false positives that, tuned badly, train people to click through alerts. Treat DLP as one layer — discovery and guardrails against the common leaks — not as a guarantee. The most valuable thing it produces for a GRC program is often the data map: knowing what sensitive data you have and where, which underpins risk assessment, scoping, and breach response.

Quick check

A company wants to 'turn on DLP' and immediately set every policy to BLOCK any message or upload containing anything that looks like PII. Why is this likely to fail, and what's the better rollout?

It will succeed — aggressive blocking is the safest configuration

Start with discovery and monitor/alert mode to understand what sensitive data exists, where it flows legitimately, and the false-positive rate; classify the data; then enforce by classification, tightening to block on the highest-sensitivity flows — so you protect data without breaking legitimate work or training users to ignore alerts

It will fail only because PII patterns are hard to write; buy a better regex

Skip discovery and just block everything; tune later if people complain

Mapping to frameworks

DLP and data classification support the data-protection and privacy controls across frameworks, and the discovery output is reusable evidence:

SOC 2 — CC6.1/CC6.7 (protecting data) and the Confidentiality criteria (C1.1/C1.2 — identifying and protecting confidential information).
ISO 27001:2022 — Annex A 5.12 (classification of information), 5.13 (labelling), and 8.12 (data leakage prevention) — DLP is named almost directly.
Privacy regimes (GDPR, HIPAA, CCPA) — the data map and classification underpin data-subject requests, breach scoping, and demonstrating you know where regulated data lives.

The evidence package: the data-classification policy, the discovery/classification results (the data map), the DLP policies and their mode (monitor vs block), and incident records showing the control caught and handled leak attempts.

GRC Engineer's lens

DLP's biggest contribution to a GRC program is answering "where is our sensitive data?" with a map instead of a guess — which is the prerequisite for honest scoping, risk assessment, and breach response. When you review a DLP program, check three things: is there discovery/classification producing a current data map (not a one-time scan from two years ago); are policies tuned and enforced by classification rather than blanket-blocking or pure monitoring forever; and are there records of the control actually catching leaks. And set expectations honestly with leadership — DLP reduces accidental and careless exposure and gives you visibility; it does not stop a determined insider, so it belongs in a layered program alongside access control, encryption, and logging.

What to carry forward

DLP is discover-and-classify then prevent, applied across data at rest, in motion, and in use, using cloud-native tools (Macie, Purview, Google Sensitive Data Protection) or enterprise suites. Discovery comes first — you can't protect what you can't find — and enforcement should roll out by classification, from monitoring toward targeted blocking, to avoid breaking work and numbing users to alerts. Its honest limit is the determined insider; its biggest GRC payoff is the data map.

In the final lesson of this module you'll put the secrets half into practice — migrating a fictional codebase off hardcoded secrets and into a managed store, the single highest-frequency finding in this entire phase.