The off-site restorable backup your SOC 2 auditor asks for

The Compliance Trap Most Teams Fall Into

Here's a scenario that plays out constantly: a startup lands its first enterprise deal. The procurement team sends a 200-question security questionnaire. Question 47 asks: "Describe your backup and disaster recovery strategy, including off-site storage, encryption, and restore testing evidence."

The team has Supabase's built-in backups. They check the box. The auditor pushes back: platform-level backups protect the vendor's infrastructure, not your compliance posture. You need an off-site copy you control, encrypted at rest, with documented proof that you've tested a restore.

This is where most teams either spend weeks building custom backup scripts — or fail the audit.

Source: [Konfirmity — SOC 2 Backup And Recovery: A Practical Guide](https://www.konfirmity.com/blog/soc-2-backup-and-recovery-for-soc-2)

What the Frameworks Actually Require

SOC 2 — Common Criteria 7.3 (Availability)

SOC 2 maps backup and recovery to the Availability criteria (A1.2, A1.3) and Confidentiality (C1.1). Auditors look for three things:

1. 1Off-site backup storage — backups must reside in a different availability zone or region than production. Same-vendor, same-region doesn't count.
2. 2Encryption at rest — AES-256 is the expected standard. Unencrypted backup buckets are a critical failure.
3. 3Restore testing evidence — at least annually (ideally quarterly), with documented proof that a restore succeeded. Screenshots, logs, or ticket records.

Auditors will sample logs from random dates to verify backups ran automatically — manual backups performed "when someone remembers" result in a qualified opinion (a failure).

Source: [Konfirmity — SOC 2 Backup Requirements](https://www.konfirmity.com/blog/soc-2-backup-and-recovery-for-soc-2), [Kirkpatrick Price — SOC 2 Resources](https://kirkpatrickprice.com/audit/soc-2/resources/)

ISO 27001 — Annex A 8.13 (Information Backup)

ISO 27001's backup control (formerly A.12.3.1, renumbered to A.8.13 in the 2022 revision) requires:

1. 1Documented backup policy with defined schedules, retention timelines, and encryption rules.
2. 2Off-site storage — backup copies held at a separate location to survive site-level disasters.
3. 3Regular restore testing — bi-annual minimum, with documented results.
4. 4Encrypted backup files — all backup copies must be encrypted.
5. 5Vendor reports for off-site storage — if a third party stores your backups, you need their service reports as audit evidence.

Source: [271 — ISO 27001 Annex A 8.13 Explained](https://iso27001.com/iso-27001-annex-a-8-13-information-backup/), [ISMS.online — ISO 27001 Control 8.13](https://www.isms.online/iso-27001/annex-a-2022/8-13-information-backup-2022/)

GDPR — Article 32 (Security of Processing)

GDPR Article 32 requires controllers and processors to implement:

1. 1The ability to restore personal data in a timely manner after an incident.
2. 2Appropriate technical measures — encryption and pseudonymization are explicitly named.
3. 3A process for regularly testing, assessing, and evaluating the effectiveness of security measures.

Critically, every subprocessor that touches personal data must be added to your GDPR subprocessor list. Adding a new backup vendor means a new DPA, a new subprocessor disclosure, and a new vendor management review.

Source: [GDPR Info — Article 32](https://gdpr-info.eu/art-32-gdpr/), [EDPB — Data Controller or Processor](https://www.edpb.europa.eu/sme/learn-the-basics/data-controller-or-data-processor_en)

The 3-2-1 Rule: The Common Thread

All three frameworks converge on the same principle: the 3-2-1 backup rule.

• 3 copies of your data (production + 2 backups)
• 2 different media types (e.g., database storage + object storage)
• 1 copy off-site (different region or vendor)

The 3-2-1 rule exists because 96% of ransomware attacks now explicitly target backup repositories to force payment. If your only backup lives in the same cloud as your production database, one compromised credential wipes everything.

Source: [Veeam — 3-2-1 Backup Rule Explained](https://www.veeam.com/blog/321-backup-rule.html), [Cohesity — What Is the 3-2-1 Backup Rule?](https://www.cohesity.com/glossary/321-backup-rule/)

How Supakeep Satisfies 3 Frameworks:

  SOC 2 CC7.3          ISO 27001 A.8.13      GDPR Art. 32
  +----------+         +----------+         +----------+
  |Off-site  |         |Off-site  |         |Restore   |
  |backup    |         |storage   |         |in time   |
  +----------+         +----------+         +----------+
  |AES-256   |         |Encrypted |         |Encrypt   |
  |encrypt   |         |backup    |         |at rest   |
  +----------+         +----------+         +----------+
  |Restore   |         |Bi-annual |         |Test      |
  |evidence  |         |restore   |         |security  |
  +----------+         +----------+         +----------+
       \                    |                    /
        \                   |                   /
         +------------------+------------------+
                            |
                     +------------+
                     | Supakeep   |
                     | Zero-      |
                     | Retention  |
                     | Architecture|
                     +------------+
                            |
                     +------------+
                     | YOUR Google|
                     | Drive      |
                     +------------+
  No new subprocessor. No new vendor to vet. Your data, your storage.

Why Native Platform Backups Don't Close the Loop

Supabase, Firebase, and most managed databases offer built-in backups. These are valuable — but they don't satisfy compliance requirements on their own because:

1. 1Same-vendor, same-region — the backup lives in the same cloud account as production. No cross-vendor redundancy.
2. 2No documented restore testing — you get retention, not proof of restore.
3. 3No off-site copy you control — the backup is in the vendor's infrastructure, not yours.
4. 4No independent audit trail — you can't show an auditor your own backup run logs.

A compliance auditor wants to see that you've taken ownership of your own disaster recovery — not delegated it entirely to your database vendor.

Supakeep's Zero-Retention Architecture

This is where Supakeep's architecture directly addresses compliance requirements — and does it in a way that simplifies your vendor management instead of complicating it.

How It Works

Supakeep connects to your Supabase project and your own Google Drive account. It streams encrypted backup artifacts — database dumps, storage files, auth data, edge functions — directly into a folder in your Google Drive.

Supakeep never holds the bytes. The backup flows through Supakeep's infrastructure but lands in your storage, under your Google account, with your access controls.

Why This Matters for Compliance

SOC 2 CC7.3 (Off-site backup): Backups land in Google Drive — a different vendor and different infrastructure than Supabase. Cross-vendor redundancy satisfied.

ISO 27001 A.8.13 (Off-site storage): Google Drive is geographically separate from your Supabase region. Off-site requirement met.

GDPR Article 32 (Restore in timely manner): Daily automated backups with 20-second setup. Your backup is a .sql.gz file you can restore with a single psql command. See our restore guide.

GDPR (Subprocessor management): Because Supakeep never stores your data, it doesn't need to be added to your GDPR subprocessor list as a data processor. The data flows through Supakeep's infrastructure but is never persisted there. Zero retention means zero new data exposure surface.

SOC 2 (Vendor management review): No new vendor to add to your SOC 2 vendor management review. Supakeep is a conduit, not a data store. Your data lives in Supabase (production) and Google Drive (backup) — both vendors you've already vetted.

Mapping Supakeep to Compliance Requirements

The Audit Conversation

Here's how this plays out during an actual audit:

Auditor: "Show me your off-site backup strategy and restore testing evidence."

You: "We use Supakeep to automate daily Supabase backups to our own Google Drive. Here are the backup run logs showing successful daily executions. Here's a screenshot of a restore we performed from a backup file into a test Supabase project. Our retention policy is 30 daily backups, configured in the dashboard."

Auditor: "Is Supakeep a subprocessor that stores your data?"

You: "No. Supakeep uses a zero-retention architecture — backup artifacts are pushed directly into our Google Drive. Supakeep never persists our data."

That's the entire conversation. No custom scripts to maintain, no new vendor to vet, no subprocessor list to update.

AES-256 Encryption: How It Works in Practice

Google Drive encrypts all files at rest using AES-256 — the standard required by SOC 2, ISO 27001, and GDPR. When Supakeep uploads your Supabase backup to Google Drive, the file is encrypted by Google's infrastructure before it's written to disk.

During transit, Supakeep uses TLS 1.2+ to stream data from Supabase to Google Drive, ensuring encryption in transit (another SOC 2 requirement).

You don't need to manage your own encryption keys for the backup files — Google handles this as part of the Drive storage you already use and trust.

Source: [Kiteworks — AES-256 Encryption](https://www.kiteworks.com/secure-file-sharing/beyond-aes-256-encryption-multi-layer-protection/), [IDERA — AES-256-bit Encryption](https://www.idera.com/glossary/aes-256-bit-encryption/)

Documenting Your Restore Test for the Auditor

Supakeep makes restore testing straightforward. Here's the process that satisfies audit evidence requirements:

1. 1Download a .sql.gz backup file from your Google Drive.
2. 2Create a fresh Supabase project (don't restore to production).
3. 3Run the restore: gunzip db_2026-07-16.sql.gz && psql "postgresql://postgres:PASSWORD@HOST:5432/postgres" -f db_2026-07-16.sql
4. 4Verify row counts and key records.
5. 5Screenshot the results and attach to your audit evidence file.

For a full walkthrough, see our step-by-step restore guide.

Related reading: why every Supabase project needs its own backups and how to restore a Supabase project from a SQL backup.