Most organizations that take SaaS backup seriously start and stop with Microsoft 365 and Google Workspace. Those two suites get the budget line, the vendor evaluation, and the restore test. Then the Q4 audit arrives and someone asks a simple question: where is the recoverable copy of the CRM, the chat history, and the engineering ticket system? The honest answer for many teams is that nobody owns it.
The three platforms that most often fill that gap are Salesforce, Slack, and Atlassian Cloud (Jira and Confluence). They sit under the same shared-responsibility logic as every other SaaS product: the vendor keeps the service running and protects against its own infrastructure failures, and the customer is accountable for the data inside it. Each vendor draws that line a little differently, and the differences determine what a bad Tuesday actually costs you.
The shared-responsibility line, stated by the vendors
Atlassian is the most explicit. Its data-management documentation says backups are “not used to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted issues, projects, or sites,” and recommends that customers take regular backups of their own. In practice that means a bulk edit gone wrong, an admin deleting a project, or a compromised account running a destructive script is your recovery problem, not Atlassian’s.
Slack’s help documentation is similarly direct about deletion: deleted messages cannot be recovered. Retention is a configuration choice that workspace owners make, and a retention policy set too short deletes data on a schedule by design. Salesforce frames its guidance as a recommendation to keep regular backups, including a manual point-in-time export before any major data project.
None of this is hidden or unreasonable. It is the standard model. The failure is organizational: the platform is treated as if the vendor’s uptime guarantee were a recoverability guarantee.
Salesforce: recycle bin, last-resort recovery, and a native backup product
Salesforce’s Recycle Bin keeps deleted records for 15 days, and its capacity is capped relative to your org’s storage, so a large mass deletion can push older entries out early. The Recycle Bin restores the latest version of a record. It does not give you point-in-time history, so a field overwritten before deletion comes back overwritten.
Beyond that, Salesforce has had a turbulent history with native recovery. It retired its Data Recovery Service on July 31, 2020, saying the service did not meet its quality standards, then reinstated it in March 2021 while signaling a replacement was coming. That replacement, Backup and Restore, was announced as a native service that creates backup copies of Salesforce data, lets administrators set retention for those copies, restores data into an org, and audits who uses those functions. It covers standard and custom objects and was positioned as encrypted at rest and in transit.
Two cautions apply. First, the announcement material does not state retention limits or pricing, and the product is a separately licensed add-on rather than part of every subscription, so confirm both with your account team before you assume you have it. Second, native backup of data is not the same as backup of configuration. Metadata such as flows, permission sets, and custom code is what makes an org function, and many organizations track that separately in version control or a deployment tool. Whatever you choose, test a restore into a sandbox, not only a successful backup job.
Slack: retention is a deletion policy, and exports are plan-dependent
Slack backup is mostly a question of what you are allowed to export. On Slack’s own documentation, all plans let owners and admins export data from public channels. Business+ extends that to public and private channels. Free and Pro workspaces can only export private channels and direct messages with valid legal process, member consent, or a legal requirement. Enterprise Grid exposes Discovery APIs that third-party archiving and eDiscovery tools consume.
Two operational consequences follow. A native export is a file you can read, not a restore into a live workspace. And retention settings affect what Slack itself can export, though third-party eDiscovery warehouses that already hold the data are unaffected by a later deletion in Slack. If your legal or compliance team needs defensible chat history, the answer is usually an archive or backup tool built on the Discovery API or a supported export pipeline, with its own retention schedule that you set deliberately rather than inherit.
Also check the free-plan edge case in your estate. Free workspaces can be configured to delete messages and files after 90 days or to keep them for a year. A forgotten free workspace used by a project team is a quiet source of data nobody realized they had lost.
Atlassian: a native backup tool with an explicit boundary
Atlassian offers a native Backup and Restore capability for Jira, Jira Service Management, and Confluence, with daily or weekly scheduled backups, reports, and audit logs. Its product page claims a full site restore in 12 hours or less, which is a vendor figure worth validating against your own data volumes rather than planning around. It covers most core entities, and Atlassian publishes a list of what is and is not included.
Read that list before you rely on it. The limiting factor is the boundary above: a restore from Atlassian’s backup is for disaster recovery of the site, and it is not a mechanism to undo individual destructive actions. For granular recovery, such as restoring one project’s issues to last Thursday’s state, teams generally turn to third-party backup vendors that capture issues, attachments, and configuration separately, or to disciplined use of manual exports (CSV or JSON for Jira, XML for Confluence spaces). Manual exports work for small instances and do not scale to automated, tested recovery.
A practical audit for this quarter
Treat the audit as a short list of questions applied to each platform, answered with evidence rather than assumptions.
- Inventory. Which SaaS platforms hold data your business cannot recreate? Include the ones adopted by a department without IT involvement.
- Native coverage. For each, what exactly does the vendor restore, from how far back, and at whose request? Write down the retention window in days.
- Granularity. Can you restore a single record, project, or channel, or only a whole site or org?
- Independence. Is the backup stored under credentials and a tenancy separate from the one an attacker would compromise? A backup in the same admin plane as the data fails the same way.
- Retention fit. Does the backup retention match your legal and compliance retention requirements, including deletion obligations?
- Proof. When was the last restore test, to where, and who signed off?
The cheapest finding of any audit is the platform with no owner. Assign one named person per platform, record the recovery objective, and schedule a restore test before the year closes. A documented gap with an owner and a date is a defensible position with auditors. An undocumented assumption that the vendor has it covered is not.