Your head of marketing left last month. Her private Asana workspace, three years of campaign briefs, launch timelines, and vendor contacts, wasn't included in the backup scope. Nobody knew until the new hire asked where the Q3 launch plan was. The IT admin checked the backup tool: it was only connected to the shared Engineering and Product workspaces. Marketing's data was never covered.
This is a policy problem, not a technology problem. The backup tool worked fine. It just wasn't configured to cover everything that mattered, and nobody had documented what "everything" meant.
The shared responsibility model means your SaaS provider protects the platform, not your account data. But even teams that understand this and have a backup tool in place often lack a written policy. Without one, backup decisions get made ad hoc: the ops lead sets up a manual CSV export "just in case," the IT admin connects a backup tool to two apps but forgets the third, the new hire doesn't know backups exist at all.
A SaaS backup policy fixes that. It documents what gets backed up, how often, who's responsible, and what recovery looks like. It's not a hundred-page governance document. It's a page or two that makes sure the right things happen consistently, especially when the person who originally set them up is on holiday or has moved on.
Why every organisation needs a SaaS backup policy
The obvious reason is data protection. But the practical reason is accountability.
Without a written policy, there's no clear answer to basic questions. Which SaaS apps are backed up? All of them, or just the ones someone remembered to connect? How long are backups retained? Does anyone test restores? What happens when a new app gets added to the stack?
These questions don't matter until something goes wrong. Then they matter a lot. The team that deleted a project board six weeks ago needs to know if a clean backup exists. The CFO preparing for a SOC 2 audit needs to show documented backup procedures. The departing employee's manager needs to know whether private project data was included in the backup scope.
A policy also protects against the bus factor. If your backup setup lives entirely in one person's head, it's not a system. It's a single point of failure. A written policy means anyone on the team can understand, verify, and maintain the backup process.
What a backup policy should cover
At its simplest, a backup policy answers: what gets backed up, how often, how long backups are kept, who's responsible, who can access restore functions, and how you verify it all works. That's it. The sections below walk through each of those decisions with the specific choices you need to make and document.
Defining scope: which apps, which data
Start by listing every SaaS app your organisation uses that contains business-critical data. Not just project management tools. Think about your CRM, knowledge base, helpdesk, design tools, communication platforms, and any app where losing data would cause real pain.
For each app, document what data types you're backing up. This matters because no backup tool covers everything. API limitations mean certain data types are inaccessible. Automations, dashboard configurations, and some file types typically can't be backed up in apps like Trello, ClickUp, or Monday.com. Your policy should be honest about these gaps so nobody is surprised later. And don't assume the app's native recycle bin fills the gaps: most recycle bins expire after 30 days and don't cover field-level changes at all.
Your scope definition should also cover workspace selection. In tools like Asana, ClickUp, and Trello, backup scope is controlled at the workspace level. If your organisation has workspaces owned by different departments, you need to ensure each one is included. This sometimes requires inviting additional team members to authorise the backup tool so their private workspaces are covered.
Setting backup frequency and retention
These two settings define your Recovery Point Objective (RPO): the maximum amount of data you can afford to lose.
Frequency: For most SaaS apps, daily backups are the right balance between risk reduction and practicality. Real-time backup sounds better in theory, but SaaS APIs have rate limits that make continuous backup impractical at scale, and the marginal improvement in RPO rarely justifies the cost. Daily snapshots give you a 24-hour RPO, which covers the vast majority of SaaS data loss scenarios.
Retention: This is how long each snapshot is kept. Retention determines how far back you can recover. If someone corrupts data via a bad import and nobody notices for two months, you need a snapshot from before that import. Short retention (30 days) won't help. Longer retention (6 months, 2 years, or more) gives you the safety margin to handle slow-discovery problems.
Your policy should specify both the minimum backup frequency and the minimum retention period. It should also specify who can change these settings, because reducing retention in ProBackup (or any backup tool) is a destructive action that permanently deletes older snapshots. If your organisation follows the 3-2-1 backup rule (three copies, two destinations, one offsite), document that here too.
In ProBackup, retention is configurable per account: 3 months, 6 months, 2 years, or 4 years depending on your plan. Premium users can request longer retention by contacting support. The right setting depends on your compliance requirements and how quickly your team typically notices data issues.
Assigning ownership and access controls
A backup policy without an owner is a document nobody reads. Name a specific person (not a team, a person) who is responsible for:
- Making sure all critical SaaS apps are connected and backing up successfully. This includes verifying that new workspaces created by other teams get added to the backup scope.
- Reviewing backup status reports weekly. ProBackup sends weekly status emails on Pro and Premium plans, but the owner needs to actually read them and act on failures.
- Responding to smart alerts when unusual deletion activity is detected. A spike in deletions could mean a disgruntled employee, a misbehaving integration, or just a big clean-up. The owner should investigate within one business day.
- Adding new SaaS apps to the backup scope when the organisation adopts them. This is the one that slips most often. Someone signs up for Notion or Airtable, the team migrates data into it, and nobody thinks to connect it to the backup tool until something goes wrong.
- Updating the policy itself when scope, frequency, or retention changes. The policy is only useful if it reflects reality.
Access controls matter too. Not everyone on the team needs the ability to restore data. In ProBackup, the admin user has full access to all backup data and billing. Invited users can be scoped per-platform with granular permissions: view only, export, or restore. Your policy should define who gets which level of access and under what circumstances.
This is also where you document the authentication setup. ProBackup supports two-factor authentication and Google SSO on all plans, with enterprise SSO (SAML) on Premium. Your policy should require 2FA for anyone with restore access, at minimum. The irony of a compromised backup account is not lost on anyone who's been through it.
Testing and audit requirements
Backups you've never tested are assumptions, not safeguards. Your policy should mandate regular restore tests and document the procedure.
A straightforward testing process: once per quarter, pick a recent backup snapshot, select a small set of records (a project, a handful of tasks, a few CRM records), restore them, and verify the result against the originals. In ProBackup, restored items are created as new copies in the original location, so this is completely non-destructive. You restore, compare, confirm the data matches, and delete the test copies.
What to do when a test fails. Sometimes the restored data won't match what you expected. A custom field might be empty. An attachment might be missing. Comments might not be included for a particular app. This doesn't necessarily mean the backup is broken. It usually means there's an API limitation you weren't aware of, a data type that can't be backed up due to platform restrictions. When this happens, document the gap in your policy's scope table (the "data types excluded" column) so it's captured as a known limitation, not a surprise during a real incident. If the missing data type is critical, evaluate whether a manual export or alternative process can cover the gap.
Document every test result. Record the date, which app and data types were tested, who performed the test, the time from trigger to completion, and whether the restored data matched expectations. This log is useful for your own confidence, but it's also exactly what an auditor will ask for during a SOC 2 or ISO 27001 assessment.
Your policy should also define how often the policy itself gets reviewed. Once a year is the minimum. Review the app inventory (has the team added new tools?), the scope (are all workspaces covered?), retention settings (do they still match your compliance needs?), and user permissions (has anyone left the company who still has backup access?).
Template: sample SaaS backup policy
Below is a starter template you can adapt. It's deliberately concise. A policy nobody reads because it's 30 pages long is worse than a one-page policy everyone follows.
[Organisation name] SaaS data backup policy
Effective date: [date]
Policy owner: [name and role]
Last reviewed: [date]
1. Purpose
This policy defines how [Organisation name] protects data stored in third-party SaaS applications from accidental loss, malicious deletion, data corruption, and compliance failures.
2. Scope
The following SaaS applications are covered under this policy:
ApplicationWorkspaces includedData types excludedBackup tool[e.g. Asana][e.g. All active workspaces][e.g. Automations, dashboard configs][e.g. ProBackup][e.g. HubSpot][Full account][e.g. Call logs, dashboards][e.g. ProBackup][e.g. Trello][e.g. Product, Engineering boards][e.g. Power-Ups, deleted cards prior to backup][e.g. ProBackup]
3. Backup frequency and retention
All applications in scope are backed up daily (every 24 hours). Backup retention is set to [e.g. 2 years]. Changes to frequency or retention settings require approval from the policy owner.
4. Access controls
Backup admin access is held by [name/role]. Restore access is granted to [names/roles]. All users with restore access must have two-factor authentication enabled. Permissions are reviewed quarterly.
5. Monitoring
The policy owner reviews weekly backup status reports and responds to automated alerts (e.g. unusual deletion activity) within [e.g. 1 business day].
6. Restore testing
A test restore is performed quarterly. The test includes selecting a previous snapshot, restoring a sample of records, verifying data accuracy, and documenting the results. Test records are summarised in the [restore test log / internal wiki / shared drive].
7. Policy review
This policy is reviewed annually, or sooner if the organisation's SaaS stack, team structure, or compliance requirements change. The review covers app inventory, backup scope, retention settings, user permissions, and testing logs.
Want a ready-to-use version? Download the complete SaaS backup policy template with pre-filled examples for common platforms, a quarterly restore test log, and a review checklist
Aligning your policy with SOC 2 and ISO 27001
If your organisation is pursuing or maintaining SOC 2 or ISO 27001 certification, your backup policy isn't just good practice. It's a control that auditors will specifically look for.
SOC 2 (specifically the Availability trust service criterion) requires organisations to demonstrate that they can restore data and systems to a defined state within documented recovery objectives. An auditor will want to see your backup policy, evidence that backups are running (status reports, logs), and records of restore testing. They'll also check that access controls on backup data are appropriate and that retention periods match your stated data handling commitments. ProBackup's Premium plan includes audit reports specifically designed to provide this evidence, and our Vanta integration automates continuous compliance monitoring.
ISO 27001 (Annex A.12.3) requires documented backup procedures, including what data is backed up, the backup schedule, retention periods, and regular testing. The standard also requires that backup media (in this case, the cloud infrastructure where backups are stored) be adequately protected. ProBackup stores all data in AWS Dublin with AES-256 encryption, and the AWS data centres themselves are ISO 27001, SOC 1 and SOC 2, and PCI Level 1 certified. Full details on our infrastructure and security controls are on our data security page.
GDPR doesn't prescribe a specific backup framework, but Article 32 requires "the ability to restore the availability and access to personal data in a timely manner." If your SaaS apps contain EU personal data (they almost certainly do), your backup policy is part of your Article 32 compliance story. Your policy should also address how GDPR deletion requests interact with backups, since personal data in a backup snapshot may persist beyond a deletion in the live app.
For a deeper look at how backup infrastructure supports these frameworks, see why backups matter for SOC 2 and ISO 27001.
What to do next
You don't need to get this perfect on the first draft. Start with the template, fill in the blanks for your current SaaS stack, and share it with whoever manages IT and security at your organisation. A rough policy is better than no policy, and you can refine it as you learn what your actual RPO needs and compliance requirements look like.
If you don't yet have a backup tool in place, start a free trial of ProBackup. Setup takes about three minutes per app, and your first snapshot runs within 24 hours. Plans start at $25/month (billed yearly) and cover unlimited apps under a single licence. See how other teams protect their SaaS data on our success stories page.
