Moving DLP from Monitor to Block Under a Regulatory Clock
A 12,000-employee health insurer enabled Enterprise DLP in monitor mode across endpoint, SaaS API and inline web. After 30 days it is generating 340 incidents a day; the compliance team sampled 100 and found 92 false positives. The dominant pattern is a 16-digit regex with Luhn validation intended to catch payment cards, and it also fires on internal claim identifiers that happen to pass Luhn. Roughly 8% of incidents involve password-protected 7z archives leaving through personal webmail, which the inline engine cannot inspect. Another cluster involves screenshots of member tables pasted into Microsoft Teams chats. The CISO wants blocking enabled on the top three patterns within 30 days because a regulator inquiry is open. Two of those top three patterns are owned by a business unit that has not yet been consulted, and the service desk has no runbook for handling DLP blocks.
1. How would you cut the 92% false-positive rate without eroding detection of real card data?
Read the worked answer
Tune the pattern, not the alert queue. Suppressing alerts is how DLP programmes quietly go blind.
1. Add context to the pattern. A bare Luhn-valid 16-digit string is a weak signal. Combine it with proximity keywords within a window (card, expiry, CVV, PAN), or with validation that the issuer range is live. If claim identifiers are a known internal format, write an exclusion for that format specifically rather than loosening the digit rule - exclusions should be narrow and documented.
2. Classify the source. Separate incidents by data source: a spreadsheet named claims_extract or a folder used for test data behaves differently from an outbound email. Restrict the profile to the repositories where card data legitimately lives, and apply a different profile elsewhere.
3. Use document classification and fingerprinting. For card data you can go further with exact-data-match on your own known test PANs to suppress them definitively, and indexed document matching for the member datasets that generate the screenshot problem.
4. Review by cluster, not by alert. Group the 340 daily incidents by pattern, source and destination, and disposition whole clusters with a documented rationale.
Target: sample again after tuning. Getting to under 20% false positive on the top pattern is realistic within two weeks; chasing 5% before enabling block is a schedule trap, and 92% suggests the pattern was never validated against production data.
2. Address the encrypted-archive and Teams-screenshot gaps with controls that actually work.
Read the worked answer
Both gaps exist because the data is opaque to the engine at the point of inspection. Fix the inspection point, not the pattern.
Password-protected 7z leaving via personal webmail: the inline engine cannot decrypt it, so do not write a pattern that pretends otherwise. Options in order of preference:
- Block encrypted archives to unsanctioned web destinations outright - encrypted archive outbound to personal mail is a low-value business flow and a legitimate default-deny.
- Allow encrypted archives only to sanctioned destinations and only from endpoints where the DLP agent can inspect before encryption or capture the archive event with file metadata.
- If a business flow genuinely needs it, require the password be shared out of band and route via an approved managed file transfer path that logs recipients.
Screenshots pasted into Teams: screen capture is invisible to content inspection. Controls that work: on managed endpoints, restrict screen capture of applications handling member data and log the attempt; in Teams, apply a DLP policy to chat and channel messages that blocks image uploads containing member data where the sensitivity label is present; and use document classification so the paste carries a label the policy can act on. Detect the pattern of behaviour too - repeated image pastes from a clinical application to chat is a signal even without content.
Be honest about the residual: a personal phone photographing a screen is outside every one of these controls. Say so rather than implying coverage.
3. The CISO wants blocking in 30 days. Give a go/no-go position with conditions.
Read the worked answer
Conditional go, on a narrowed scope. Blocking with no runbook produces the same outcome as the 300 VPN bypasses elsewhere in this estate - users find a way around, and the bypass is invisible.
What can go live inside 30 days:
- Blocking on the tuned card pattern for the highest-risk destinations only: personal webmail, unsanctioned cloud storage, and removable media. Narrow destination scope keeps user impact low while the regulator's concern is answered.
- Blocking on encrypted archives to unsanctioned destinations, which has the least legitimate business impact of anything on the list.
Conditions that must be true first:
- A service-desk runbook exists - what the user sees, who to call, who can approve an override, and a target resolution time. Without this, the first block is a business outage.
- Both unconsulted business units have signed off on user impact. A block imposed on a unit that was not asked will be escalated and reversed, which is worse than a documented monitor-mode decision.
- An override process with named approvers and automatic expiry, plus weekly reporting of override counts.
- A defined rollback: one policy change and a named person authorised to make it.
What I would tell the CISO directly: blocking the tuned card pattern plus encrypted archives is defensible in 30 days. Blocking the third pattern before it is tuned would generate more false positives than true positives and would undermine the regulator narrative, not support it. Offer a 14-day monitor-then-block ramp for that one.