Vertex Financial: a DLP program the business has learned to override
Vertex Financial has 25,000 users and one DLP policy for PCI data across Exchange, SharePoint, OneDrive, Teams, and Endpoint. The rule uses the built-in Credit Card Number sensitive information type at default confidence and blocks external sharing with an override that requires a business justification. Incidents run at 200 a day; analysts sample 50 and find 46 are internal 16-digit account references and test cards. Ninety percent of blocked users override with text such as 'false positive'. Twelve thousand Windows devices are onboarded to Endpoint DLP, where a second rule blocks copying to USB for everyone; that rule has produced 1,100 tickets from Finance, who legitimately move settlement files to approved encrypted drives. Executives are now asking whether DLP works at all.
1. Cut the false positives without weakening PCI protection. Describe the changes and the evidence each one depends on.
Read the worked answer
Start from the sample, not from the knob
- 46 of 50 sampled incidents are internal account references or test cards. That is a fidelity problem, and raising the built-in SIT confidence to High would also suppress genuine 16-digit cards, so it is the wrong first move.
Changes, in order
- Exact data matching (EDM) against the actual card/account vault. This is the only change that separates Vertex's real numbers from look-alike internal references, and it removes most of the noise by construction. It depends on a clean, hashed source table and a refresh cadence - get that commitment from the data owner first.
- Instance counting and proximity on the residual built-in rule: require a plausible count in a single document or message, and use the SIT's supporting evidence (keywords such as card, expiry, CVV) so a bare number alone no longer trips.
- Split the rule by direction. Internal-to-internal sharing gets a policy tip or audit-only treatment; external sharing keeps the block. Nothing about PCI protection is lost because the exposure is outbound.
- Run the new rule in simulation over real traffic for two weeks before enforcing, and compare match volume against the current baseline.
What to avoid
- Adding blanket exceptions for the finance document libraries. That hides the problem and leaves the real card data unprotected. Target the pattern, not the location.
2. Ninety percent of blocks are overridden with meaningless justifications. Redesign the override so it stays usable but becomes a control.
Read the worked answer
Diagnosis
- Override is doing two jobs at once: a genuine business exception path and an escape hatch from a noisy rule. While 92% of incidents are false positives, users are behaving rationally - the fix is the rule first, the override second.
Redesign
- Remove override entirely on the external-sharing path for items that carry the PCI label or an EDM match. Block means block for the highest-risk case; provide a documented exception route through the service desk instead.
- Keep override on the lower-severity paths, but require a justification and add a link to the policy tip that explains what a valid justification contains. Vague text is the symptom of an unexplained control.
- Configure alerts on override events with aggregation and a threshold (for example, more than three overrides by one user in 24 hours), so repeat overriders surface as an investigation rather than a queue of one-offs.
- Use Activity explorer and the alert list to identify the top ten overriders by volume and coach them; if a group overrides weekly for a legitimate reason, that is a rule defect, not user behaviour.
Measure
- Track override rate per rule before and after. A useful target is under 10% of incidents overridden with a substantive justification; anything above that means the rule still does not match how the business works.
3. Finance genuinely needs to move settlement files to approved encrypted drives, but 1,100 tickets say the USB rule is wrong. Fix the rule without weakening device control.
Read the worked answer
What is wrong
- The rule blocks a channel (USB) for everyone rather than blocking sensitive content leaving through any channel. That is a perimeter control wearing a DLP rule's clothes, and it will always generate exceptions because most USB writes are benign.
Fix
- Scope the rule with a content condition - PCI EDM matches or the Confidential-Finance label - so writing unrelated files to removable storage is unaffected.
- Use endpoint DLP device control settings to treat the approved encrypted drives as known good where device identification is available, and pair that with an allow-list of restricted app groups so approved sync tools are not caught.
- Run the retuned rule in audit-only mode for two weeks and review volume by user and by content type before enforcing. This also gives you the numbers to answer the executives.
- Publish a self-service exception form with a defined turnaround, so the 1,100 tickets become a short, auditable list rather than a queue.
Do not do
- Simply excluding the Finance group from the rule. That leaves the exact content the program exists to protect unmonitored at the point of highest risk.
Report to leadership
- Track blocked sensitive copies versus total USB writes. The first number should be small and real; the second shows the rule is no longer a tax on normal work.