Microsoft 365 / When to use retention policies and data loss prevention (DLP)

Microsoft 365 retention policies govern how long content is kept and when it is deleted, while data loss prevention (DLP) policies detect and restrict inappropriate sharing or transmission of sensitive information. Both protect data, but address different questions. Decide separately how long content should be kept and where it may be shared or sent.

Differences between retention and DLP

Use Microsoft’s retention policy and label guidance for content lifecycle requirements and the DLP overview for sensitive-information controls. Supported locations and conditions depend on the license and policy type.

For example, if you want to retain contract materials for a period defined by your organization while preventing them from being shared externally, both retention and DLP may be needed. Applying retention alone does not prevent external transmission, and applying DLP alone does not guarantee that documents deleted by users will be preserved for the required period.

When is a retention policy necessary?

It is considered when contract documents or work records must be maintained for a specified period, or when unnecessary data must be deleted after a certain time. First, determine the purpose of retention, where it will be applied (Exchange, SharePoint, OneDrive, etc.), the start time, exceptions, and legal retention requirements. When a retention policy is enabled, the way internal retention copies are handled may differ even if users delete files from their view. It should not be understood simply as a “function of using the recycle bin longer.”

To apply a common period across an entire site, use a retention policy; if the period or classification differs for each document, review item-level retention labels. Labels are not just simple display names but settings that link to retention actions. Just having a sensitivity label on a document does not mean that a retention label is also applied.

Retention is different from an operational backup. A retained copy does not provide an immediate point-in-time restoration of a user’s folder structure. Review how retention works in SharePoint and OneDrive. Their Preservation Hold library is a hidden system location for retained content, not an ordinary folder to edit or clean up manually. It counts toward the site’s storage quota, so plan both retention duration and storage capacity.

When is DLP needed?

It is considered when you want to reduce the risk of sensitive information such as national identification numbers, payment information, and internal confidential data leaving the organization through email or file sharing. You should test whether the detection conditions accurately distinguish actual data. Conditions that are too broad can block normal business, while conditions that are too narrow can miss important leaks. You need to design policy tips, alerts, and exception approval procedures for operation.

Decide what you need before deployment

1. Check the data to be protected and the applicable laws and contracts. Legal retention periods are not arbitrarily defined in this document.
2. Distinguish whether the question to be solved is related to retention or DLP. If both are required, review their interactions.
3. Check the available licenses and the currently supported locations of Microsoft Purview.
4. Check the policy results and false positives on a small number of users or in a test scope, and get feedback from business, security, and legal personnel.
5. Prepare change logs, notifications, exceptions, and rollback procedures before full deployment.

Configure a retention pilot

In Microsoft Purview, open Solutions → Data Lifecycle Management → Policies → Retention policies and select New retention policy. Confirm that the affected users have the required licenses and that the administrator has suitable permissions, such as the Retention Management role described in Microsoft’s data lifecycle management setup guide. Check administrative scope for the chosen locations. Use a dedicated test location containing no important production data; do not test deletion against live business records.

1. Document the purpose of retention, type of data, retention period, the rationale, and responsible persons. The period should use the organizational standards confirmed by business and legal personnel.
2. Choose a Static scope for a fixed list of locations or an Adaptive scope for attribute-based selection. Adaptive scopes must already exist and meet the applicable feature and licensing requirements. Choose based on your prepared scope and pilot needs; do not select Adaptive automatically simply because it is available.
3. Determine the actual storage locations such as Exchange, SharePoint, OneDrive, and Microsoft 365 groups, and include only the necessary test targets. Always check whether the default is set to all targets.
4. Choose retain-only, delete-only or retain-then-delete behavior and the applicable period-start rule. For SharePoint and OneDrive files, check whether age is measured from creation or last modification; it is not necessarily measured from the day you create the policy. Existing files may already be older than the configured period. Confirm the end action carefully if your purpose is continued preservation rather than permanent deletion.
5. Review the locations, included recipients or sites, duration, start rule and end action, then confirm only the approved settings. Check the saved configuration and deployment status before evaluating the test data. Record the expected result and the actual deployment and observation times.

Teams messages and channel files are stored in different locations. A message-retention policy does not automatically preserve every connected SharePoint or OneDrive file. When several policies or labels apply, do not assume the newest policy alone determines the result. Review the location requirements and retention principles linked in Microsoft’s retention policy creation guide. DLP simulation is not a simulation of retention or deletion: test retention separately with isolated content and the relevant deployment conditions.

How to test DLP on a small scale

Consider this hypothetical requirement: detect external sharing of sensitive test documents, then block external access after validation. Use approved synthetic data rather than real personal information. Confirm the required DLP-administration permissions using Microsoft’s DLP policy reference; retention-management permissions alone do not establish DLP access. If you use a sensitivity label as a condition, it must already be created, published and applied to the test file.

1. Open Data loss prevention → Policies → Create policy → Enterprise applications & devices. For this custom SharePoint and OneDrive scenario, choose Custom in the template categories and regulations, then name and describe the policy. Keep enforcement off while configuring the pilot.
2. Include only the pilot SharePoint sites and OneDrive accounts and exclude unrelated locations and recipients. On Define policy settings, choose Create or customize advanced DLP rules, then select Create rule. Set the intended sensitive information type or prepared sensitivity label and require external sharing as well. In the label-based example, combine Content contains the selected label with Content is shared from Microsoft 365 → with people outside my organization; verify that both conditions must be satisfied.
3. For this example, configure Restrict access or encrypt the content in Microsoft 365 locations → Block only people outside your organization. Decide policy tips and administrator alerts separately. Leave User overrides disabled so users cannot bypass this pilot’s external-access block. A notification alone is not a block.
4. On Policy mode, select Run the policy in simulation mode. Choose whether to enable Show policy tips while in simulation mode, then select Next → Submit. Simulation does not enforce the configured blocks.
5. Check test files that match the conditions and files that do not, dividing them into internal and external sharing cases. After reviewing matches, notifications, false positives, and actual business impacts, switch to enforcement mode within the approved scope.

The expected result is that external sharing of the sensitive test document is detected, while a non-matching document is not needlessly restricted. Simulation does not prove that access is blocked. After switching the approved pilot to enforcement, check the external test account’s denied access and the internal test account’s expected access. The external account must otherwise have a valid sharing permission so the test distinguishes a DLP block from a missing permission. Verify results using Microsoft’s SharePoint and OneDrive DLP configuration example; alert counts alone do not demonstrate success.

Change or roll back settings carefully

If DLP test results differ, start by checking the target, actual classification of the file, conditions, and mode. If retention differs from expectations, investigate other retention policies, labels, eDiscovery or legal hold requirements, and deployment status. Instead of simply removing the policy to hide the issue, record the settings that caused it and modify them within the necessary scope.

Removing a policy does not restore content that was already permanently deleted or guarantee immediate recovery of blocked access. Other policies, holds, sharing permissions and deployment changes may still matter. Preserve the previous configuration, pilot scope and observations before changing anything. Do not shorten required retention or release holds without the organization’s approved retention decision and recovery plan.