Keeping everything forever is not a retention policy. It is an unmanaged liability with a storage bill attached.
Retention policies and retention labels decide what your organisation keeps and what it deletes, across Exchange, SharePoint, OneDrive, Teams, Viva Engage and Copilot. Microsoft makes the security argument directly: deleting content that no longer has business value helps you manage risk and liability, because it reduces your attack surface.
- Retain and deleteBoth halves, or either one alone
- Retention winsAnd the longest period wins
- Adaptive scopesQueries that re-run daily
- Preservation LockNobody can weaken a locked policy
Eight things that determine whether your retention design survives contact with reality.
Retention wins over deletion, and the longest period wins
These two rules resolve almost every conflict. Microsoft states that by default retention always takes precedence over permanent deletion, and the longest retention period wins, unless priority cleanup applies. A third rule breaks the remaining ties: the delete action from a retention label always takes precedence over the delete action from a retention policy. Understanding this is what stops surprise outcomes.
Labels travel with the content, policies do not
Microsoft states that unlike retention policies, retention settings from retention labels travel with the content if it is moved to a different location within your Microsoft 365 tenant. That single difference decides most policy-versus-label questions. A site-level policy stops applying when the document moves. A label goes with it.
Retained copies go somewhere specific, and it costs quota
When a user edits or deletes retained content, the copy goes to the Preservation Hold library in SharePoint and OneDrive, the Recoverable Items folder in Exchange, and for Teams, Viva Engage, Copilot and AI apps a hidden SubstrateHolds folder inside Recoverable Items. Microsoft warns that because the Preservation Hold library counts against the site storage quota, you might need to increase storage.
Adaptive scopes re-run daily, static scopes do not
An adaptive scope uses a query that runs daily against attributes you specify, so a new executive is picked up automatically. A static scope captures membership when the policy is created and needs reconfiguring as people change. Microsoft notes adaptive scopes have no limit on the number of items per policy, and can target inactive mailboxes specifically, which static scopes cannot.
Preservation Lock, which nobody can undo
Microsoft describes Preservation Lock for regulatory rules such as SEC Rule 17a-4, which requires that once a retention policy is turned on it cannot be turned off or made less restrictive. Once locked, no one including an administrator can turn the policy off, delete it, or make it less restrictive. Two caveats: it is applied after creation, and adaptive scopes currently do not support it.
Disposition review, which is the audit-friendly half
Only labels support disposition review, letting a named person review content before permanent deletion, and only labels give proof of disposition for up to seven years when disposition review is used or the item is marked as a record. Policies delete silently. Where an auditor may ask what was destroyed and who authorised it, that is a label conversation rather than a policy one.
Nothing happens immediately, and that is documented
Microsoft says to allow up to seven days for retention settings to be applied to content when you submit policies or auto-apply label policies, and the same for published labels to become visible in apps. It notes this is often quicker, but with many variables it is best to plan for seven days. Test plans that check the next morning conclude, wrongly, that the policy failed.
Archiving, inactive mailboxes and PST import
Beyond retention, mailbox archiving gives users additional storage with auto-expanding archiving for mailboxes needing more than 100 GB, inactive mailboxes retain content after employees leave, and the import service brings PST files in through network upload or drive shipping. In UAE organisations, that third one usually turns up a decade of files sitting on somebody desktop.
A five year retention period can beat a seven year one.
Microsoft states this directly, and it is the single most misunderstood behaviour in the whole solution.
- Quoted: it is possible for a retention period of five years in a retention policy or label to win over a retention period of seven years, because the five year period is configured to start based on when the file is last modified, and the seven year period is configured to start from when the file is created.
- A file created in 2020 and last modified in 2026 has a five-year-from-modified end date of 2031, and a seven-year-from-created end date of 2027. The shorter number produces the longer retention.
- That is not a defect, it is the arithmetic of two different start events. But it means a retention design expressed only in years, without the start condition alongside each one, is not actually specified.
- Every retention period we document carries its start event next to it, and every conflict is worked through against the published principles rather than assumed from the larger number.
Four things that separate a retention design from a set of numbers.
We write every period with its start event attached
Microsoft own documentation shows a five year period beating a seven year one because of different start events. A schedule that says seven years without saying seven years from what is not a specification, it is an intention. Getting this right at the schedule stage prevents every downstream surprise about which policy actually won.
We treat Preservation Lock as irreversible, because it is
Microsoft states that once locked, nobody including an administrator can turn the policy off, delete it, or make it less restrictive. That is exactly what SEC 17a-4 style rules require and exactly what makes it dangerous applied casually. We apply it narrowly, only where a real obligation exists, and only after the outcome has been proven.
We build the retain half first and prove it before deleting
Policy lookup, run against representative users, sites and groups, tells you which policies actually apply, though it needs exact addresses and URLs since wildcards are not supported. Confirming the real outcome against the intended one, then enabling deletion category by category, is slower and considerably safer than the reverse.
We check the storage consequence before it becomes an incident
Microsoft warns that the Preservation Hold library is included in the site storage quota. In an estate where SharePoint is already near its limits, switching on retention across all sites is a capacity event rather than a compliance one. We model it in advance rather than discovering it when uploads start failing.
Four phases, and the deletion half comes last for good reason.
- 01Weeks 1 to 3
The schedule, in business language
What must be kept, for how long, starting from what event, and under whose obligation. This is a legal and business exercise rather than a technical one, and it is where the whole project either becomes coherent or becomes a set of arbitrary numbers. Every period is written with its start event beside it.
- Obligations mapped to content categories, with the source of each
- Retention periods with start events, not bare year counts
- Records management boundary decided, per Microsoft guidance
- Owner named for each category
- 02Weeks 4 to 6
Retain first, delete nothing
Retention policies configured for the workloads that need blanket coverage, and labels published where item-level control, portability or disposition review is required. Scope decisions made deliberately between adaptive and static. Storage impact assessed, because the Preservation Hold library counts against the SharePoint site quota.
- Policies built with retain-only actions initially
- Adaptive scopes where membership changes, static where it does not
- SharePoint and OneDrive quota headroom checked
- Seven day propagation window respected before any verification
- 03Weeks 7 to 10
Prove the outcome before enabling deletion
Policy lookup used to confirm which policies apply to specific users, sites and groups, remembering it needs exact addresses and URLs with no wildcards. Conflicts worked through against the published principles. Only once the actual outcome for representative items matches the intended outcome does anything get a delete action.
- Policy lookup results for representative users, sites and groups
- Conflict outcomes documented against the four principles
- Disposition review configured where sign-off is required
- Delete actions enabled category by category
- 04Ongoing
Lock, audit and maintain
Preservation Lock applied only where a genuine regulatory requirement exists, since nobody including an administrator can undo it, and noting that adaptive scopes currently do not support it. Auditing enabled for configuration and retention actions. Then a review rhythm, because obligations change and a retention schedule nobody revisits becomes wrong quietly.
- Preservation Lock applied deliberately and narrowly
- Auditing enabled for admin configuration and label actions
- Disposition evidence retained where required
- Annual schedule review with a named owner
Six UAE situations where lifecycle management pays for itself.
A regulated firm with an immutability requirement
Microsoft names SEC Rule 17a-4 as the example, requiring that once a retention policy is on it cannot be turned off or made less restrictive, and Preservation Lock exists to satisfy exactly that shape of rule. Where a UAE regulator imposes a comparable requirement, this is the mechanism, and the mapping is worth confirming obligation by obligation.
A group whose SharePoint has grown without limit
Ten years of sites, most of them dormant, none of them ever cleaned up. Retention policies with delete actions, scoped adaptively so new sites are picked up automatically, address the growth. The Preservation Hold quota effect has to be modelled first, because in a full tenant the cure briefly worsens the symptom.
A professional services firm with client-driven retention
Different clients impose different retention terms, and the engagement folder moves between sites over its life. Labels are the answer, because retention settings from labels travel with content moved within the tenant, and because event-based retention can start the clock at engagement close rather than at file creation.
A healthcare organisation with long statutory periods
Clinical records frequently carry retention obligations measured in decades, and the consequence of deleting early is severe. Disposition review, available only with labels, puts a named person between the end of a retention period and permanent deletion, and produces proof of disposition for up to seven years.
An operator sitting on a decade of PST files
Archive mail scattered across desktops and file shares, invisible to every compliance control the organisation has. The import service brings PSTs in by network upload or drive shipping, at which point retention, search and legal hold all apply to content that until then existed outside every policy.
A business reducing what a breach could expose
Microsoft makes the argument explicitly: deleting content that no longer has business value helps manage risk and liability and reduces your attack surface. Data that no longer exists cannot be stolen, cannot be subject to a data subject request, and does not have to be reviewed during an incident.
How UAE organisations handle retention today.
| Feature | Enforced lifecycle | A schedule on paper | Keep everything forever |
|---|---|---|---|
Retention actually enforced | Yes | No | No |
Deletion actually happens | Yes | No | No |
Teams and Copilot covered | Yes | Rarely | No |
Item-level exceptions possible | Yes | Manual | Not applicable |
Retention survives content moving | Yes, with labels | No | Not applicable |
Sign-off before permanent deletion | Yes | No | Not applicable |
Proof of what was destroyed | Yes | No | Not applicable |
Immutable where regulation requires | Yes | No | No |
Storage growth controlled | Yes | No | No |
Data exposed in a breach | Only what is needed | Everything | Everything |
Fourteen capabilities, and which of the two supports each.
| Capability | Retention policy | Retention label | When it decides the design | |
|---|---|---|---|---|
| Retain, delete, or retain then delete | Yes | Yes | Never, both do this | |
| Teams, Viva Engage, Copilot and AI apps | Yes | No | If chat and Copilot are in scope, you need policies | |
| Skype for Business | Yes | No | Relevant only where legacy Skype persists | |
| Exchange public folders | Yes | No | Public folders are a policy-only conversation | |
| Applied based on content conditions | No | Yes | Sensitive info types, KeyQL, trainable classifiers, cloud attachments | |
| Applied manually by users | No | Yes | When the business must decide item by item | |
| End-user interaction | No | Yes | When you want visible classification, not silent retention | |
| Persists if the content is moved | No | Yes, within your tenant | The single biggest reason to choose labels | |
| Declare item as a record | No | Yes | Regulatory record-keeping starts here | |
| Start the period when labeled or on an event | No | Yes | Contract end, employee departure, project close | |
| Different settings at the end of the period | No | Yes | Multi-stage lifecycles need labels | |
| Disposition review | No | Yes | When somebody must sign off before deletion | |
| Proof of disposition for up to seven years | No | Yes, with review or as a record | When an auditor asks what you destroyed | |
| Findable in Content Search and content explorer | No | Yes | When you need to evidence coverage, not just configure it |
Five steps, and the schedule work is the majority of it.
- 1
Build the retention schedule in business language
Content categories, the obligation behind each period, the period itself, and the event the period starts from. Where high-value items are subject to business, legal or regulatory record-keeping requirements, Microsoft directs those to records management rather than data lifecycle management, so that boundary is drawn here.
- 2
Decide policies, labels, or both, and the scope type
Policies for blanket coverage and for the workloads labels do not reach, including Teams, Viva Engage, Copilot and AI apps, Skype for Business and Exchange public folders. Labels where retention must travel with content, start on an event, be applied by conditions, or end in a disposition review. Adaptive scopes where membership changes, static where it genuinely does not.
- 3
Configure retain actions and wait properly
Retain-only first, deletion later. Microsoft says to allow up to seven days for retention settings to apply and for published labels to become visible, so verification is scheduled after that window rather than the following morning. Storage headroom is checked, since the Preservation Hold library counts against the SharePoint site quota.
- 4
Prove the outcome, then enable deletion
Policy lookup against representative users, sites and Microsoft 365 groups, using exact addresses and URLs because wildcards are not supported. Every conflict resolved against the published principles rather than by assumption. Delete actions enabled category by category, with disposition review where sign-off is required.
- 5
Lock where required, audit, and hand over
Preservation Lock applied only where a genuine regulatory obligation exists, narrowly and after the outcome is proven, noting adaptive scopes do not currently support it. Auditing enabled for both configuration and retention actions. Then an annual schedule review with a named owner, because obligations change and nothing tells you when.
What organisations ask about retention and deletion.
Fifteen questions that make a retention schedule defensible.
The obligation
- Which law or contract requires each period?Cite the source, not a convention.
- When does each period start?Created, modified, labeled, or an event.
- Is any of this record-keeping?Then it belongs in records management.
- Is there a regulatory immutability rule?That is the Preservation Lock question.
- Who owns each content category?Someone has to answer questions later.
The design
- Policy, label, or both?Labels travel, policies cover more workloads.
- Adaptive or static scope?Adaptive re-queries daily.
- Are Teams and Copilot in scope?Labels do not cover them, policies do.
- Do you have SharePoint quota headroom?Preservation Hold counts against it.
- Is disposition review needed?Labels only, and it is what auditors want.
Change and release
- What if a period turns out to be wrong?Preservation Lock makes it permanent.
- Do you understand the 30 day grace period?SharePoint and OneDrive on release.
- Are inactive mailboxes handled?Release behaviour differs by scope type.
- Is auditing switched on?Configuration and actions are separate.
- Who reviews the schedule annually?Obligations change.
The pages around this one.
Start with the schedule, not the portal.
Every retention project that goes wrong went wrong at the schedule. Numbers without a source, periods without a start event, and no decision on where records management begins. That work is a few weeks and it determines everything after it.
Related Services
Explore more solutions that work great with this service
Privacy Impact Assessment
DPIA done at design stage, necessity tested properly
Purview eDiscovery
Holds, review sets and the runbook that no longer matches the portal
Purview Audit
How far back you can actually search, decided before the incident
Sensitivity Labels
Classification that travels with the file, and governs what Copilot sees
Microsoft Purview
Data governance and compliance solutions
UAE PDPL Compliance
Federal Decree-Law 45 of 2021 readiness and operations
Endpoint DLP
USB, print, clipboard and browser controls on devices
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own