DLP Blocks Invoices, Sales Encrypts With ZIP Passwords
Tailspin Toys has 1,100 users on Microsoft 365 E5. A DLP policy blocks any email containing 13-19 digit numbers near the word 'invoice' to external recipients, with a policy tip. The finance team sends 600 invoices per month to 140 trading partners. Since the policy went live, 210 messages were blocked in 6 weeks; 60% were false positives because order numbers and phone numbers matched. Sales has started sending pricing sheets as password-protected ZIP files, with the password in a separate plaintext email. A top-5 partner refuses TLS 1.2 and can only accept SMTP over TLS 1.0; the partner accounts for 18% of revenue. The CISO wants no unencrypted PII outbound and no user friction. The compliance officer wants an auditable exception process. The IT team proposes disabling the DLP policy for finance.
1. Assess the DLP false positives and propose a revised policy design.
Read the worked answer
The policy is matching numeric patterns, not invoice semantics. Blocking 210 messages with 60% false positives means the rule is both ineffective and corrosive: users will find workarounds such as the ZIP practice. Redesign:
- Use a sensitive information type with context: invoice number plus a vendor or customer name, or a document fingerprint of the invoice template. Do not rely on a bare 13-19 digit regex.
- Add confidence levels and instance counts; require at least two indicators before blocking.
- Run in test mode with policy tips for 2-3 weeks and review matches by sender, recipient, and content.
- Allow override with business justification for low-confidence matches; log overrides.
- Scope the block to external recipients and to finance, not all 1,100 users.
- Add a separate rule for IBAN and account numbers with checksum validation where possible.
Do not disable the policy for finance; that removes the only control over the real data. The goal is precision, not zero friction.
2. How should the organization handle the partner that cannot do TLS 1.2 and the password-in-email ZIP practice?
Read the worked answer
TLS 1.0 is not acceptable for PII, even for an 18%-revenue partner. The right answer is not to downgrade the tenant. Options:
- Use message encryption (Microsoft Purview Message Encryption or a partner portal) so the payload is protected end to end regardless of SMTP TLS. The partner receives a link and authenticates.
- If the partner can only do SMTP, set up a dedicated connector with TLS 1.2 and a fallback that refuses rather than downgrades; force the exception through the portal.
- For the partner's inbound mail, do not accept TLS 1.0; require the portal or a managed file transfer.
On ZIP plus password: this is not encryption in any meaningful policy sense because the password travels in the same channel and the email is often not protected. Block password-protected archives at the edge, add a DLP rule that detects 'password' plus an archive attachment, and replace the practice with sensitivity labels that encrypt the document. Sales should not invent cryptography.
3. Design an auditable exception workflow that satisfies compliance without making DLP optional.
Read the worked answer
Exception workflow:
- A request form captures sender, recipient, data type, business justification, partner, and duration.
- The data owner and compliance approve; security reviews the compensating control (message encryption, portal, NDA).
- The exception is time-bound (maximum 90 days) and scoped to a domain or recipient, not a user-wide bypass.
- The exception is implemented as a DLP rule with an override policy tip and audit logging, not by disabling the policy.
- A monthly report of exceptions goes to compliance; automatic expiry and re-review are enforced.
- Any override by a user without approval triggers an alert and manager notification.
This keeps DLP auditable and prevents the 'disable for finance' shortcut. It also separates a legitimate business exception from a shadow workaround.