Build a defensible Microsoft Purview retention and legal-hold decision tree

Source facts: retention and eDiscovery holds serve different purposes

Microsoft’s retention-policy documentation describes policies that retain content, delete it, or retain and then delete it. Policies can apply at a container level so content in supported locations inherits the settings. Microsoft directs organizations toward retention labels and file-plan capabilities when item-level or higher-value business, legal, or regulatory record keeping is needed.

Microsoft’s eDiscovery hold guidance describes preserving content relevant to a case and distinguishes a case hold from long-term lifecycle retention. It notes that a hold can take time to take effect and documents workload-specific locations and considerations. Microsoft’s related hold-management guidance warns that identity or location changes can require the policy to be updated and reapplied.

Microsoft documentation is product guidance, not legal advice. Applicable law, court orders, regulatory rules, contracts, records schedules, privacy obligations, and litigation strategy determine what must be preserved or deleted. Features, supported locations, indexing, processing time, limits, and licensing vary. Qualified legal, records, privacy, and Microsoft 365 administrators must approve the design.

DSE recommendation: use one decision record before choosing a control

For every proposed rule, capture the authority and exact business statement before opening Purview. Identify the content class, creator or custodian, event that starts the clock, duration, required disposition, geographic or business scope, exceptions, legal owner, records owner, technical owner, and evidence needed. “Keep Teams for seven years” is not sufficiently precise.

Choose the purpose branch. Use lifecycle controls for approved ongoing retention and deletion. Use record controls when content needs item-level classification, event-based retention, disposition, or record restrictions. Use an eDiscovery hold for scoped case preservation under authorized legal process. Do not use a permanent hold as a substitute for records design.

Map the actual workload. Trace where the content lives, including group mailboxes, SharePoint sites, OneDrive, meeting artifacts, chats, channel messages, private or shared channels, attachments, versions, and connected applications. A user-facing product name can hide multiple storage locations.

Resolve conflicts and priority. Model overlapping retention, deletion, labels, records, and holds using current Microsoft retention principles. Ask legal and records owners to decide the intended result. Do not simplify a conflict by removing a hold or shortening retention without authority.

Confirm support and license. Verify the tenant, workload, policy type, scope, label behavior, limits, and required licenses for every affected user or feature. Record assumptions that depend on Microsoft service behavior and set a review trigger for product change.

Pilot representative content. Use controlled test locations and items to validate publication, application, event trigger, preservation after edit or deletion, searchability where relevant, disposition, user experience, and audit. Respect documented processing time; do not infer failure or success too early.

Verify deployment continuously. Check policy and per-location status, errors, renamed or moved sites and mailboxes, departed custodians, scope changes, and new collaboration locations. For case holds, follow the legal process to update or retry after identity and location changes.

Require separation of duties for creation, approval, modification, and release where risk warrants it. Maintain a register connecting each Purview object to its requirement, scope, owner, approval, test evidence, exceptions, and next review. Alert or review unauthorized policy, label, case, hold, scope, and role changes.

Release is a governed decision, not cleanup. Confirm legal authorization, overlapping requirements, disposition effect, processing status, and evidence before removing a hold or policy. A defensible program can explain why the control exists, what it covers, how it was tested, who monitors it, and who may end it.

Reject any configuration request that lacks an approved authority, content definition, start event, duration, disposition, scope, and owner. Pause deployment when the test cannot locate expected content, protected content can be removed contrary to the approved outcome, or policy status remains unresolved. Technical administrators should surface those failures to counsel and records owners rather than reinterpret the requirement themselves.

Official references

Microsoft, Automatically retain or delete content by using retention policies.

Microsoft, Create holds in eDiscovery.