Direct answer: a SharePoint disaster recovery plan must say which tool recovers each incident, which objects it can restore, who approves the action, where restored data goes, and how success is measured. "We have backups" is not a plan, and a successful backup job is not recovery evidence.
Correct the native-tool assumptions before writing the runbook. SharePoint Files Restore rolls a document library back for activity in the previous 30 days; it is not a full-site rollback in the SharePoint admin center. Deleted SharePoint sites can normally be restored by an administrator during their documented 93-day retention window. Microsoft 365 Backup is a separate product with SharePoint site and selected-content restore workflows. Microsoft's resiliency documentation and Microsoft 365 Backup restore procedure should be attached to the runbook and reviewed when the service changes.
SharePoint Incident and Recovery Matrix
| Incident | First candidate | North Brook Vault boundary | Decision gate |
|---|---|---|---|
| One recently deleted file, folder, or list item | Recycle bin or version history where applicable | Selective restore for supported site drive items or list items from retained snapshots | Age, object type, metadata, permissions, and destination |
| Mass document-library deletion or overwrite | Files Restore for activity in the prior 30 days; Microsoft 365 Backup if protected | Restore supported drive items individually or in tested batches; no full-library rollback claim | Blast radius, clean recovery point, later legitimate changes, throughput |
| Deleted SharePoint site | Restore deleted site within Microsoft's documented window or use Microsoft 365 Backup | No current full-site creation or site-rollback handler | Site still recoverable, target URL, dependencies, and site fidelity |
| Custom-list damage | Recycle bin, retention, or Microsoft 365 Backup where applicable | Selective list-item restore is supported; list-structure restore is not currently claimed | Fields, attachments, versions, lookups, and list schema |
| Deleted or corrupted site page | Native version/recycle behavior where available | Selective site-page restore is supported | Web parts, assets, publication state, and rendering |
| Permission, content type, column, taxonomy, workflow, or app damage | Audit and manual correction, Microsoft-native recovery where documented, or product with explicit structural restore | North Brook Vault does not claim universal structural or permission restoration | Exact configuration objects and tested reconstruction procedure |
| Widespread ransomware or malicious administration | Contain identities and sync, preserve evidence, then select native, Microsoft 365 Backup, or independent recovery by object | Supported selective restores only; managed storage is not native Object Lock | Clean point, affected tenants/sites, credential boundary, and recovery order |
Use the SharePoint recovery decision guide to compare the candidate layers and the SharePoint object coverage guide to determine what North Brook Vault can and cannot restore.
Incident Procedure
- Declare and assign: record incident commander, SharePoint administrator, security lead, business owner, recovery operator, approver, and communications owner.
- Contain without destroying evidence: disable compromised sessions or accounts, pause affected sync clients and automation, preserve audit logs, and avoid indiscriminate deletion.
- Identify blast radius: list affected sites, libraries, lists, pages, users, time range, actions, object IDs, and known-good timestamps.
- Protect later legitimate work: export or snapshot changes made after the proposed recovery point before using a rollback operation.
- Choose the least disruptive path: single-item native restore, Files Restore, deleted-site restore, Microsoft 365 Backup, North Brook Vault selective restore, or manual reconstruction.
- Confirm authorization: require business approval for rollback, overwrite, original-location restore, or any action that can remove later changes.
- Restore to an alternate destination first where possible: validate content and metadata before replacing production objects.
- Verify and reconcile: compare counts, hashes, fields, versions, pages, permissions, links, and user access.
- Return to service: re-enable automation and sync in stages, monitor for repeated changes, communicate residual gaps, and retain the evidence packet.
Runbook Inputs
- Approved RPO and RTO by site and incident class. Use the M365 RTO/RPO guide to set measurable targets.
- Site inventory, business owners, data classification, dependencies, and recovery priority.
- Native retention, version policies, Files Restore access, deleted-site procedure, and Microsoft 365 Backup policies.
- North Brook Vault tenant, schedule, retention, storage boundary, supported restore handlers, authorized operators, and escalation path.
- Original and alternate restore destinations, conflict rules, approval thresholds, and communication templates.
Seeded Recovery Exercises
- Single-object exercise: delete a file and a custom list item, recover each through the least disruptive path, and compare metadata.
- Library-corruption exercise: edit and delete a seeded set of files, preserve two later legitimate edits, and test Files Restore or the approved alternative in a nonproduction library.
- Selective-backup exercise: recover supported site drive items, list items, and a site page from a retained North Brook Vault snapshot.
- Deleted-site exercise: delete an approved pilot site and use Microsoft's documented deleted-site or Microsoft 365 Backup path. Do not represent this as a North Brook Vault site restore.
- Structural-loss tabletop: simulate damaged permissions, columns, content types, taxonomy, and workflows; prove the manual or alternate-product reconstruction path.
- Credential-compromise tabletop: assume a tenant admin and backup operator are compromised; review containment, storage boundary, escalation, and deletion controls.
Run exercises after material product, permission, retention, or site-architecture changes, not only on an arbitrary annual date. Never delete a production site merely to prove a product claim.
Pass/Fail Evidence Checklist
- Record incident declaration, roles, approvals, source systems, affected object IDs, and containment timeline.
- Record recovery source, recovery point, snapshot or job ID, destination, conflict option, operator, and escalation events.
- Compare expected and restored item counts, hashes, paths, fields, attachments, versions, pages, permissions, and links.
- Measure time to detect, authorize, locate the recovery point, restore, validate, and return to service.
- List every skipped, capture-only, manually reconstructed, unsupported, or failed object.
- Fail if the required object lacks a tested path, rollback destroys unprotected legitimate work, or measured RPO/RTO misses the approved target.
- Require corrective action, owner, due date, and a repeat exercise for every failed criterion.
North Brook Vault Fit and No-Fit Boundaries
North Brook Vault fits a SharePoint DR design when supported list items, site drive items, or site pages need selective restoration from retained managed-service snapshots and those workflows pass the tenant pilot. Customers remain responsible for tenant authorization, incident command, business approval, customer-side access, and representative exercises.
It is not currently a complete-site DR product. It does not claim full-site rollback or creation, historical document-library version capture, universal configuration or permission restoration, native Object Lock, or uninterrupted access during a provider incident. A complete runbook may need SharePoint native recovery, Microsoft 365 Backup, Purview, manual reconstruction, and North Brook Vault together.
Review SharePoint recovery coverage Discuss a SharePoint DR consultation Review managed-service pricing