10.5 Retention, Records Management, and Label Policies

Retain, Delete, and the Two Mechanisms

Retention in Microsoft Purview (the Data Lifecycle Management and Records Management solutions) governs how long information is kept and what happens when that period ends. Every retention configuration does one or both of two things:

• Retain — keep content for a defined period so it cannot be permanently deleted during that time, even if a user tries to delete it (a hidden preservation copy is held to satisfy compliance and legal needs).
• Delete — permanently remove content when the retention period expires (for example, delete emails 7 years after creation to avoid keeping data longer than necessary).

A single rule can do both: "retain for 7 years, then delete." Retention is measured from a trigger such as the item's creation date, last-modified date, or labeling date, and for some content from an event (event-based retention, e.g., employee departure).

There are two mechanisms, and distinguishing them is a core SC-900 point:

Use a retention policy for a blanket baseline across a workload, and a retention label when specific items need their own rule or need to be declared records. Retention labels can be applied manually by users, set as a default in a library, or auto-applied when a SIT or trainable classifier matches — reusing classification just like labels and DLP do.

Records Management and Principles of Retention

Records management is the higher-assurance side of retention. A retention label can be configured to declare an item a record or a regulatory record, which adds stronger controls than ordinary retention:

• Record — restricts what users can do: the item generally cannot be deleted, and changes are versioned/audited. You can unlock it later if needed.
• Regulatory record — the strictest setting: the label cannot be removed or changed, the retention period cannot be shortened, and the item cannot be deleted before the period ends — used where regulators require true immutability.
• Disposition review — at end of retention, designated reviewers must approve deletion rather than letting it happen automatically, providing a documented decision point.
• A file plan — a central catalog of all retention labels with metadata (regulatory citations, departments) for managing records at scale.

Because many policies and labels can target the same content, Purview uses the principles of retention to resolve conflicts. Memorize the order:

1. Retention wins over deletion — if one rule says retain and another says delete, the content is retained (it is kept until the longest retention is satisfied).
2. Longest retention period wins — the content is kept for the longest applicable period.
3. Explicit label wins over a policy — an explicitly applied retention label takes precedence over a broad retention policy.
4. Shortest deletion period wins — once retention is satisfied, the content is deleted at the shortest configured deletion period.

The net effect: the rules combine to be maximally protective — content is never deleted while any rule still wants to keep it.

The trap: retention vs sensitivity

This is the most-tested confusion in the whole chapter. Retention labels govern the lifecycle of data (how long to keep, when to delete, whether it is a record). Sensitivity labels protect data (classify, encrypt, mark, restrict access). They are independent — an item can carry one sensitivity label and one retention label at the same time. If the scenario talks about keeping records, deleting after X years, or declaring a record, choose retention. If it talks about confidentiality, encryption, or who may open the file, choose sensitivity.

And note retention is not a legal hold — eDiscovery holds (next section) are case-specific, whereas retention is ongoing organizational governance.

Scope, Triggers, and a Worked Retention Example

When an administrator builds retention, two more choices appear that SC-900 may touch. The first is how locations are chosen:

• Static scope — you pick the specific locations or sites the policy applies to.
• Adaptive scope — the policy targets locations dynamically using attributes (for example, all mailboxes where Department = Legal), so it stays current as people and sites change.

The second is the retention trigger — the clock that starts the period: when the item was created, when it was last modified, when it was labeled, or an event (event-based retention, such as contract expiration or employee departure). Event-based retention is what lets an organization say "keep this employee's records for 10 years after they leave."

A worked example shows the pieces together. A company must keep signed contracts for 10 years after the contract ends, then have a person approve deletion:

1. Create a retention label "Contract – 10yr" configured to retain, then delete, with an event-based trigger tied to the contract-end event.
2. Turn on records management so the label declares the contract a record, blocking edits and deletion during the period.
3. Enable disposition review so a reviewer must approve deletion at the 10-year mark rather than auto-deleting.
4. Auto-apply the label using a trainable classifier that recognizes contracts, so staff need not tag each one.

Contrast this with a blanket retention policy that simply keeps all Teams chat for 3 years — no per-item label, no record declaration, applied to the whole workload. The example illustrates when to reach for a label (targeted, record-grade) versus a policy (broad baseline).

Keep the chapter-wide map straight: sensitivity = protect, DLP = prevent sharing, retention = keep/delete lifecycle, and a legal hold = preserve for a specific case.