What is a retention policy?¶

A retention policy is a configured rule that decides how long defined cloud data is kept and what happens at the end of that period. It may preserve, archive, review or delete data automatically.

A policy needs scope, clock and action¶

Identify the data types, accounts, folders or users covered; the event that starts the retention clock; the duration; and the end action. Active, deleted and archived data may be treated differently.

Policies may be set by the provider, customer administrator or a separate compliance system. The policy owner, approver and technical operator may be different people.

Rules can overlap¶

One rule may remove the live object while another retains a compliance copy. Legal holds, backups and exceptions can override or supplement ordinary retention. Priority and effective dates therefore matter.

Historical configuration is essential. The current policy may have changed since the event, and documentation alone does not prove the system executed successfully. Audit and policy-run records can show application, error or override.

Policy explains system behaviour¶

Where data disappeared automatically, the relevant rule may account for absence without a manual user deletion. Preserve its configuration, change history and execution event before attributing conduct.

Purview policy RET-17 applies to SharePoint site SITE-21, starts its clock from item creation, retains content for the configured period and then deletes it automatically. Object OBJ-4407 reaches that end condition, and execution event PEX-204 records policy RET-17, target OBJ-4407, action delete and outcome success. Those records can establish the system rule and execution that removed the item; they do not by themselves prove why the policy was originally chosen or whether another hold preserved a copy.

The next useful comparison is PEX-204 against the exported RET-17 version, policy change and approval history, item creation time, applicable holds and the resulting retained or deleted state.