SharePoint Retention Period: What You Need to Know

SharePoint Retention Period is a policy-driven feature, part of Microsoft Purview, that controls how long content is kept before it’s deleted or archived. It’s how you actually enforce a retention rule instead of relying on someone remembering to clean up old files.

In this post: The three pieces · Why it matters · Retention labels vs. legal hold · The mechanism: the Preservation Hold Library · When would you actually use this? · Best practices · Applying a retention label via PowerShell · Related reading

The three pieces

Retention labels: applied to individual files, manually or by policy, defining how long that specific content is retained and what happens when the period ends.
Retention policies: applied at a higher level — entire SharePoint sites, OneDrive accounts, Exchange mailboxes, Teams — for large-scale governance rather than file-by-file.
Disposition reviews: a final human check before content is permanently deleted, so legal/compliance can confirm records were reviewed before removal.

Why it matters

Compliance: GDPR, HIPAA, and various ISO standards specify how long certain data must be kept — non-compliance has real penalties.
Security: keeping data indefinitely is its own risk; retention policies dispose of outdated content in a controlled way instead of it sitting around as a liability.
Storage: without a policy, SharePoint storage grows unchecked — this automates the cleanup instead of a manual purge project.
Litigation protection: ensures required records are actually retained through the period needed for eDiscovery and legal hold obligations, covered in more depth in SharePoint Compliance Policy and Governance.

Retention labels vs. legal hold

These get conflated because both prevent content from disappearing, but they’re triggered and scoped very differently. A retention label/policy is a planned, ongoing schedule — “keep invoices for 7 years” — that applies broadly and predictably, decided in advance regardless of whether litigation is happening. A legal hold (technically an eDiscovery hold) is reactive and situational — applied to a specific set of content tied to a specific matter, the moment litigation or an investigation becomes reasonably anticipated, and it overrides normal retention/deletion schedules entirely for as long as it’s active. A file that’s due for automatic deletion under its retention label will still be preserved if it’s also under an active legal hold — hold always wins over a scheduled disposition. If your org is handling both, know which one governs a given piece of content before assuming a retention period is the full picture.

The mechanism: the Preservation Hold Library

Worth knowing exactly how “a legal hold always wins” and “content under a retention label survives an edit” actually happen, not just that they do: SharePoint and OneDrive automatically create a hidden system library — the Preservation Hold Library — on any site where a retention label, retention policy, or eDiscovery hold applies. Whenever someone edits or deletes content that’s under retention, the visible action appears to succeed normally for that user, but a copy of the original version is quietly captured into this hidden library first. The user sees a normal delete or edit; compliance still has the original.

Not every label behaves identically here: a standard retention label only triggers a preserved copy on deletion; a record label also captures on edit; a regulatory record label goes further and blocks edits and deletes outright rather than silently preserving around them. One real operational consequence worth flagging to whoever owns storage budgets: Preservation Hold Library content counts against the same SharePoint storage quota as everything else, and because it’s invisible in the normal library view, it’s a common, hard-to-diagnose cause of a site’s storage climbing well past what the visible content would suggest.

Disposition review is a final human check before content is permanently deleted, so there’s a review before anything’s gone for good.

When would you actually use this?

Finance/legal needs customer records kept for a specific period (7 years is common) and disposed of afterward — not kept forever, not deleted early.
Storage costs are climbing and nobody’s been cleaning up old document libraries — automated expiration handles this without a dedicated cleanup project.
Legal asks whether a specific class of documents has actually been retained per policy — disposition review logs give you the answer instead of guessing.

Best practices

Understand the regulatory requirement before configuring anything — what applies to your industry determines the actual retention period, not a guess.
Use different labels for different content types — financial records and temporary project files don’t belong on the same retention schedule.
Automate application via Purview rather than relying on users to apply labels manually.
Enable disposition review before permanent deletion, so there’s a human check before anything’s gone for good.
Test in a controlled scope first before rolling a policy out organization-wide.

Applying a retention label via PowerShell

Worth using the dedicated cmdlet rather than hand-setting the internal ComplianceTag field directly — Set-PnPRetentionLabel is the current, purpose-built way to do this, and it fails with a clear warning rather than silently doing nothing if the label doesn’t actually exist on the site, which a raw field-value update won’t catch:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/YourSite" -Interactive

# Apply a retention label to every item in a library at once
Set-PnPRetentionLabel -List "Documents" -Label "RetentionLabelName"

# Or target specific items rather than the whole library
$items = Get-PnPListItem -List "Documents"
Set-PnPRetentionLabel -List "Documents" -Identity $items -Label "RetentionLabelName"

Write-Host "Retention label applied successfully!"

Setting the label at the library level (the first line above) applies it going forward to everything already there and anything added later, which is worth doing over an item-by-item loop whenever the whole library should genuinely follow one retention rule.

Worth checking what’s currently applied before assuming a library is unlabeled — a label set previously (by policy, or by someone else running this exact script) doesn’t show up anywhere in the normal library view, so confirming state before making a change is worth the extra call:

Get-PnPListItem -List "Documents" | Select-Object Id, @{N="RetentionLabel";E={$_.FieldValues["ComplianceTag"]}}

Reading the applied label back is one of the few places the raw ComplianceTag field name is still the right tool — there’s no dedicated “get” cmdlet mirroring Set-PnPRetentionLabel, so checking current state means reading the field directly even though setting it doesn’t anymore.

Useful References

SharePoint Audit Trail: What You Need to Know — retention determines how long the activity this tracks stays queryable.
SharePoint Compliance Policy and Governance — the broader governance framework retention labels sit inside.

One more tip in the bag. Questions or corrections? Comment below.