You probably know what SaaS apps your team uses. You probably don't know which of them are actually protected.
That's not a criticism. It's just how SaaS adoption works. Someone signs up for Notion to manage a knowledge base. Another team starts using Airtable for client tracking. HubSpot gets connected to three different integrations. Each tool is evaluated for features and price, and almost never for what happens when data inside it disappears.
The result is a SaaS stack where some apps are backed up, some aren't, and nobody has a complete picture of where the gaps are. The shared responsibility model means your providers aren't filling those gaps for you. They protect the platform. You protect the data.
This post walks through a five-step audit process to find your gaps and fix them. It shouldn't take more than an afternoon, and you'll come out of it with a clear map of what's protected, what isn't, and what to do about it.
Why you need a SaaS data protection audit
Most teams discover their data protection gaps after an incident. Someone deletes a board. An import corrupts 200 records. A former employee's private workspace turns out to have never been included in the backup scope.
The audit prevents that. It forces you to answer, for every app in your stack: what happens if we lose this data tomorrow? And the honest answer, more often than not, is "we don't know."
There are also compliance reasons. If you're pursuing or maintaining SOC 2, ISO 27001, or GDPR compliance, auditors will expect you to demonstrate that you've identified the systems containing critical data and have documented protection measures for each one. An ad hoc backup setup connected to three out of nine apps won't pass that review.
But the simplest reason is this: your SaaS stack has probably grown since anyone last thought about data protection. The average team adds two or three new tools per year. Each one is a potential gap if nobody stops to ask whether it's covered.
Step 1: Inventory every SaaS app your team uses
Start with a full list. Not just the apps you pay for. Every SaaS tool that contains data someone on your team would miss if it vanished.
Check your identity provider (Okta, Google Workspace, Azure AD) for a list of connected applications. Check expense reports and credit card statements for SaaS subscriptions. Check browser extensions and OAuth permissions. Ask department leads what tools their teams use day-to-day.
You'll find apps you forgot about. You'll find apps you didn't know the team was using. That's normal. The average mid-size company uses somewhere between 50 and 100 SaaS apps, and IT typically knows about 60-70% of them.
For each app, record:
- The app name and what it's used for
- Which team or department owns it
- How many users have access
- Whether it's paid or on a free tier (free tiers often have weaker retention and recovery)
- Whether it's connected to other apps via integrations or APIs
Don't filter at this stage. The goal is a complete inventory. You'll prioritise in the next step.
Step 2: Map which apps hold business-critical data
Not every SaaS app needs the same level of protection. The tool your design team uses to brainstorm mood boards is different from the CRM that holds every client interaction for the past three years.
Go through your inventory and categorise each app by data criticality:
Tier 1: Business-critical. Losing this data would directly impact revenue, client relationships, compliance, or operations. Think CRM data (HubSpot, Salesforce), project management (Asana, Monday.com, ClickUp, Jira), client-facing knowledge bases, financial records, and any app where data loss means work has to be reconstructed from scratch.
Tier 2: Important but recoverable. Losing this data would be painful and time-consuming, but the business could reconstruct it within a reasonable timeframe. Internal wikis, communication archives (Slack), design assets, and secondary project tools often fall here.
Tier 3: Low impact. Losing this data would be an inconvenience, not a crisis. Tools used for brainstorming, non-critical scheduling, or internal experimentation.
Your Tier 1 apps are the priority. Everything else can follow, but if your CRM and project management tools aren't protected, you have a problem regardless of what's happening with the rest.
Step 3: Check native backup and recovery options
For each Tier 1 and Tier 2 app, document what the platform itself offers for data recovery. This is where most teams discover their assumptions don't match reality.
Look up three things:
Recycle bin / trash retention. How long do deleted items stay recoverable? Most platforms cap at 30 days. Trello has no recycle bin for cards at all. HubSpot gives you 90 days for records but only 30 for files.
Version history. Can you roll back individual records to a previous state? Notion offers version history but it's limited to 7 days on the Free plan and 30 on Plus. Most project management tools don't version-control field configurations or custom field values at all.
Export options. Can you export your data manually? In what format? How complete is the export? Many platforms offer CSV exports that miss comments, file attachments, field history, and relational data. An export that gives you task names without their comments, assignees, and custom fields isn't really a backup.
For each app, record the answers in a simple table. You'll quickly see a pattern: most native recovery features are designed for "I accidentally deleted this five minutes ago," not for "something went wrong three weeks ago and we just noticed."
Step 4: Identify gaps in retention and restore
Now compare what each app offers against what you actually need. This is where the audit gets useful.
For each Tier 1 app, ask:
Is 30 days of recycle bin retention enough? If your team wouldn't notice a data problem within 30 days (and for slow-burn issues like integration corruption or field-level overwrites, they often wouldn't), then the native retention window is too short.
Does the recycle bin cover the right data types? Most recycle bins only cover top-level items like tasks and projects. Changes to field configurations, custom field values, automations, and views are typically not recoverable from trash.
What about bulk overwrites and integration errors? A bad CSV import that changes 500 field values doesn't trigger a trash event. Neither does a misbehaving integration. These are among the most common data loss scenarios, and no native recycle bin catches them.
What's your actual RTO and RPO? If you've already defined your Recovery Time Objective and Recovery Point Objective, check whether your current protection can meet them. If your RPO is 24 hours but your only recovery option is a manual CSV export from last quarter, you're not meeting it.
Are access controls adequate? Can a single user permanently delete data from the recycle bin? Is MFA enforced? Who has admin access that doesn't need it? These aren't backup questions per se, but they're data protection gaps the audit should surface.
Document each gap. Be specific: "Monday.com: 30-day recycle bin doesn't cover field configuration changes. No protection against bulk import errors. RPO effectively undefined."
Step 5: Build a protection plan for each app
For every gap you've identified, decide how to close it. There are really only three options:
Accept the risk. For Tier 3 apps, this might be fine. If losing the data would be a minor inconvenience and the cost of protecting it isn't justified, document the decision and move on. The key is making it a conscious choice, not an oversight.
Implement manual workarounds. Scheduled CSV exports, manual screenshots of dashboards, periodic data exports to Google Drive. These work for low-volume apps with simple data structures. They don't scale, they're error-prone, and they depend on someone remembering to do them. But for an app with five users and limited data, they might be enough.
Set up automated independent backups. For Tier 1 and most Tier 2 apps, this is the answer. You need a backup tool that runs automatically, stores data independently from the source platform, and lets you restore to a specific point in time.
ProBackup covers 19 platforms under a single licence, including Asana, Monday.com, ClickUp, Trello, Notion, HubSpot, Jira, Airtable, Slack, and more. Daily automated snapshots stored in AWS Dublin with AES-256 encryption. Granular restore down to individual records, comments, and files. Configurable retention from 3 months to 4+ years. Plans start at $25/month (billed yearly).
If you're also building or updating a formal backup policy as part of this audit, our post on how to build a SaaS backup policy includes a downloadable template.
Free template: SaaS data protection audit worksheet
We've created a spreadsheet template to make this audit easier. It includes:
- An app inventory tab with columns for name, department, user count, tier, and integration dependencies
- A native recovery tab to document each app's recycle bin retention, version history, and export options
- A gap analysis tab that maps each gap to a remediation action (accept, manual workaround, or automated backup)
- A protection plan summary with backup tool, frequency, retention, and owner per app
Download the audit worksheet →
The worksheet follows the same five-step process described in this post. Fill it in with your team, and you'll have a complete picture of your SaaS data protection posture in an afternoon.
What to do next
Run the audit. It doesn't need to be perfect on the first pass. Start with your Tier 1 apps, document what you find, and address the gaps. You can expand to Tier 2 and Tier 3 apps over the following weeks.
If the audit reveals that most of your critical SaaS data isn't independently backed up (and for most teams, it will), start a free trial of ProBackup. Setup takes about three minutes per app. Your first snapshot runs within 24 hours. See how other teams have used ProBackup to close their data protection gaps on our success stories page.
