# DLP policy design and exception management

Move beyond a DLP-enabled indicator to channels, business rules and validated outcomes. Review false blocking and missed coverage separately.

Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress.

Sources checked: 2026-10-21

## Identify the protected channel

Email, browser uploads, SaaS sharing and removable media have different enforcement points. A policy working on one channel does not automatically protect another. Harbor declares internal, partner or public destinations and monitors no real application or network traffic. Explain the relationship among classification, purpose, destination and the intended response. Distinguish monitoring from actual blocking. Supported product locations and licensing can vary; verify the official scope for a real deployment. A dashboard indicator alone cannot demonstrate end-to-end protection across data movement paths.

## Test legitimate and negative cases

DLP tests should cover both prohibited sharing and legitimate work. Matching one sensitive example cannot reveal false blocking or missed channels. Define expected synthetic outcomes from business rules, not by copying product output. Record revision, channel and test scope together. Harbor’s evidence models illustrate this approach but execute no real DLP product. Classifier accuracy, policy enforcement and user override behavior need separate validation. A passing local example is not evidence that every client, file format and transfer route is controlled.

## Exceptions require scope and accountability

Business may require external sharing. Scope the purpose, recipient, data, duration, approver and compensating evidence. A user-override record does not establish authorized approval. Exempting everyone can turn a brief task into a standing exposure. Harbor workpapers show narrow scope and expiry. Real exceptions require the organization’s authorized access and data owners; this lesson opens no exemption and changes no DLP policy. Evaluate what evidence demonstrates the alternative control instead of treating an exception ticket as protection in its own right.

## From alert to outcome evidence

A DLP alert alone does not establish what actually reached which recipient. Review the observation point, transaction outcome, copies and user context. A block record does not rule out another channel. Protect evidence through minimal collection and appropriate access. Harbor computes a sharing decision from declared metadata rules; it scans no content, decrypts no file and blocks no packets. Control owners should show coverage gaps and retest plans. Measure success through correct business-rule enforcement at the intended boundary rather than alert counts alone.

## Working sequence

1. Define channel and data movement.
2. Translate business rules into expected outcomes.
3. Compare positive and negative synthetic cases.
4. Review exception scope and compensating evidence.
5. Record actual outcomes and coverage gaps.

## 1. DLP enabled

An enabled indicator explains neither channel nor business-rule scope. Without ownership and an enforcement boundary, it cannot establish general prevention of data loss.

This code is a local policy model; it does not replace actual content discovery, DLP or sanitization validation.

### Weak implementation
```js
s => s.dlpEnabled === true
```

### Corrected implementation
```js
s => s.dlpEnabled === true &&
  s.channelScoped === true &&
  s.businessRule === true &&
  s.ownerAssigned === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "dlpEnabled": true,
        "channelScoped": true,
        "businessRule": true,
        "ownerAssigned": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-channelScoped",
      "input": {
        "dlpEnabled": true,
        "channelScoped": false,
        "businessRule": true,
        "ownerAssigned": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-businessRule",
      "input": {
        "dlpEnabled": true,
        "channelScoped": true,
        "businessRule": false,
        "ownerAssigned": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "dlpEnabled": true,
        "channelScoped": true,
        "businessRule": true,
        "ownerAssigned": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-channelScoped",
      "input": {
        "dlpEnabled": true,
        "channelScoped": false,
        "businessRule": true,
        "ownerAssigned": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-businessRule",
      "input": {
        "dlpEnabled": true,
        "channelScoped": true,
        "businessRule": false,
        "ownerAssigned": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 2. The rule matches

One match measures neither false blocking nor missed paths. Without negative examples and coverage, a passing test does not validate the intended control boundary.

This code is a local policy model; it does not replace actual content discovery, DLP or sanitization validation.

### Weak implementation
```js
s => s.ruleMatches === true
```

### Corrected implementation
```js
s => s.ruleMatches === true &&
  s.positiveFixture === true &&
  s.negativeFixture === true &&
  s.coverageKnown === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "ruleMatches": true,
        "positiveFixture": true,
        "negativeFixture": true,
        "coverageKnown": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-negativeFixture",
      "input": {
        "ruleMatches": true,
        "positiveFixture": true,
        "negativeFixture": false,
        "coverageKnown": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-coverageKnown",
      "input": {
        "ruleMatches": true,
        "positiveFixture": true,
        "negativeFixture": true,
        "coverageKnown": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "ruleMatches": true,
        "positiveFixture": true,
        "negativeFixture": true,
        "coverageKnown": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-negativeFixture",
      "input": {
        "ruleMatches": true,
        "positiveFixture": true,
        "negativeFixture": false,
        "coverageKnown": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-coverageKnown",
      "input": {
        "ruleMatches": true,
        "positiveFixture": true,
        "negativeFixture": true,
        "coverageKnown": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 3. Business exemption

An exception request provides neither expiry nor compensation. Without narrow scope, duration and evidenced alternatives, a temporary need can create standing exposure.

This code is a local policy model; it does not replace actual content discovery, DLP or sanitization validation.

### Weak implementation
```js
s => s.exceptionRequested === true
```

### Corrected implementation
```js
s => s.exceptionRequested === true &&
  s.purposeDefined === true &&
  s.durationBounded === true &&
  s.compensationEvidenced === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "exceptionRequested": true,
        "purposeDefined": true,
        "durationBounded": true,
        "compensationEvidenced": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-durationBounded",
      "input": {
        "exceptionRequested": true,
        "purposeDefined": true,
        "durationBounded": false,
        "compensationEvidenced": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-compensationEvidenced",
      "input": {
        "exceptionRequested": true,
        "purposeDefined": true,
        "durationBounded": true,
        "compensationEvidenced": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "exceptionRequested": true,
        "purposeDefined": true,
        "durationBounded": true,
        "compensationEvidenced": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-durationBounded",
      "input": {
        "exceptionRequested": true,
        "purposeDefined": true,
        "durationBounded": false,
        "compensationEvidenced": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-compensationEvidenced",
      "input": {
        "exceptionRequested": true,
        "purposeDefined": true,
        "durationBounded": true,
        "compensationEvidenced": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## Exit evidence

- Channel/rule/revision and positive-negative test matrix.
- Time-bound exception, compensation and outcome record.

## References

- [Microsoft Purview · Data loss prevention overview](https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp)
- [NIST SP 800-122 · PII confidentiality foundation · April 2010](https://csrc.nist.gov/pubs/sp/800/122/final)