Small-business recovery plan · September 5, 2026
Your Microsoft 365 data can be highly available and still be recoverable for less time than your business assumes. Deleted mail, emptied recycle bins, a departing employee, ransomware, and a bad bulk change follow different recovery paths. The expensive surprise is discovering the difference after the built-in clock has run out.
Guidance checked September 5, 2026, at 1:16 p.m. Eastern / 17:16 UTC. Microsoft changes cloud features and licensing; confirm the live settings and entitlements in your tenant before relying on a recovery window.
Fast answer: Treat Microsoft 365 retention, recycle bins, version history, service resiliency, and backup as different controls. Exchange Online keeps permanently deleted items for 14 days by default and allows an administrator to raise that setting to 30 days, while SharePoint’s standard recycle-bin path runs for 93 days from the original deletion.[1][2] Build a written recovery target, protect the workloads that matter, and prove the plan with a real restore.
The problem: “It is in Microsoft 365” is not a recovery plan
Microsoft’s cloud infrastructure is designed for service resiliency, but service uptime does not answer your business question: Can we restore this exact mailbox item, folder, site, or account to the needed point in time after a user, attacker, application, or administrator changes it? Microsoft positions Microsoft 365 Backup for ransomware, accidental deletion, malicious deletion, and overwrite recovery—separate scenarios from ordinary service failover.[4]
That distinction matters to a law office searching for an old client attachment, a contractor whose estimator overwrote a shared workbook, a medical office that removed a former employee too quickly, or a retailer whose synchronized SharePoint files were encrypted. NIST says data-loss incidents can have catastrophic effects and recommends that backup files be conducted, maintained, and tested—not merely configured once.[5]
Know the recovery clocks before you need them
Phone readers: swipe the table left to see every recovery-path column.
| Scenario | Built-in path | Important limit | What to verify now |
|---|---|---|---|
| Permanently deleted Exchange item | Recoverable Items | 14 days by default; administrator-configurable up to 30 days.[1] | Actual RetainDeletedItemsFor value and any separate retention/hold policy. |
| Deleted SharePoint or OneDrive file | First- and second-stage recycle bins | 93 days total from the original deletion in the standard SharePoint path; moving between stages does not create a fresh 93-day window.[2] | Who can reach the second-stage bin and how quickly a deletion alert reaches them. |
| Deleted employee’s OneDrive | Delegated access, deletion process, then site collection recycle bin | A delegate has 30 days by default to access and download files; Microsoft notes retention policies and holds can change the standard path.[3] | Manager/secondary-owner assignment, tenant retention value, licensing state, and offboarding checklist. |
| Bulk overwrite, ransomware, or deletion beyond native windows | Purpose-built Microsoft 365 backup or another independently managed backup service | Only protected workloads and restore points that exist under an active policy are available. Microsoft’s own backup offering supports configurable 3-month, 6-month, 1-year, or 2-year recovery windows.[4] | Covered users/sites, first successful restore point, administrator separation, alerts, retention, and restore test. |
Do not use those numbers as a promise for your tenant. Retention policies, labels, legal holds, licensing changes, hard deletion, APIs, and administrator actions can alter the path. Microsoft says a SharePoint API can delete rather than recycle an item, immediately bypassing both recycle bins.[2] Record your observed settings and test the exact recovery scenario that matters.
A practical six-step fix
Inventory what would stop the business
List the Exchange mailboxes, shared mailboxes, OneDrive accounts, SharePoint sites, Teams-connected files, and business records needed for payroll, billing, scheduling, customer service, legal obligations, and daily operations. Name a business owner for each. NIST recommends planning backups around business value, operational needs, restoration time, and the maximum acceptable age of recoverable data.[5]
Write two numbers: RPO and RTO
Your recovery point objective (RPO) is how much recent work the business can afford to lose; your recovery time objective (RTO) is how long it can operate without the data. A dentist might tolerate losing 15 minutes of appointment changes but not a full day; an archived project library may tolerate a longer gap. These are business decisions, not values a backup vendor should invent for you.
Map each native recovery layer
Document Exchange deleted-item retention, SharePoint and OneDrive recycle-bin access, OneDrive deleted-user retention, version history, Purview retention policies or labels, and any legal holds. A compliance hold can preserve evidence, but it is not automatically the simple self-service restore experience staff expect. Microsoft notes that the SharePoint recycle bin is not indexed, so ordinary search and eDiscovery search do not find content there.[3]
Select backup coverage from the recovery targets
Compare Microsoft 365 Backup and qualified third-party options against your written RPO/RTO, workload coverage, restore granularity, administrative roles, retention choices, regional/data-handling needs, export options, alerting, and total cost. Microsoft’s current service protects selected OneDrive accounts, SharePoint sites, and Exchange mailboxes; its documented restore points differ by workload and age.[4] Teams chat and every SaaS integration should not be assumed covered merely because Teams files live in SharePoint.
Separate the keys from the data
Use a dedicated backup-administrator role, multi-factor authentication, least privilege, and alerts for policy changes, failed protection, mass deletion, and restore activity. Where the product supports it, make backup copies resistant to alteration from an ordinary Microsoft 365 administrator account. Microsoft describes its own backup storage as append-only protection against malicious overwrites.[4]
Restore one real item, then document the result
Restore a harmless test email, one file, and—if SharePoint is critical—a small test site or isolated library using the product’s supported method. Record who approved it, the restore point selected, where the recovered data appeared, elapsed time, permission behavior, and whether current work was overwritten. NIST’s guidance emphasizes testing recovery processes and monitoring backups for creation, consistency, usability, and successful recovery.[5]
Good plan versus dangerous assumption
Good
- Critical workloads and owners are written down.
- RPO and RTO are approved by the business.
- Native retention settings and backup policies are recorded separately.
- Backup administration is protected and monitored.
- A restore test proves where recovered data lands.
- Offboarding transfers ownership before account deletion.
Bad
- “Microsoft backs it up” with no product, policy, or restore point named.
- OneDrive sync is treated as an independent backup.
- A recycle bin is expected to preserve deleted files forever.
- A compliance hold is assumed to be a convenient operational restore tool.
- The only backup administrator is the same daily global-admin account.
- The first restore test happens during ransomware or litigation.
Stop before changing retention or deleting accounts when the data may be subject to a legal hold, regulatory requirement, contract, investigation, insurance condition, or documented records schedule. Backup and retention solve different problems. Have the organization’s authorized legal/compliance owner approve those rules; an IT cleanup should not silently become a records-destruction decision.
Affected and not affected
Affected: Microsoft 365 organizations that depend on Exchange Online, OneDrive, or SharePoint for records they could not cheaply recreate—especially businesses with frequent staff turnover, shared files, ransomware exposure, or no tested restore procedure.
Not necessarily affected: a home user with only replaceable files, an organization whose Microsoft 365 data is already covered by a documented and recently tested backup, or a tenant using a verified retention-and-recovery design that meets its actual RPO/RTO. Even then, the plan should be rechecked after licensing, ownership, or policy changes.
Two realistic examples
A recoverable mistake
An employee deletes a SharePoint project folder on Monday. The owner notices on Tuesday, checks the first-stage recycle bin, restores the folder, and verifies permissions and version history. The native recovery path was fast because the deletion was noticed early and the owner knew where to look.
A costly wrong assumption
A former employee’s account is removed, nobody is assigned to preserve the OneDrive, and the missing estimate archive is discovered months later. The team says, “It was in the cloud,” but cannot name a backup policy or valid restore point. Billing history must be rebuilt from email, PDFs, and customer calls—if those copies still exist.
Related guides from The IT Guys
- If someone is leaving, follow our Microsoft 365 and Google Workspace offboarding data-preservation guide before deleting the account.
- If the problem is quota pressure rather than recovery coverage, use our cloud-storage-full cleanup guide.
- Whatever backup product you choose, run the one-file restore test before trusting it.
FAQ
Does Microsoft 365 already have backups?
Microsoft runs resilient cloud services and also sells Microsoft 365 Backup. The useful question is not whether copies exist somewhere in the platform; it is whether your tenant has an active policy covering the needed workload and a supported restore point for the incident you face.[4]
Is OneDrive sync a backup?
Sync is useful for availability and offline work, but a deletion or destructive change can synchronize too. Practical guidance: count a copy as a backup only if it has an independently managed recovery path, retention window, and tested restore that meets your RPO/RTO.
Are SharePoint deleted files always recoverable for 93 days?
No blanket promise is safe. Microsoft documents a 93-day standard recycle-bin path from original deletion, but hard deletion, API behavior, retention policies, holds, and other conditions can change what is recoverable.[2]
Should I simply set every retention period to the maximum?
Not without a records policy. Longer retention can help recovery, but it can also increase storage, discovery, privacy, or contractual obligations. Let business and authorized compliance owners define requirements; configure technology to match them.
How often should we test?
Choose a schedule based on risk and change rate. A practical small-business baseline is a quarterly item-level test and another test after changing the backup product, licensing, protected users/sites, administrator roles, or retention settings. That interval is practical guidance, not a Microsoft or NIST guarantee.
What should a restore report contain?
Include the workload, item, restore point, approver, operator, destination, start/end times, result, permissions observed, gaps, and follow-up owner. Do not place customer content, passwords, recovery codes, or unnecessary personal data in the report.
Your next 20 minutes
- Write down the three Microsoft 365 locations your business cannot operate without.
- Name the owner and current recovery method for each.
- Check the actual Exchange deleted-item, OneDrive deleted-user, and SharePoint recovery settings.
- Identify the last successful backup or native restore point you can see—without changing anything.
- Schedule one harmless test restore and document where the recovered item lands.
Treasure Coast help: The IT Guys helps homes and small businesses in Port Saint Lucie, Jensen Beach, Fort Pierce, and Vero Beach turn “the cloud probably has it” into a written, tested recovery plan. Bring your Microsoft 365 workload list, licensing summary, retention requirements, and the result of your latest restore test—never send passwords or recovery codes.
Sources
- Microsoft Learn — Change how long permanently deleted Exchange Online items are kept.
- Microsoft Learn — Microsoft 365 SharePoint data deletion.
- Microsoft Learn — OneDrive retention and deletion.
- Microsoft Learn — Overview of Microsoft 365 Backup.
- NIST NCCoE — Protecting Data from Ransomware and Other Data Loss Events.
Evidence boundary: These sources document Microsoft recovery behavior and backup-planning principles. They do not reveal this site’s tenant settings, guarantee recovery of a particular item, replace legal advice, or endorse a specific backup vendor.