Microsoft Purview records management

Records management in Microsoft Purview is the structured way to declare specific content as a record — making it immutable, preserving it for a defined period, and disposing of it through a formal process. It's retention with teeth, designed for the kinds of compliance regimes where "we kept the document for 7 years" needs to be defensible in court.

What declaring a record does

When a retention label has the "Mark items as a record" setting and a user (or a policy) applies it:

• The item becomes immutable: no edits, no deletions, no renames.
• Some metadata is locked to the value at declaration.
• The label can only be removed by a user with the right privileges, and only to specific other labels.
• A disposition review can be required before final deletion at the end of retention.

A regulatory record is even stronger: once applied, the label cannot be removed by anyone (including admins), and content can never be unlocked.

The records management workflow

1. Define a file plan — a hierarchy of record categories with retention periods, triggers, and disposition rules. Purview's File Plan view lets you import a file plan from spreadsheet.
2. Publish retention labels mapped to record categories.
3. Apply labels — manually by users, or automatically by content match, machine-learning classifier, or trainable classifier.
4. Trigger retention — by content creation date, last-modified date, or event-based retention (e.g., a customer contract is closed; retention starts then).
5. Disposition review — at the end of retention, named reviewers approve deletion, extension, or relabel.
6. Audit trail — every record action is logged.

Event-based retention

A particularly useful capability: retention triggers from an event like contract closure, employee departure, or product end-of-life. The event is typically published by an external system (Dataverse, an HR system) via the Microsoft Graph. When the event fires, the timer on relevant records starts.

This means "retain for 7 years after the project ends" is enforceable, where a static creation-date trigger would fail.

Auto-application

To minimise reliance on user behaviour, labels can be auto-applied to content matching:

• Sensitive information types (regex + context).
• Trainable classifiers (ML categorisation).
• Keywords or properties (a SharePoint column value, a content type).

Auto-application is the practical way to apply records management at scale.

Licensing

Basic retention labels are included in Microsoft 365 E3. Records management — declaring records, event-based retention, disposition review — requires Microsoft 365 E5 or the Purview Records Management add-on.

When you need it

For industries with statutory record-keeping (finance, healthcare, public sector, legal, energy), records management is essential. For organisations with looser obligations, retention policies plus sensitivity labels are usually enough — records management adds operational overhead that needs to be justified.

When you do need it, document the file plan as carefully as you would any legal artefact. The whole point is defensibility, and undocumented decisions don't defend themselves.

A worked example: a 12-year retention plus a legal hold

A financial-services firm needs to keep all client correspondence for 12 years after the client relationship ends, and to place a legal hold on a subset when a matter opens.

• File plan. One record label per business function (Client Correspondence, Investment Advice, Compliance Attestations). Not one per team.
• Retention rule. Record; retain for 12 years starting from a date-triggered event ("Client offboarded") published from CRM into an event-based retention topic.
• Immutability. Regulatory record where the regulator requires it (locks the label from modification/deletion by anyone, including tenant admin); standard record where it doesn't. This choice is one-way — a regulatory record cannot be downgraded.
• Disposition. Manual disposition review by the compliance officer; a second-approver rule for anything over a stated financial threshold.
• Legal hold. When a matter opens, an eDiscovery hold is placed on relevant custodians. This overrides deletion behaviours until the hold is released, without changing the underlying retention rule.

The unglamorous part is the CRM-to-Purview event topic wiring. Getting the "offboarded" signal to Purview reliably is what makes date-triggered retention work; without it, retention rolls forward from the file's create date and everything expires too early.

Decision matrix: retention policy vs. retention label vs. record label

| You need to… | Use | | --- | --- | | Keep everything in a container (site, mailbox, Team) for N years | Retention policy | | Apply different rules to specific items based on classification | Retention label (non-record) | | Prevent deletion/modification of specific items with disposition | Record label | | Meet SEC 17a-4/FINRA WORM requirements | Regulatory record label | | Trigger the retention clock on a business event (contract end, client offboarded) | Event-based retention on any label type | | Support one-off legal preservation independent of the retention rules | eDiscovery hold |

When records management is the wrong tool

• You have no statutory obligation. Retention labels or plain retention policies do the job at a fraction of the operational cost.
• You cannot commit to disposition review. A disposition queue that nobody triages is worse than no records programme at all — the whole point is a defensible chain of decisions.
• You are still on OneDrive/SharePoint with no site classification. Fix information architecture and sensitivity labels first (SharePoint IA, sensitivity labels deep dive); records without a target is theatre.
• Users would need to classify every item manually. That fails everywhere it's been tried. Auto-application by container, sensitive-info type, or trainable classifier is the only sustainable posture.

MSP checklist

• Do not ship a records programme without a records officer named on the client side. Records management is a governance function first; the tooling only executes decisions someone accountable made.
• Sizing. For a mid-market client, plan on 6–8 record labels, not 60. Start with client correspondence, contracts, financial records, HR files.
• Auto-apply pilot. Publish records auto-apply against a subset of sites (one department) for at least one full retention cycle before extending tenant-wide. Bad classification at scale is enormously painful to undo.
• Disposition workflow. Give the client a documented monthly cadence for disposition review with named roles. The default queue in the compliance portal is fine for small volumes; hand off to eDiscovery for anything requiring a defensible export before disposal.
• Regulator evidence. Keep the file plan, the auto-apply rules, and the disposition reasons in the same document set. When the auditor arrives, this is what you hand over.