A restored SharePoint address is the start of recovery, not its acceptance. The project owner needs evidence that the required documents open, the right people can work, and restricted material remains restricted.
This procedure is for a Microsoft 365 administrator and project owner handling a deleted project site. It includes a synthetic rehearsal set and a downloadable acceptance worksheet. It is a procedure template, not a report of a customer restoration or a test performed in your tenant.
Identify what was deleted before choosing a route
Record the exact site address, deletion timestamp and time zone, business owner, and whether the workspace connects to a Microsoft 365 group or Teams channel. If the site still exists and only one document is missing, investigate item recovery or version history instead. Replacing a whole workspace is a different operation.
Microsoft documents a 93-day retention period for deleted SharePoint sites. Associated Microsoft 365 group resources have a shorter, 30-day window. Record both dates when applicable; the longer site window does not establish that the complete group workspace remains recoverable. Microsoft Learn: restore deleted sites.
Private and shared channel sites need a separate decision. Teams manages their lifecycle and synchronises site membership with channel membership; their permissions are not managed independently in SharePoint. Microsoft documents a 30-day channel restoration window. A channel site restored after that window can operate as a standalone site, so a working URL does not prove the Teams channel is back. Follow the applicable private-channel or shared-channel guidance with the Teams owner.
This guide addresses SharePoint in Microsoft 365, not an on-premises SharePoint Server recovery. It does not treat the recycle bin, version history or retention as an independent backup. Those are different recovery mechanisms; document the selected mechanism and verify its actual scope. The broader backup recovery testing guide covers independent recovery assurance.
Define acceptance before the restore starts
Agree which project task must work again, the required content date, the target time to resume it, and who may authorise restoration. Record the administrator, business approver and incident reference. If compromise or a preservation requirement is suspected, coordinate with the incident lead before changing data or reconnecting integrations.
Separate the recovery operator from the people performing acceptance. Microsoft distinguishes the SharePoint Administrator role from a site administrator, who does not automatically have access to the SharePoint admin center. Prefer the least privileged suitable role. Administrative capability also does not mean automatic access to every site's content. Microsoft Learn: SharePoint Administrator role.
For a rehearsal, prepare an approved disposable site with synthetic content: Project-summary.txt containing a revision marker, Estimate.csv with three invented cost rows, a Decisions list with two sample entries, and a Restricted library. Define a project editor, a read-only reviewer and an account that should have no access. Do not delete a live project to try this worksheet.
Record expected paths, file contents, list values and permissions before the rehearsal. Identify any intentionally different library permissions or sharing links. For a real incident, use the best available approved inventory and mark unknown expectations explicitly. A test with no known expected result cannot demonstrate completeness.
Perform and record the approved restoration
- For an eligible deleted site, open Deleted sites in the SharePoint admin center using an authorised SharePoint Administrator account.
- Match the recorded address and deletion details. Select that one site, then choose Restore. Microsoft's restore button is not shown when multiple sites are selected.
- Record the action time, observed status and any error reference. Use the channel-specific route identified earlier when the workspace is a private or shared channel site.
These steps follow Microsoft's deleted-site procedure. If the expected site is absent, a dependency is outside its recovery window, or the operation fails, stop and investigate eligibility with the responsible administrator or support provider. Do not permanently delete the remaining site merely to reuse its address.
Test six paths using the intended accounts
Use separate browser sessions with approved test identities. An administrator opening every file is insufficient: it can hide the very permission problem the project team faces. Record actual results and evidence locations for each check.
- Open the workspace. The editor follows the recorded site link and reaches the expected project page and library. Where Teams is in scope, test the channel's actual Files or tab route as well as the direct URL.
- Read the required content. Open the summary, compare its revision marker, and inspect the estimate's three rows. Check agreed list entries, required metadata and relevant versions against the baseline. File counts alone do not establish that the right information returned.
- Perform permitted work. In the synthetic test area, the editor creates and saves a labelled test document, then reopens it. The reviewer opens an approved file and confirms that an attempted edit is denied under the intended read-only policy.
- Check the denied path. The excluded account attempts the Restricted library and a recorded direct file link. Expected access denial must hold. Test only approved synthetic material; do not use real confidential documents as probes.
- Follow dependencies. Open one agreed cross-file link and inspect each required tab or integration. Test automation only in a controlled mode that cannot send real notices or alter production records. Mark untested dependencies as unverified, not passed.
- Complete a project task. The owner uses the restored material to perform one agreed activity, such as checking the synthetic estimate and recording a decision. Record whether that task is usable, the actual completion time and remaining limitations.
Close the business gap, not just the restore dialog
| Outcome | Required record |
|---|---|
| Passed | The observed result matches the agreed expectation; link the evidence. |
| Failed | Describe the mismatch, responsible owner and retest action. |
| Unverified | State what could not be tested and who will resolve it. |
| Not applicable | Explain why this check is outside the approved scope. |
A denied-access test that unexpectedly succeeds is a failure even when all documents open. Investigate the approved permission model; granting everyone broader access is not an acceptable way to pass.
For example, the editor may open Estimate.csv while a project tab still points to a deleted location. Record the tab failure and its owner. The business can approve limited work using the verified direct path, or keep recovery open until the dependency is repaired and retested. This is a hypothetical decision, not a measured outcome.
Record who accepts any limited operation, its expiry or review time, unresolved actions and the retest result. Remove approved temporary recovery access when it is no longer needed. Retain evidence in the restricted incident record. A passed worksheet covers the checks performed; it is not a legal guarantee or proof that every site component was recovered.
Download the restoration acceptance worksheet
Download the SharePoint restore worksheet
The editable text worksheet keeps recovery-window decisions, the synthetic baseline, six tests, exceptions and owner acceptance together. For ongoing organisation and permission design, use the SharePoint file-management guide. For help planning a supervised recovery, contact North Star's Microsoft 365 support team.