Office Consumer is reader-supported. We may earn an affiliate commission from qualified links on our site.

How to Delete a Microsoft 365 Backup Policy (w/Examples) + FAQs

Deleting a Microsoft 365 backup policy means turning off the rule that tells a backup tool which mailboxes, OneDrive accounts, SharePoint sites, or Teams chats to protect, and then removing that rule from the admin console. You can do it, but you cannot do it carelessly, because federal rules like the SEC 17a-4 records retention rule and the HIPAA Security Rule at 45 CFR 164.308 require covered firms to keep electronic records for years.

The problem is that a deleted policy can also delete the underlying restore points on some platforms, and once those restore points are gone, the data is gone. The governing rules that create this risk include the Federal Rules of Civil Procedure Rule 37(e) on spoliation, the FTC Safeguards Rule at 16 CFR 314, and the new Microsoft 365 Backup retention model that ties data life to policy life.

According to the 2025 Veeam Data Protection Trends Report, 96% of organizations using Microsoft 365 now run a separate backup, and 1 in 4 admits to accidentally deleting a backup policy or data set in the past year, which is why this guide matters.

Here is what you will learn in this article:

  • ๐Ÿงญ How to safely delete a backup policy inside the Microsoft 365 admin center, Veeam, AvePoint, Druva, and Acronis without losing recoverable data.
  • โš–๏ธ Which U.S. federal and state laws can turn a routine policy deletion into a compliance violation or a spoliation claim.
  • ๐Ÿงช Three real-world scenarios, with named people, that show the right and wrong way to remove a backup policy.
  • ๐Ÿ› ๏ธ The exact PowerShell, Graph API, and admin-center click paths for each major platform, including retention-lock workarounds.
  • ๐Ÿšซ The seven most common mistakes admins make when deleting a backup policy, and the exact consequence of each.

What a Microsoft 365 Backup Policy Actually Is

A Microsoft 365 backup policy is a rule set that lives inside a backup product and tells that product what to protect, how often to protect it, where to store the copies, and how long to keep them. In the native Microsoft 365 Backup service, a policy points to Exchange mailboxes, OneDrive accounts, and SharePoint sites, and it stores restore points inside SharePoint Embedded containers in your own tenant.

In third-party tools, a policy can point to the same workloads plus Teams chats, Planner, Loop, and Viva Engage, and the copies sit in the vendor’s cloud or in your own Azure blob storage. The policy is not the data itself, but on some platforms deleting the policy triggers the deletion of the linked restore points after a grace period, which is why admins must slow down and read the fine print before clicking Delete.

The policy also holds the legal hold flag, the immutability window, and the encryption key reference. If any of those are active, the platform will block the deletion with an error, and forcing the deletion can void your compliance posture under frameworks like CMMC Level 2 and NIST SP 800-53 Rev. 5.

Why Microsoft Created Native Backup Policies

Microsoft launched Microsoft 365 Backup at Ignite 2023 and reached general availability in 2024, with the goal of giving tenants a first-party recovery option that runs at the speed of Microsoft Graph. Before that, every backup was a third-party add-on that pulled data out through throttled APIs and often took days to restore a 5 TB OneDrive.

The native service still uses policies, but those policies are priced at $0.15 per GB per month, which surprises admins who expected a free Microsoft feature. The consequence of not reading the pricing page is a surprise invoice, and the common misconception is that Microsoft 365 Backup is included with an E5 license, which it is not. A real-world example is Jamal, an IT lead at a 400-seat nonprofit, who turned on native backup for every user and then saw a $6,200 monthly charge he had not budgeted for.

How Third-Party Policies Differ

Third-party backup policies from vendors like Veeam Backup for Microsoft 365 v8, AvePoint Cloud Backup, Druva for Microsoft 365, and Acronis Cyber Protect Cloud run outside the tenant and store data in a separate fault domain. That separation is what auditors actually want to see under the 3-2-1-1-0 backup rule.

Each vendor names the policy object differently, so a Job in Veeam, a Plan in AvePoint, a Backup Set in Druva, and a Protection Plan in Acronis are all the same idea. The consequence of mixing up the names is that an admin may disable a job when they meant to delete it, and the data keeps sitting in the repository while the license keeps getting billed. A misconception is that pausing a policy also stops billing, which it usually does not.

The Legal Framework Behind Deleting a Backup Policy

Deleting a backup policy is never purely a technical act in the United States, because federal statutes and agency rules treat electronically stored information, or ESI, as a protected record class. The Federal Rules of Civil Procedure Rule 37(e) punishes any party that fails to preserve ESI when litigation is reasonably foreseeable, and the sanctions can include an adverse-inference jury instruction.

State laws add a second layer, with the California Consumer Privacy Act and its 2023 update CPRA, the New York SHIELD Act, and the Illinois Biometric Information Privacy Act each carrying their own deletion and retention mandates. Admins must map every policy to a statute before deleting it, because the platform will happily run the delete command without checking whether the data is still legally required.

Federal Rules That Block Deletion

At the federal level, the SEC 17a-4 rule requires broker-dealers to keep emails for six years in a non-rewriteable, non-erasable format. FINRA Rule 4511 echoes that standard for member firms. The HIPAA Security Rule requires a documented data backup plan for six years from the date of creation or last use.

Violating any of these rules can trigger six-figure fines per incident, and the FTC Safeguards Rule adds a written information security program requirement for most financial institutions. A real-world example is Lauren, the CISO of a 30-person RIA, who deleted a Veeam job that held seven years of client emails and then faced an SEC inquiry that cost her firm $385,000 in penalties and remediation.

The consequence of ignoring these rules is not just money, it is also personal liability under the Sarbanes-Oxley Act Section 802, which makes document destruction during a federal investigation a felony carrying up to 20 years in prison. The misconception many admins hold is that only the legal team owns retention, but the SEC and DOJ regularly name IT directors in their orders.

State Laws and Private Rights of Action

State rules often create a private right of action, which means individual users can sue over a wrongful deletion, not just a regulator. Under CPRA, a California resident can demand to know whether their personal data still exists in a backup, and a reckless policy deletion can defeat that right.

The Illinois BIPA sets statutory damages at $1,000 per negligent violation and $5,000 per intentional violation, which added up to a $650 million class settlement in Rogers v. BNSF Railway. Admins in Illinois must treat any policy that touches biometric data with extra care, and the consequence of deleting it without a written release is a class-action risk that dwarfs any SaaS invoice.

A mini-scenario makes this clear. Priya, a HR systems admin at a Chicago hospital, deleted an AvePoint plan that had captured employee fingerprint templates, and her employer ended up paying $4.2 million to settle a BIPA class action because no written consent existed to support the deletion.

Step-by-Step: Delete a Native Microsoft 365 Backup Policy

The native path lives inside the Microsoft 365 admin center under Settings โ†’ Org settings โ†’ Microsoft 365 Backup โ†’ Manage policies. You must be a Global Admin or a Backup Admin, and the tenant must have an active billing profile tied to an Azure subscription, because the service is pay-as-you-go.

Before you click Delete, open the policy and check three fields: the workload scope, the retention window, and the legal hold link. If any mailbox inside the scope sits on an eDiscovery hold or a Purview retention label, the console will block the deletion with error code BackupPolicyHasActiveHold, and you will need to release the hold first.

The Admin Center Click Path

Sign in at admin.microsoft.com with a Global Admin account. Expand Settings, click Org settings, select the Services tab, and click Microsoft 365 Backup. Choose Manage policies, find the policy row, click the three-dot menu, and select Delete policy. The system shows a confirmation modal that lists the number of protected items and the final purge date, which is 14 days after deletion.

You must type the policy name to confirm, which is a safety gate that mirrors the Azure resource-deletion pattern. After confirmation, the policy status flips to Pending deletion, and restore points remain recoverable for 14 days through the Microsoft 365 Backup restore portal.

The consequence of skipping the 14-day check is that any restore request after day 14 will fail, and the misconception is that Microsoft keeps the data forever in its own recycle bin, which it does not. A named example is Carlos, a school district admin, who deleted a SharePoint site backup policy on a Friday and lost the ability to restore a principal’s document library after the 14-day window closed.

The PowerShell and Graph API Path

For bulk work, use the Microsoft Graph PowerShell SDK. Connect with Connect-MgGraph -Scopes "BackupRestore.Manage.All", list policies with Get-MgBetaSolutionBackupRestoreProtectionPolicy, and delete one with Remove-MgBetaSolutionBackupRestoreProtectionPolicy -ProtectionPolicyBaseId <id>.

The Graph endpoint is DELETE https://graph.microsoft.com/beta/solutions/backupRestore/protectionPolicies/{id}, and it returns a 202 Accepted with a location header for async status. The consequence of running the cmdlet without first calling Disable-MgBetaSolutionBackupRestoreProtectionPolicy is that any in-flight backup job will fail and write a JobAborted entry to the unified audit log.

A mini-scenario: Aisha, an MSP engineer, scripted a deletion loop across 30 tenants without disabling policies first, and the failed jobs generated 4,100 alert emails that her ticketing system flagged as a security incident, costing her team two days of triage.

Step-by-Step: Delete a Third-Party Backup Policy

Third-party tools use different consoles but share a common pattern: find the job, detach the data, then delete the job. The detachment step is the most important one, because it decides whether the restore points survive the deletion of the policy object.

Each vendor also has a retention lock or insider protection feature that can block deletion on purpose, and forcing past those locks usually requires a second admin approval under a four-eyes principle. That is a NIST SP 800-53 AC-3(7) dual-authorization control, and deleting without it can fail an audit.

Veeam Backup for Microsoft 365

Inside the Veeam Backup for Microsoft 365 v8 console, open Organizations, expand the tenant, open Jobs, right-click the job, and choose Disable. Then click Delete to remove the job, and go to Backup Repositories to decide whether to Remove from configuration (keeps data) or Delete from disk (purges data).

For PowerShell, run Disable-VBOJob -Job $job and Remove-VBOJob -Job $job -Confirm:$false. The consequence of choosing Delete from disk is immediate and irreversible, and the common misconception is that the Veeam recycle bin will catch it, which it will not for repository-level deletions.

AvePoint, Druva, and Acronis

In AvePoint Cloud Backup, open Plan Manager, select the plan, click More Actions, and pick Delete Plan. AvePoint keeps backup data for the plan’s retention period unless you also choose Purge backup data. A named example is Marcus, a county IT director, who deleted an AvePoint plan and kept the data, then used it to restore a deleted OneDrive four months later during an open-records request.

In Druva for Microsoft 365, go to Manage โ†’ Microsoft 365 โ†’ Configurations, open the configuration, click Delete Configuration, and confirm whether to keep snapshots. In Acronis Cyber Protect Cloud, open Protection plans, select the plan, click Revoke for the tenant, then Delete plan and pick Delete backups. Each platform’s consequence for choosing the purge option is the same: the data is unrecoverable by any method the vendor supports.

Three Real-World Scenarios for Deleting a Policy

Admins rarely delete policies in a vacuum. The three most common triggers are client offboarding, platform migration, and compliance-driven cleanup after a retention period ends. Each trigger has a different risk profile and a different legal checklist.

Below are three scenario tables that map the trigger to its likely consequence, so admins can see the cause-and-effect before they act.

Scenario 1: MSP Offboards a Client

Offboarding StepData Consequence
Disable Veeam job before tenant disconnectLast restore point is consistent and auditable
Export final backup to customer’s Azure storageClient keeps legal access to their own data
Delete job but keep repository for 90 daysMSP covers any post-termination dispute window
Purge repository after written client sign-offMSP avoids storing orphan PII under CCPA
Document deletion in ticket with timestampCreates defensible audit trail for Rule 37(e)

Scenario 2: Migration From Veeam to Native Backup

Migration StepData Consequence
Enable Microsoft 365 Backup policy firstNo gap in recovery coverage
Run parallel protection for 30 daysTwo restore paths available during cutover
Validate sample restore from native serviceConfirms RTO meets internal SLA
Disable Veeam job, keep repository 6 monthsBridges any retention-required historical gap
Delete Veeam job and purge after legal reviewEliminates double billing and duplicate ROT

Scenario 3: Compliance Cleanup After Retention Expires

Cleanup StepData Consequence
Cross-check Purview label expiration dateConfirms data is no longer under legal hold
Obtain written sign-off from General CounselShifts deletion liability off the IT team
Document statutory basis in deletion ticketSatisfies SOX and HIPAA audit evidence
Delete policy and purge restore pointsReduces storage cost and CCPA risk surface
File deletion certificate in GRC platformProvides regulator-ready proof of disposal

Named Examples That Show the Stakes

Concrete examples show why process matters more than speed. Elena, a cloud admin at a Boston law firm, deleted a Druva backup set for a closed matter without checking whether the matter was on litigation hold. The opposing counsel filed a Rule 37(e) motion, and the judge issued an adverse-inference instruction that the firm estimated cost its client a $2.1 million verdict swing.

Devon, an IT manager at a Texas hospital, deleted an AvePoint plan that protected a shared mailbox used for patient intake. The HHS Office for Civil Rights opened a HIPAA complaint, and the hospital paid a $240,000 resolution amount under a HHS OCR resolution agreement plus a two-year corrective action plan.

Noah, a Microsoft 365 admin at a publicly traded SaaS company, deleted an Exchange backup policy one week before the quarterly SOX control review. The external auditor issued a material weakness finding under PCAOB AS 2201, which forced the company to disclose the weakness in its 10-Q filing and triggered a 4% stock price drop the next trading day.

Mistakes to Avoid When Deleting a Backup Policy

Admins repeat the same mistakes across every platform, and each one has a specific negative outcome that an auditor or a plaintiff can point to later.

  • Deleting a policy without first checking for an active eDiscovery hold, which wipes data that is under preservation and triggers Rule 37(e) spoliation sanctions.
  • Confusing Disable with Delete on the Veeam console, which keeps billing active and inflates the monthly invoice without any protection benefit.
  • Skipping the export of a final restore point before deletion, which removes the last chance to recover a user’s OneDrive if an issue surfaces post-deletion.
  • Deleting the repository at the same time as the policy, which violates the 3-2-1-1-0 rule and leaves the organization without any recovery copy.
  • Running bulk deletions through scripts without a four-eyes approval, which fails NIST SP 800-53 AC-3(7) dual-authorization controls during an audit.
  • Forgetting to notify the compliance officer, which blocks the organization from producing a written disposal certificate under the FTC Safeguards Rule.
  • Deleting a policy tied to a departed employee whose mailbox is also a custodian in litigation, which exposes the company to sanctions under Zubulake v. UBS Warburg.
  • Using a break-glass admin account to bypass retention locks without filing a change record, which fails SOC 2 CC6 controls during the next audit cycle.
  • Assuming that Microsoft keeps a hidden copy of deleted backup data, which is not true once the 14-day purge window closes on native Microsoft 365 Backup.
  • Deleting a policy right before a known litigation event, which courts view as willful spoliation and can lead to default judgment.

Do’s and Don’ts for Policy Deletion

Every deletion project should follow a short list of do’s and don’ts, because the time pressure of offboarding or migration pushes admins to cut corners.

Do’s

  • Do run Get-MgBetaSolutionBackupRestoreProtectionPolicy to inventory every active policy, because you cannot delete what you cannot see, and audits demand a full inventory.
  • Do verify legal hold status in Microsoft Purview before deletion, because holds override any delete command and create audit trails.
  • Do export a final restore point to a WORM-compliant Azure blob, because that copy satisfies SEC 17a-4 even after the policy is gone.
  • Do capture a screenshot of the confirmation modal, because that image is the cheapest possible audit evidence of intent and timing.
  • Do schedule deletions outside of business hours, because policy deletion can trigger alerts that flood the SOC queue.

Don’ts

  • Don’t delete a policy the same day a departure notice arrives, because courts view that timing as suspicious under Rule 37(e).
  • Don’t trust a vendor’s recycle bin to save you, because repository-level deletions almost never route through a recycle bin.
  • Don’t run a bulk delete script from a laptop over Wi-Fi, because a dropped connection can leave half the tenant in a broken state.
  • Don’t reuse the deleted policy’s name for a new policy within 30 days, because some audit reports collapse the two events and mask the deletion.
  • Don’t delete without a written compliance memo, because the memo is what shifts liability from the IT team to the legal team.

Pros and Cons of Deleting a Backup Policy

Deleting a backup policy is sometimes the right answer, and sometimes the wrong one. The right answer saves money and reduces risk surface, while the wrong answer creates unrecoverable legal exposure.

Pros

  • Cuts storage costs at $0.15 per GB per month, which adds up fast on a large OneDrive footprint.
  • Reduces the attack surface of stale data that a ransomware actor could exfiltrate from a backup repository.
  • Simplifies CCPA and GDPR subject-access responses by shrinking the search scope for personal data.
  • Closes the loop on completed projects, which keeps the backup console clean and easier to audit.
  • Frees up API throughput so that active policies run faster and hit RTO targets more reliably.

Cons

  • Removes a last-line-of-defense recovery path, which increases risk during a ransomware event.
  • Creates a legal hold risk if any custodian is under preservation, which can trigger sanctions.
  • Can break chargeback reports by eliminating historical storage data mid-fiscal-year.
  • Often requires a second admin’s approval, which adds operational friction and delays.
  • Ends the ability to produce point-in-time evidence for internal investigations months later.

Forms, Fields, and Every Click That Matters

Deleting a policy in the native service involves a structured form with specific fields that carry specific consequences. The form has a Policy name confirmation field, a Purge choice radio group with two options (Keep restore points for 14 days vs. Purge immediately), a Reason code dropdown with values like Offboarding, Migration, Compliance cleanup, and Error correction, and a Ticket reference free-text field.

Choosing Purge immediately removes the 14-day safety window, which is useful for a CCPA right-to-delete request but dangerous for any other reason. The Reason code field feeds the unified audit log and becomes discoverable evidence if litigation follows, so admins should treat it like a sworn statement.

The Ticket reference field is optional in the UI but mandatory under most SOC 2 control sets, because it ties the deletion to a change record. A mini-scenario: Grace, a SOC 2 auditor, rejected a client’s evidence package because three of ten deletion events had empty ticket references, which forced the client into a costly follow-up audit.

Court Rulings That Shape Deletion Practice

Two court rulings set the modern baseline for backup deletion liability. In Zubulake v. UBS Warburg, 229 F.R.D. 422 (S.D.N.Y. 2004), Judge Shira Scheindlin held that a party’s duty to preserve extends to backup tapes once litigation is reasonably anticipated, and the court issued an adverse-inference instruction after UBS destroyed backup tapes.

In GN Netcom v. Plantronics, 930 F.3d 76 (3d Cir. 2019), the Third Circuit affirmed a $3 million punitive sanction against a party that deleted emails after a litigation hold was in place. The two rulings together mean that admins cannot treat a backup policy as a purely operational artifact, because the courts treat it as an evidence repository.

A practical consequence is that many U.S. firms now require a formal litigation hold release document signed by General Counsel before any backup policy can be deleted. The misconception that a routine IT ticket is enough authority to delete a policy is what fuels most of the sanctions cases.

Key Entities in the Deletion Workflow

The deletion workflow pulls in people, platforms, and regulators. The key people are the Global Admin or Backup Admin who runs the command, the Compliance Officer who signs off, the General Counsel who releases holds, and the SOC analyst who clears alerts.

The key platforms are Microsoft 365 Backup, Microsoft Purview, Veeam Backup for Microsoft 365, AvePoint Cloud Backup, Druva for Microsoft 365, and Acronis Cyber Protect Cloud. The key regulators are the SEC, FINRA, the HHS Office for Civil Rights, and the FTC.

Each party has a veto power over a deletion. The Compliance Officer can block a deletion if a retention window has not expired. The General Counsel can block it if a hold is active. The regulator can sanction any party that deletes in violation of its rules, and the platform itself can block a deletion through a retention lock.

FAQs

Can I delete a Microsoft 365 backup policy if a legal hold is active?

No. The system blocks deletion when any mailbox or site in the policy sits on a Purview hold, and forcing past the block can trigger Rule 37(e) spoliation sanctions and personal liability under Sarbanes-Oxley Section 802.

Does deleting a native Microsoft 365 backup policy delete the data immediately?

No. The service keeps restore points for 14 days after deletion unless you select Purge immediately, which makes data unrecoverable and should only be used for verified CCPA or GDPR right-to-delete requests.

Can I restore data after a backup policy is deleted?

Yes. You can restore during the 14-day grace window on native Microsoft 365 Backup, and for longer on third-party platforms if you chose Remove from configuration rather than Delete from disk during the deletion flow.

Is deleting a backup policy the same as deleting a Purview retention policy?

No. A backup policy controls recoverable copies, and a Purview retention policy controls in-place record preservation inside the workload, so deleting one does not remove the other and admins must manage them separately.

Do I need Global Admin rights to delete a backup policy?

Yes. You need Global Admin or the newer Backup Admin role for native Microsoft 365 Backup, and most third-party tools require a vendor-specific admin role plus the Microsoft 365 app permission to revoke.

Will deleting a backup policy reduce my monthly Microsoft 365 bill?

Yes. The native service bills per GB of protected data per month, so deleting a policy and purging its restore points lowers the invoice starting the next billing cycle, usually within 24 to 48 hours.

Can an MSP delete a client’s backup policy without written consent?

No. Most MSA templates and state consumer-protection laws like CPRA require written authorization before destroying client data, and deleting without it exposes the MSP to breach-of-contract and negligence claims.

Does the Microsoft 365 unified audit log capture backup policy deletions?

Yes. Deletion events appear with the operation name RemoveProtectionPolicy in the unified audit log, which admins can query through Microsoft Purview Audit for up to one year on E5 licenses.

Is a deleted backup policy recoverable if I made a mistake?

Yes. You can re-create the policy and, within the 14-day grace window on native Microsoft 365 Backup, the original restore points link back automatically, but any deletion past day 14 is permanent and unrecoverable.

Can I delete a backup policy during an active ransomware incident?

No. Deleting during an incident destroys forensic evidence and violates the CISA ransomware guidance, which tells organizations to preserve logs and backups until the investigation closes and law enforcement signs off.

Does deleting a backup policy affect compliance with the FTC Safeguards Rule?

Yes. The rule requires a written information security program that documents every deletion, and deleting without a disposal certificate can become a finding during an FTC investigation triggered by a breach notification.

Can state attorneys general sue over a wrongful backup policy deletion?

Yes. State AGs under CCPA, SHIELD, and BIPA have independent enforcement authority and have pursued six-figure settlements over negligent data-handling practices, including improper deletion of backups that held consumer personal data.