Seven-year retention versus a project that must be destroyed, and a DLP policy that has never matched anything
Litware Financial has 3,000 users on Microsoft 365 E3, with 400 E5 licences held by finance, legal, and the executive team. The regulator requires seven-year retention of all Exchange and Teams content, immutability for the first two years, and defensible deletion afterwards. Project Falcon, a 120-member Microsoft 365 group, must have all its content permanently destroyed 30 days after the project closes. A DLP policy blocking external sharing of documents containing customer account numbers was published six months ago; the compliance dashboard shows zero matches, although a sampling of 40,000 SharePoint documents confirms thousands contain the number pattern. Legal wants 12 custodians placed on hold for an investigation without tipping them off.
1. How do you design retention so the seven-year rule does not defeat the Falcon deletion, and what does immutability actually cost you?
Read the worked answer
Recognise the trap first: retention beats deletion, and deleting a site does not delete retained content. With a seven-year retain policy in place, deleting the Project Falcon group leaves its content sitting in the preservation hold library for the remaining term. The Falcon requirement must be solved inside the retention model, not alongside it.
- Baseline: a retention policy covering both Exchange and the Teams locations (channel messages and chats are separate selections from Exchange - verify both, or you will retain email and lose chat), retain seven years.
- Immutability: a record label for the first two years. Choose locked record, not regulatory record. A regulatory record cannot be removed even by an administrator - apply it to the wrong content via auto-labelling and you have created an irreversible mess. Locked records can be unlocked with justification, which is the defensible position an auditor actually wants.
- Falcon: apply a label with a 30-day delete and no retain period to the group's site and mailbox. Labels take precedence over policies, so the deletion wins over the seven-year policy. Do not mark Falcon content as a record - records cannot be deleted. Event-based retention triggered by 'project closed' is cleaner but is an E5 records-management feature.
- Prove it: create a document in the Falcon site, apply the label, and confirm through disposition review that it actually deletes at day 30 - before the project closes, not after.
2. The DLP policy shows zero matches against known-positive data. What are the plausible causes, and how do you prove which one it is?
Read the worked answer
Zero matches on 40,000 known-positive documents is almost always one of five things, and you can discriminate between them in an hour.
- Mode. The policy was published in simulation or test-with-notifications and never flipped to enforce. Check status first - this is the single most common cause.
- Location or scope. SharePoint and OneDrive selected but not Exchange; a security-group scope that excludes the actual document owners; or the affected sites sit in an excluded location.
- The sensitive information type does not match the real data. Account numbers may need a supporting keyword, a checksum, a proximity window, or a lower confidence/instance-count threshold. Prove it by building a one-page test file with the exact pattern and running the policy Test against it.
- Wrong engine. A rule authored as an Exchange transport rule or a legacy compliance policy does not appear in the dashboard you are reading.
- Wrong report window. Activity explorer retains 30 days by default, so 'no matches' may simply mean 'no matches in the period you queried'. Use the DLP rule matches report and Content explorer to see which sensitive information types the classifier actually found on real documents.
Order of work: fix the sensitive information type, re-simulate against one sample site, confirm matches appear, then enforce. Going straight to block on a broken classifier produces a political incident, not compliance.
3. Which of these requirements does Microsoft 365 E3 not cover, and how do you scope the 400 E5 licences?
Read the worked answer
E3 covers the routine; E5 covers the judgement-heavy.
E3, fine for all 3,000: DLP for Exchange, SharePoint, OneDrive, and Teams; manual sensitivity labels with encryption; retention policies and basic retention labels; standard eDiscovery with holds and content search.
Requires E5 or E5 Compliance: client-side and service-side auto-labelling; exact data match and trainable classifiers (likely necessary for reliable account-number detection at scale); records management, meaning labels that declare content a record or regulatory record and event-based retention; eDiscovery Premium for custodian management, review sets, and conditional filtering; Insider Risk Management; Communication Compliance.
Scoping decision. The 400 seats are broadly in the right places, but check the 12 custodians individually: eDiscovery Premium licensing attaches to the custodian and the reviewer, so a custodian on E3 cannot be managed inside a Premium case even when legal holds an E5 seat. Move those 12 first - that is the cheapest possible fix for the immediate legal deadline.
For the remaining 2,600, design so no E5 feature sits on the critical path: manual and default labels for confidential content instead of auto-labelling, a custom sensitive information type with a keyword instead of exact data match, and standard eDiscovery with the limitation documented. Tell the regulator what is and is not covered rather than under-delivering silently - that documentation is itself part of defensibility.