# Data classification and DLP

Writing “confidential” on a document does not protect it by itself. Ownership, permitted use, recipients, storage and exceptions must work together. This guide connects discovery and labelling to a DLP pilot and incident review, using customer-list and proposal examples.

Original SecNet educational content with fictional examples, not publication/endorsement by referenced organizations. Page exercise choices last only for the open session; no real organizational data is collected.

2026.10 · 2026-10-21

## What should I do tomorrow?

1. Choose one sharing area and its purpose with a data owner.
2. Classify ten synthetic documents and compare permitted recipient/channel decisions.
3. Pilot one DLP rule in observation mode and record false positives and misses.

## Concepts

**Bilgi sahibi / data owner** — Business role approving classification and sharing conditions based on purpose and impact.

**DLP** — Controls that detect, warn about or restrict defined data movements; not a replacement for labelling or access controls.

**Yanlış pozitif / false positive** — An activity flagged by a rule but found permissible after review.

**Etiket / label** — Classification metadata helping people or systems handle information; enforcement varies by tool.

**Veri keşfi / discovery** — Finding data and context in authorized stores without unnecessarily duplicating its contents.

## Process map

### 1. Scope and owner

Business owner + data governance

Choose one business process and its data stores.

Owned data map.

### 2. Class and handling

Information owner

Approve labels and recipient/channel rules with examples.

Handling matrix.

### 3. Pilot and observe

Security + privacy

Measure detection and user impact using synthetic examples.

Reviewed pilot results.

### 4. Controlled enforcement

Control owner + support

Introduce warning, blocking and exception paths.

Approved rule and rollback plan.

### 5. Monitor and improve

Data owner + SOC

Review alerts, uncovered channels and false positives.

Time-bound improvement record.

## Connect classification to the business

Design classes around disclosure, alteration and unavailability impacts rather than document counts. An internal lunch menu and an undisclosed merger document need different treatment. The data owner decides; IT implements. Personal data, trade secrets and contractual restrictions may need additional attributes.

Start with a few understandable classes. Public, internal, confidential and restricted are an illustrative model here, not universal legal classifications. Define authority to raise/lower labels and handle mixed-content documents. Test with representative users whether control effort matches the business need.

- [ ] Label definitions include example documents and decision owners.

Reference: [NIST SP 1800-39 — Initial Public Draft (12 February 2026)](https://csrc.nist.gov/pubs/sp/1800/39/ipd)

## Where discovery and labelling begin

Begin with a bounded area such as a sales file share. Map repositories, email, SaaS exports and local copies. Set authorization, logging and sampling rules for discovery. Record location, suggested class and confidence instead of copying raw customer content into the report.

Automation infers from patterns and keywords but can miss business context. A test number may resemble a real identifier. Include owner review and representative validation. Test new-file labels, label propagation during copying and traceability of label removal as separate behaviours.

- [ ] Discovery reports avoid unnecessary sensitive content.

Reference: [NIST SP 1800-39 — Initial Public Draft (12 February 2026)](https://csrc.nist.gov/pubs/sp/1800/39/ipd)

## Translate labels into handling rules

For each class define readers, external sharing, transfer channels and storage locations. Access groups and visible labels must stay consistent. Time-limited external sharing needs recipient verification, download decisions and revocation. Do not claim complete prevention of screenshots or onward disclosure.

Classification alone does not determine retention. Link purpose, legal holds and deletion rules to the separate retention matrix. Confidential files are not kept forever; public files still require integrity. Users without disclosure authority must not legitimize external sharing simply by relabelling a file.

Illustrative handling matrix; adapt locally

| Class | Sharing | Control |
| --- | --- | --- |
| Public | Approved publication | Publisher and integrity control |
| Internal | Defined staff group | Authenticated access |
| Confidential | Verified need-to-know recipient | Approved channel, expiring access |
| Restricted | Named authorized small group | Strong access, monitoring, explicit approval |

- [ ] Labels, access, channels and retention decisions are linked.

Reference: [NIST SP 1800-39 — Initial Public Draft (12 February 2026)](https://csrc.nist.gov/pubs/sp/1800/39/ipd), [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Run a controlled DLP pilot

Write the detection condition, covered channel and expected response. For a synthetic customer-list transfer to an unapproved external recipient, start in observation mode. Measure valid detections, false positives and missed synthetic tests separately. Silence from the tool does not demonstrate absence of leakage.

Move next to warnings and, where justified, blocking. Predetermine ownership, exception duration and rollback if essential work is disrupted. A user justification is not an unlimited bypass. Bind exceptions to recipient, purpose and duration instead of turning one case into permanent permission.

- [ ] The pilot has success criteria, support and rollback paths.

Reference: [NIST SP 1800-39 — Initial Public Draft (12 February 2026)](https://csrc.nist.gov/pubs/sp/1800/39/ipd), [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Manage blind spots and privacy

An email control alone does not cover browser uploads, personal cloud, USB copies or API exports. Explicitly report visibility into encrypted archives, screenshots, unsupported files and offline devices. Assess unmanaged-device access separately. Do not assume labels survive every file format or conversion.

Alert reviewers do not need unrestricted access to every employee document. Limit previews and prefer incident IDs, rule IDs, file metadata and controlled references. Log reviewer access and justify retention. DLP deployment does not itself authorize unrelated employee-performance monitoring.

- [ ] Channel gaps and reviewer permissions are recorded.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## From alert to verified improvement

When a fictional proposal goes to personal email, first establish recipient, class, purpose and delivery status. Message recall does not remove every copy. Incident responders restrict access and preserve evidence; legal/privacy staff assess applicable notification duties. A choice in this teaching page is not an incident record.

Closure should go beyond warning the user. Examine the sharing workflow, missing labels and usability of approved channels. Record the rule version and reason for changes, then rerun the same permitted/prohibited samples. Report improvement only for the tested channels and sample population.

- [ ] Closure is validated through rule testing and process correction.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Common mistakes and better approaches

**Giving every file the highest class.** — Justify classes with impact and usage examples.

**Treating a label as access enforcement.** — Test recipient, link and file-format behaviour separately.

**Counting blocked events as success.** — Measure reviewed accuracy, user impact and uncovered channels together.

## Decision examples and explained answers

### False alarm

A test customer number is blocked during external sharing.

**Disable the rule for everyone.** — Revisit

Global disabling exposes genuine data too. It broadens the exception before its cause is understood; record the sample and permitted activity before tuning.

**Validate the sample, narrowly except it and retest.** — Supported approach

The owner confirms the test nature. Scope any change narrowly, then retest both genuinely sensitive and permitted test samples to check protection and workflow.

### Labelled but exposed

A confidential proposal opens through an anonymous link.

**The label is sufficient.** — Revisit

A visible label does not authenticate recipients. Anonymous sharing fails to enforce the intended boundary, so access and possible copies need separate review.

**Restrict the link and review access history.** — Supported approach

Control the link and redefine authorized recipients. Check log coverage and give responders the necessary facts; do not assume nobody accessed it without evidence.

### Retention decision

An expired confidential report is under a legal hold.

**Delete automatically because retention expired.** — Revisit

The label and expiry do not cancel preservation. Uncontrolled deletion can destroy relevant evidence; the authorized legal scope governs the decision.

**Validate the authorized hold scope.** — Supported approach

Preserve only in-scope records, tracking ownership, access and review. After release, return to the normal retention/disposal workflow under control.

## Official references

- [NIST SP 1800-39 — Initial Public Draft (12 February 2026)](https://csrc.nist.gov/pubs/sp/1800/39/ipd) — Discovery, identification and labelling context; an initial public draft, not a final standard. The example matrix and DLP workflow are original SecNet teaching.

- [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) — Reference for control families; example workflows are SecNet adaptations, not automatic compliance mappings.