Direct answer: Microsoft provides SharePoint service resiliency, recycle bins, file version history, document-library Files Restore, Purview retention, and the separately metered Microsoft 365 Backup product. Whether that is enough depends on the object you must recover, the age and scope of the incident, the required destination, and whether you require a copy under a separate administrative boundary.
Do not reduce the decision to "Microsoft backs it up" or "Microsoft does not back it up." Start with a recovery scenario and test the relevant layer. Microsoft's current SharePoint and OneDrive resiliency documentation describes recycle-bin and Files Restore behavior, while the Microsoft 365 Backup overview documents its own protection units, recovery points, retention, and restore model.
SharePoint Recovery and Capture Matrix
| Layer | Best fit | Important boundary | Proof to require |
|---|---|---|---|
| Recycle bins | Recently deleted files, folders, list items, libraries, and sites where supported | SharePoint item retention is normally 93 days from original deletion; administrative purge and retention configuration matter | Restore a seeded deleted item and site; record permissions, IDs, and elapsed time |
| File version history | Recovering an earlier state of one document | Version limits can be automatic or manually configured and differ by library | Inspect the actual library policy and restore an older seeded version |
| Files Restore | Rolling a document library back after mass deletion, overwrite, or corruption | It is a library operation for activity in the prior 30 days, not a native full-site rollback | Test on a nonproduction library and document the effect on later legitimate changes |
| Purview retention or holds | Preservation, discovery, and records obligations | Preserved content is not the same as an operational in-place restore of every SharePoint object | Search, export, and legal-owner approval against the configured policy |
| Microsoft 365 Backup | Microsoft-operated backup and restore for protected SharePoint sites | Separate product, metering, retention, restore points, and restore rules; data remains in Microsoft's boundary | Protect a pilot site and run both required full-site and selected-content restore scenarios |
| Independent backup | Different service boundary, longer or custom retention, or object-level workflows | Capture and restore support vary by vendor and object; "SharePoint support" is not enough | Object-by-object backup and restore results from the customer's tenant |
Microsoft documents Files Restore as a document-library capability. Full SharePoint site restoration belongs to Microsoft 365 Backup or another product that explicitly supports it. See Microsoft's current Microsoft 365 Backup restore procedure before assigning either behavior to the SharePoint admin center.
Admin Decision Procedure
- Name the incident: single file, list item, library-wide corruption, deleted site, permission damage, or structural loss.
- Record detection lag: determine whether the required recovery point is hours, days, months, or years old.
- Inventory the object: document content, metadata, versions, attachments, permissions, pages, columns, content types, taxonomy, workflows, and apps that matter.
- Select candidate layers: map the scenario to the matrix instead of assuming one tool covers every object.
- Define destination and conflicts: original location, alternate location, overwrite, skip, rename, or merge.
- Test before purchase: run the same seeded recovery through each shortlisted product and retain the evidence.
For a North Brook Vault object-level scope, use the SharePoint backup and pilot guide. For incident ownership and recovery sequencing, use the SharePoint disaster recovery runbook.
Seeded Pilot Scenarios
- Create a document with custom metadata, a unique permission, and two versions. Delete it after the first backup.
- Create a custom list item with an attachment, edit it twice, and then delete it.
- Change ten files in a pilot library, make two legitimate later edits, and test a library rollback without losing track of those later edits.
- Delete a pilot site and test the documented recovery path within the applicable window.
- Break a page or permission assignment and verify whether the candidate product captures and restores that object at all.
Pass/Fail Evidence Checklist
- Record product, license, policy, tenant configuration, test date, and official documentation version.
- Capture source and restored URLs, object IDs, item counts, versions, hashes, metadata, permissions, and timestamps.
- Record selected recovery point, destination, conflict option, start time, finish time, throttling, and item errors.
- Mark every required object as restored, preserved-only, export-only, manually reconstructed, or unsupported.
- Fail the pilot if a required object lacks a tested recovery path or if measured RPO/RTO exceeds the approved objective.
North Brook Vault Fit and No-Fit Boundaries
North Brook Vault backs up supported SharePoint objects, including list-item versions and current site drive items. Current restore handlers cover list items, site drive items, and site pages. It does not currently capture historical document-library file versions as a separate handler, restore every captured structural object, provide native Object Lock configuration, or replace Purview legal preservation. It is a fit only when the required objects and restore paths pass a representative pilot.
When a Microsoft-Only Design May Be Enough
A separate backup product is not automatically required. A Microsoft-only design can be acceptable when approved recovery points fit the native windows, Files Restore covers the relevant document-library incidents, Microsoft 365 Backup protects every required site, Purview meets preservation obligations, and tested Microsoft restore performance meets the business objective. Record that conclusion as a risk decision rather than a general statement that SharePoint protects itself.
Add or evaluate an independent service when the organization requires a separate administrative boundary, different retention rules, supported object-level workflows not available in the chosen Microsoft path, or a second recovery path for a defined threat. Layering products without mapping objects can create cost and false confidence: two products may capture the same files while neither restores a required list schema, permission model, workflow, or taxonomy dependency.
Decision rule: choose native recovery, Microsoft 365 Backup, independent backup, or a layered design only after the required scenario succeeds. Architecture preference is not recovery evidence.
Inspect managed SharePoint coverage Discuss a SharePoint recovery consultation Review managed-service pricing