FREE TOOLS / BACKUP POLICY

Backup policy generator

The question arrives as “please attach your backup and recovery policy” — in a SOC 2 readiness review, an enterprise security questionnaire, or due diligence. Answer it in sixty seconds: describe how your backups actually run, and get a complete, ten-section policy in Markdown — schedule, retention, encryption, restore testing, and derived RPO/RTO objectives. Nothing leaves your browser.

Names
Schedule & retention

Backup frequency sets your stated RPO (§7) — the document derives it automatically.

Storage & testing

Choosing “platform storage” or “none yet” writes an honest improvement note into the policy rather than papering over it — auditors respond better to a documented gap with a plan than to a claim that doesn't survive questions.

backup & recovery policy (markdown)
# Backup & Recovery Policy

**Organization:** Acme, Inc.
**Version:** 1.0 · **Effective:** 2026-06-12 · **Owner:** the CTO
**Review cycle:** annually, and after any material incident or architecture change

## 1. Purpose

This policy defines how Acme, Inc. backs up its production data, how those backups are protected, and how recovery is tested — so that data can be restored within defined, evidenced objectives following data loss, corruption, or infrastructure failure.

## 2. Scope

This policy covers the production Postgres database (Supabase), including all application data stored within it. Ephemeral data, caches, and assets reproducible from source control are out of scope.

## 3. Backup schedule and retention

- Automated backups run every hour. Backup execution does not require manual action.
- In addition to scheduled backups, a tagged checkpoint backup is taken immediately before schema migrations and other high-risk database changes, so that recovery from a failed change does not depend on the most recent scheduled backup.
- Backups are retained for 90 days, after which they are automatically deleted.
- Backup success and failure are monitored; failures generate alerts to the responsible personnel (see §7).

## 4. Encryption and access control

- Backup artifacts are encrypted with AES-256-GCM before leaving the backup worker, and remain encrypted at rest.
- Backups are transferred exclusively over encrypted (TLS) connections.
- Database credentials used by the backup system are stored encrypted and scoped to the minimum required privileges (read-only where supported).
- Access to backup storage and encryption keys is restricted to personnel with an operational need.

## 5. Storage and isolation

Backup artifacts are stored off-site in object storage owned and controlled by Acme, Inc. (separate from the platform hosting the database), so that no single account, platform, or region failure can destroy both the database and its backups.

## 6. Restore testing

Each restore test recovers a recent backup into an isolated environment and verifies the result (schema present, table and row counts in expected ranges). Restore tests are performed after every backup, automatically. Results, including time-to-restore, are recorded and retained as evidence.

## 7. Recovery objectives

| Objective | Target |
|---|---|
| Recovery Point Objective (RPO) | 1 hour of data loss, maximum |
| Recovery Time Objective (RTO) | 4 hours to restored service |

These objectives are validated by restore-test evidence rather than asserted. The CTO is responsible for reviewing objectives against actual measured restore times.

## 8. Roles and responsibilities

- **The CTO** owns this policy, reviews restore-test evidence, and approves exceptions.
- Personnel with access to backups are responsible for reporting suspected backup failures or gaps immediately.

## 9. Recovery procedure

On confirmed data loss or corruption: (1) identify the most recent verified backup preceding the incident; (2) restore into an isolated environment and validate; (3) restore affected data to production — selectively where possible, to preserve writes made after the incident; (4) record the incident, recovery time, and any data loss against the objectives in §7.

## 10. Exceptions and review

Exceptions to this policy must be documented and approved by the CTO. This policy is reviewed at least annually and updated when systems, providers, or objectives change.

---
*Template generated with the OffsiteDB backup policy generator (offsitedb.com/tools/backup-policy-generator). Adapt to your environment; this is a starting point, not legal or audit advice.*

What makes a backup policy survive an audit

FAQ

Do I actually need a written backup policy for SOC 2?
Yes. SOC 2's availability criteria expect documented backup and recovery procedures with defined objectives, and nearly every enterprise security questionnaire asks for the document outright. 'We have backups' without a policy and evidence reads as 'we think we have backups'.
What does a credible backup policy include?
Scope (which systems), schedule and retention, encryption and access control, where backups live relative to the systems they protect, how restores are tested, stated RPO/RTO objectives, who owns the policy, and a review cycle. The generator covers all ten sections.
What if my real setup has gaps — untested restores, on-platform storage?
Say so in the policy. The generator writes an explicit improvement note for those selections instead of papering over them. Auditors respond far better to a documented gap with a plan than to a confident claim that collapses under one follow-up question.
What evidence should back the policy up?
The two things auditors ask for next: proof backups actually ran (logs or a ledger), and proof a restore was tested (drill results with dates and timings). A policy plus monthly restore-drill reports answers the entire backup section of most audits.
Is this legal or audit advice?
No — it's a well-structured starting point. Adapt it to your actual environment, have it reviewed as part of your compliance process, and above all make sure the policy describes what you really do: the fastest way to fail an audit is a policy that doesn't match reality.

The policy is the easy half

The hard half is the evidence behind §6 and §7. OffsiteDB runs the schedule, encrypts to a bucket you own, restore-drills every snapshot, and emails the monthly report that makes this policy true. Start free — the policy you just generated describes it almost exactly.