Every outbound transfer gets a content-inspection score by blending its true sensitivity (public → internal → confidential → PII) with pattern-matching noise, mimicking imperfect regex/keyword detectors for card numbers, SSNs and confidentiality labels. The DLP rule strictness sets two thresholds: above the upper one a transfer is blocked outright; in the band just below it, the transfer is queued for a manager to approve or deny; below both, it passes.
score = base(sensitivity) + noise
blockAt = 0.95 − strictness/100·0.65
holdAt = blockAt − 0.18
score ≥ blockAt → BLOCK
score ≥ holdAt → HOLD (manual)
else → ALLOW
- Rule strictness — raising it catches more real leaks but also flags more legitimate public/internal data as suspicious (false positives).
- Channel — email, USB, cloud upload and web form are common exfiltration paths; the scanner treats every channel identically here, as real DLP appliances do.
- Data sensitivity — the label chosen for the test transfer; higher sensitivity raises its detection score before noise is applied.
- False positives — legitimate public data blocked by mistake; watch this counter climb as you push strictness toward 100%.
Real-world relevance: production DLP systems make this exact trade-off — stricter content rules reduce data breaches but increase user friction and help-desk tickets from blocked legitimate work, which is why most rollouts start in "monitor only" mode before enforcing blocks.