Often, yes. A SaaS vendor is responsible for keeping the service available. Getting back data that you or an attacker deleted is frequently on you, and the vendor's recovery window may be short or partial. Decide what matters, export it on a schedule, and test a restore.
Availability is not recovery
Vendors replicate data so their platform survives hardware failure. That protects against their problems. It does not protect you against an admin deleting a repository, a departing employee wiping a shared drive, a bad integration overwriting records, or a compromised account.
Read each vendor's documentation for what can be restored and for how long. Windows differ by product and plan, and they change, so check the current pages rather than assuming. For one concrete example, see the restore window for a deleted GitHub repository. The general model is covered in what you own under SaaS shared responsibility.
Rank what you would miss
For an engineering team, a short list usually covers it:
- Source repositories, including issues, pull request history and wikis if you rely on them.
- Identity provider configuration and group membership.
- Documents and runbooks you need during an outage.
- CI/CD configuration and pipeline definitions.
- Ticketing history tied to audits or customer commitments.
- Customer-facing data in tools such as support or billing systems.
Mark each as: rebuildable from code, exportable, or only in the vendor. The last group is the risk.
Backup methods
- Native export. Scheduled exports or API pulls. Cheap, but you must store and verify them.
- Mirror. For Git, a regular mirror clone to storage you control is simple and complete for code.
- Third-party backup. Adds convenience and another vendor to assess.
- Configuration as code. Store settings in version control so they are reproducible.
Whichever you choose, protect the copy. An export of your repositories is as sensitive as the originals, so encrypt it and limit access. Keep it in a separate account so one stolen credential cannot reach both, as with offline encrypted backups.
Test the restore
Pick one item per quarter and restore it into a scratch tenant or folder. Note what was missing: comments, permissions, attachments. Those gaps are your real recovery point.
Also keep a break-glass path for the day your identity provider is down, as in break-glass access when SSO is down.
Safeguard scans repositories and dependencies and can discover assets, which helps you list what you rely on. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Does the vendor's uptime promise cover my deleted data?
Not necessarily. Uptime concerns the service. Restoring deleted data depends on the product's recovery features and window, so read them.
What should I back up first?
Items that exist only in the vendor and that you cannot rebuild, usually source code history and identity configuration.
Last reviewed: 19 October 2026.
