Most organizations that have M365 backup configured don't have a written policy describing how it works, who's responsible for it, and what "success" means during an incident. This matters during audits — ISO 27001, SOC 2, and HIPAA all require documented backup procedures — and it matters even more when an incident actually occurs and you're trying to make decisions quickly under pressure.
Here's a policy template that covers the essential components. Adapt the specifics to your organization.
Purpose and Scope
The policy should open by stating what it covers. For most organizations: all data stored in the Microsoft 365 tenant, including Exchange Online mailboxes, SharePoint Online site collections and document libraries, OneDrive for Business drives, and Microsoft Teams channel and chat history. Explicitly state whether shared mailboxes, resource mailboxes, and distribution groups are in scope — these are often forgotten and then become a problem during an incident.
Define who the policy applies to: the IT team is responsible for implementation and monitoring; department heads are responsible for identifying their critical data and recovery requirements; the CISO or designated officer is responsible for annual policy review.
Recovery Objectives
This section is the heart of the policy and should be agreed upon with business stakeholders, not decided by IT alone. Recovery Point Objective (RPO) defines the maximum acceptable data loss — how much data from before the incident you're willing to lose. A 24-hour RPO means your backup runs daily and you may lose up to a day of changes. Recovery Time Objective (RTO) defines how quickly you need to be operational after declaring a recovery event.
Reasonable baselines for most organizations: RPO of 24 hours for standard workloads, 4 hours for business-critical workloads. RTO of 4 hours for individual item restores, 24 hours for full mailbox or site collection restores. These need to be documented, communicated, and tested — not just written down and filed.
Backup Configuration Requirements
Specify what must be configured: backup frequency (daily at minimum, 6-hourly for critical systems), retention period (90 days of daily backups plus 12 monthly snapshots is a common baseline), and storage requirements. The policy should explicitly require that backup data be stored outside the primary M365 tenant — separate credentials, separate infrastructure — and ideally in immutable object storage (S3 Object Lock Compliance mode) with a retention lock matching the policy retention period.
Document the backup tool, the storage location, the access credentials (stored in a secrets manager, not a shared spreadsheet), and the alert configuration for backup failures. If a backup job fails silently for a week, you don't want to discover this during an incident.
Testing Requirements
The policy must require restore testing — not just backup verification. Quarterly individual item restores: pick a random mailbox, restore a specific email from 60 days ago, verify the content is correct. Annual full workload restores: restore an entire mailbox or SharePoint site to an alternate location and verify completeness. Document the results, including what was restored, how long it took, and any issues encountered. This documentation is what you show auditors.
Incident Response Integration
The backup policy should reference the incident response plan and specify the triggers for invoking recovery procedures: detection of ransomware affecting M365 data, report of significant accidental deletion, request from legal or HR for data that's been deleted. Define who has authority to initiate a recovery, who must approve full site restores (which may have impact on recent work), and how affected users are notified.
Review and update the policy annually, or after any significant change to your M365 environment or after any incident that required invoking recovery procedures. The first test of the policy shouldn't be a real incident.