Microsoft 365 Ransomware Recovery Runbook

Direct answer: contain identities and synchronized endpoints before restoring data. Preserve evidence, determine affected objects and the earliest known malicious activity, verify a clean recovery point, choose native or backup recovery by tested object support, restore to a controlled destination, validate with the data owner, and reconcile legitimate changes made after the chosen point.

Do not assume that every encrypted file will overwrite its version history, that every privileged account can instantly remove every hold, or that a backup guarantees recovery. Microsoft 365 recovery behavior depends on workload, policy, versioning, recycle-bin state, retention, account state, permissions, and incident timing. Backup behavior depends on successful capture, retained points, supported restore handlers, administrative controls, and a clean destination.

Recovery Decision Table

OneDrive sync can propagate local file modifications to Microsoft 365. This is a reason to include synchronized devices in containment and recovery planning, not proof that all clean versions are gone. Microsoft documents version history, recycle bins, Files Restore, retention, and newer Microsoft 365 Backup capabilities as layers. Validate the tenant's actual settings and limitations using Microsoft's Microsoft 365 ransomware protection overview.

Roles and Incident Fields

• Incident commander: [name/title and alternate]
• Identity containment owner: [name/title]
• Endpoint containment owner: [name/title]
• Microsoft 365 service owner: [name/title]
• Backup and recovery owner: [name/title]
• Legal/evidence owner: [name/title]
• Business validation owner: [name/title]
• Earliest known malicious activity: [timestamp and timezone]
• Affected workloads and objects: [users, sites, libraries, mailboxes, apps]
• Approved recovery point and destination: [time, source, location, approver]

Prepare Before an Incident

1. Define recovery objectives from business impact and measured tests. Use the RTO and RPO worksheet; do not copy a vendor's default schedule into policy.
2. Map each required object to native recovery, successful backup capture, retained recovery points, and tested restore support. Include permissions, metadata, versions, memberships, and destination constraints where material.
3. Separate daily production administration from backup-service administration as far as the implementation supports. Monitor role changes, application consent, retention changes, bulk deletion, and backup failures.
4. Document how responders access the backup service if Microsoft Entra or normal administrator devices are unavailable. Protect emergency access and test it.
5. Run quarterly or risk-based restore exercises. Restore representative items to a controlled destination and record elapsed time, fidelity, unsupported objects, and owner acceptance. The backup field guide provides the test structure.

Incident Runbook

1. Declare and Contain

1. Open the incident record and establish one incident commander, decision log, communication channel, and evidence location.
2. Isolate suspected endpoints and pause OneDrive sync where appropriate. Do not reconnect a device until the endpoint-response owner clears it.
3. Disable or restrict compromised identities, revoke sessions and tokens, remove malicious authentication methods, and investigate newly consented or modified applications. Preserve logs before their retention window expires.
4. Protect clean administration. Use a known-clean device and approved emergency identity; rotate credentials and certificates according to the incident scope.

Microsoft's ransomware response playbook explicitly includes pausing synchronization, cleaning devices, and recovering OneDrive before sync is re-enabled.

2. Scope the Data Impact

1. Establish the earliest known malicious activity from endpoint, identity, audit, file, and application evidence. Treat it as a hypothesis until corroborated.
2. Identify affected users, sites, libraries, folders, file types, mailboxes, Teams resources, sharing changes, and permissions. Record both changed and deleted objects.
3. Sample files across the timeline and verify that candidate clean versions open safely. Do not rely only on extension or modification time.
4. Review native recovery state and backup jobs independently. A successful job can still contain item-level failures or a recovery point after compromise.

3. Select the Recovery Method

OneDrive Files Restore can restore an entire OneDrive to an earlier point within the last 30 days when the feature and content state support it; review Microsoft's current Files Restore instructions. SharePoint has separate library and recycle-bin workflows. Retention-preserved content can support discovery or retrieval but is not automatically an operational rollback.

1. Compare native recovery and backup by coverage, clean-point confidence, overwrite risk, destination, elapsed time, and effect on legitimate later work.
2. Require the incident commander, service owner, and business owner to approve the recovery point and expected data loss.
3. Prefer a controlled alternate destination or limited sample when the original environment or overwrite behavior is uncertain.

4. Restore, Validate, and Resume

1. Restore a representative sample first. Scan and open files from a clean device; verify content, metadata, permissions, and destination behavior.
2. Execute the approved batch restore while recording start/end time, item counts, errors, retries, throttling, and operator actions.
3. Reconcile legitimate work created after the recovery point. Do not silently overwrite later business records.
4. Obtain business-owner acceptance before reconnecting endpoints or reopening broad access. Re-enable sync in controlled stages and monitor for renewed changes.
5. Complete a post-incident review, remediate control gaps, and repeat the affected detection and recovery tests.

Evidence Checklist

• ☐ Incident authority, commander, timeline, affected scope, and decision log.
• ☐ Identity, endpoint, audit, application-consent, and file-activity evidence preserved.
• ☐ Confirmation that compromised access and synchronization are contained before restore.
• ☐ Native recovery state, configured windows, and tested clean samples.
• ☐ Backup job status, item errors, retained point, object support, and administrative access record.
• ☐ Approved recovery point, expected data loss, destination, and rollback decision.
• ☐ Restore counts, failures, elapsed time, fidelity checks, and business acceptance.
• ☐ Reconciliation record, staged resumption, monitoring, and post-incident actions.

North Brook Vault and Storage Limitations

North Brook Vault manages backup infrastructure and storage as a SaaS service. It does not currently expose native Object Lock configuration or enforcement, guarantee an RPO, or guarantee a ransomware recovery outcome. S3 compatibility is not proof of Object Lock, and Object Lock is not a physical air gap. Require documented provider responsibilities and tested deletion and recovery controls rather than relying on terminology.

North Brook Vault restore support varies by object type. It does not restore Teams chat messages, channel messages, channel structure, or meeting transcripts. Review the Microsoft 365 shared-responsibility guide and validate every required recovery object during a pilot.

Review ransomware recovery boundaries Discuss a ransomware recovery consultation