Riverton Health Plan: retention that deletes what audit needs

Why it disappeared

• Three independent failures stacked up. OneDrive is deleted 30 days after the account is disabled, so a request at day 90 is 60 days too late. The Claims-7y label is auto-applied to Exchange only, so it never touched the OneDrive files. And nothing created a retention event for the person, so no event-based clock ever started.

Redesign

1. Preserve the storage first. Raise OneDrive retention for departed users from 30 days to a period that covers the longest audit horizon, and route departures through a documented process rather than a Slack-adjacent email to the service desk.
2. Make the label event-based. Event-based retention needs an asset ID on the content, not a keyword. Store the employee or case identifier in a site or document property and configure the label to use it; 'Claim #' in a subject line is a search hint, not an asset ID.
3. Create the event at departure. Automate event creation from the HR signal (Power Automate or Graph) so the clock starts before the account is disabled, not after someone remembers.
4. Cover the gap with a hold. For roles with statutory exposure, place an appropriate retention policy or eDiscovery hold on OneDrive that does not depend on anyone acting on the day.

Verify

• Walk one simulated departure end to end: disable account, event created, label applied to OneDrive, item retrievable at day 90. Test it before the next audit request.

Outcome: the item is kept for seven years, then deleted - the three-year policy never deletes it.

Why, principle by principle

• Retention wins over deletion. Where one setting retains and another deletes, the delete is blocked for as long as the retention obligation lasts.
• Explicit wins over implicit. A label applied to an item is an explicit setting; a policy scoped to a mailbox location is implicit. The label's seven years governs.
• Longest retention period wins among competing retention settings, so if a second label or policy also retained it, the seven-year period would still control.

Practical consequences

• The three-year policy is not overridden globally; it still deletes everything the label does not touch. That is why the design works at all.
• At the end of seven years, what happens depends on the label's delete action and whether the label marks the item as a record. If the label only retains, the item becomes eligible and the underlying policy's delete then applies - which can mean deletion the moment retention lapses. Be deliberate about that rather than discovering it in an audit.
• If the label is a regulatory record, nobody, including an administrator, can remove it before the period ends. Choose record versus regulatory record per content type, not by default.

Most likely expected

• A label created about a year ago with a seven-year retention period has no items reaching end of retention yet, so an empty queue is the correct state. Emptiness is only alarming if items should have expired.

What to check, in order

1. Is disposition review actually enabled on the label, and are reviewers assigned? A label without reviewers will not produce work items even when retention ends.
2. When does the retention clock start - from creation, from when the item was labeled, or from an event? A misconfigured start date shifts every future queue date.
3. Did auto-apply actually match the 40,000 items, or are they the ones users labeled by hand? Compare the auto-apply policy simulation results and its coverage report against Content explorer.
4. Are the labeled items records or ordinary retained items? That changes what reviewers can do at end of retention.

Then demonstrate control, not absence of activity

• Run a test label with a one-day retention and disposition review, and prove an item reaches a reviewer and can be disposed or extended with an audit trail. That evidence is far stronger for an auditor than an empty queue and a policy screenshot.