AI SOP Template: Data Backup and Recovery

Backups are the work nobody wants to do until the moment they desperately need to have done it. AI does not magically protect your data, but it absolutely makes backup auditing, restore testing, and incident response faster and less error-prone. This SOP is what I deploy at small and mid-size companies that have outgrown ad-hoc backups but cannot justify a full DR engineer.

Why Backup and Recovery Needs a Documented AI SOP

Most small companies have backups that work the day they are set up and slowly rot from there. A drive fills up. A credential expires. An engineer leaves. Six months later, ransomware hits, and the "backup" is a stale snapshot from the prior fiscal year.

A documented SOP forces three things: explicit ownership, scheduled verification, and tested restores. AI compresses the verification and testing work so the SOP does not collapse under its own weight.

The Full SOP Template

This SOP assumes a small to mid-size company with cloud SaaS tools, a few production databases, and a code repository. Scale the principles up if you are larger.

Phase 1: Asset Inventory (one-time, then quarterly review)

1. List every system that holds business-critical data. Use this categorization:
   • Tier 1 (RPO 1 hour, RTO 4 hours): production databases, customer-facing apps, payment systems
   • Tier 2 (RPO 24 hours, RTO 24 hours): CRM, ERP, internal tools
   • Tier 3 (RPO 7 days, RTO 7 days): marketing tools, analytics, knowledge bases
2. For each system, document: data owner, where data lives, current backup mechanism, current RPO/RTO, gap from target.
3. Run the Inventory Audit Prompt in Claude or ChatGPT against the inventory:
   • "Review this asset inventory. For each row, identify: missing fields, RPO/RTO targets that seem too lax for the data type, and any system that lacks a backup mechanism. Output as a prioritized risk list."
4. Owner reviews AI flags, fixes the worst, schedules quarterly re-audit.

Phase 2: Backup Configuration (one-time per system)

1. Configure each system to back up via its native or vendor-recommended tool:
   • Postgres or MySQL: managed snapshots plus pg_dump or mysqldump to S3 with versioning
   • SaaS tools (HubSpot, Notion, Google Workspace): third-party backup like Rewind, AvePoint, or SaaS Protection
   • Code: GitHub plus a mirrored backup to GitLab or a private S3 bucket
   • File storage (Drive, Dropbox): vendor backup plus an independent copy
2. Apply the 3-2-1-1-0 rule (the 2026 standard, replacing legacy 3-2-1): 3 copies, 2 media types, 1 off-site, 1 immutable (e.g., S3 Object Lock, Backblaze B2 Object Lock, or write-once tape), 0 verification errors after every restore test.
3. Encrypt every backup at rest with a key managed in your KMS, not embedded in scripts.
4. Retention policy by tier: Tier 1 keeps 30 days hourly plus 12 months monthly, Tier 2 keeps 90 days, Tier 3 keeps 30 days.

Phase 3: Daily Verification (automated)

1. Each backup job emits structured logs to a central location (CloudWatch, Datadog, or a plain S3 bucket).
2. A scheduled job runs the Daily Verification Prompt against the prior 24 hours of logs:
   • "Review these backup job logs. For each system, return: did the backup run, was it successful, what was the size, and is the size within 20 percent of the rolling 30-day average. Flag any anomaly."
3. Output goes to a Slack channel and a status dashboard. Green, yellow, red per system.
4. Anything red triggers a page to the on-call engineer within 15 minutes.

Phase 4: Monthly Restore Drill (mandatory)

1. The on-call engineer picks one Tier 1 or Tier 2 system at random.
2. Restore the most recent backup to a non-production environment.
3. Run the Restore Validation Prompt:
   • "Given this restored database, run these N validation queries and confirm row counts, recent timestamps, and referential integrity. Flag any discrepancy compared to the production baseline provided."
4. Document time to restore, any issues encountered, and whether it met the RTO target.
5. If RTO was missed, the next sprint includes a remediation ticket. Non-negotiable.

Phase 5: Incident Response (when needed)

1. Declare incident in the standard incident channel.
2. Run the Incident Triage Prompt:
   • "Given this incident description and our asset inventory, list: which systems are likely affected, which backups should be considered for restore, what the data loss window is in the worst case, and what the safe order of restore is given dependencies."
3. Lead engineer reviews the AI triage, makes the restore decision, executes from the runbook.
4. AI generates a real-time incident timeline from Slack and PagerDuty events for the postmortem.

Phase 6: Postmortem and SOP Update (within 7 days of any incident)

1. Run the Postmortem Draft Prompt against the incident timeline.
2. Lead engineer rewrites the draft as a blameless postmortem.
3. Action items go into the next sprint with deadlines.
4. SOP itself is updated within 7 days. The version number bumps. The change log records what changed and why.

Tools You'll Use (Verified May 2026)

• Enterprise backup platforms: Veeam (software-defined, lower TCO, Secure Restore with sandbox scanning), Rubrik (appliance-based, $10M ransomware recovery warranty on Enterprise Edition, strong threat hunting), Cohesity (Instant Mass Restore from SpanFS, mounts hundreds of VMs in parallel), or Druva (cloud-native on AWS with Dru Assist and Dru Investigate AI agents). Gartner's 2026 Magic Quadrant lists Rubrik, Veeam, Commvault, Cohesity, Dell, and Druva as leaders.
• Backup execution for self-built stacks: native cloud snapshots (RDS, S3 versioning), Velero for Kubernetes, Restic or Borg for servers, Rewind or AvePoint Cloud Backup for SaaS (Microsoft 365, Salesforce, HubSpot, Notion).
• Storage: S3 with Object Lock, Backblaze B2 with Object Lock, or Wasabi. Always at least one geographically separate region.
• Orchestration and verification: n8n, GitHub Actions, or AWS Step Functions to run scheduled checks.
• Log aggregation: Datadog, Better Stack, or self-hosted Grafana Loki.
• LLM: Claude or GPT-class for log analysis. Self-hosted (e.g., Llama 3 or Mistral via Ollama) if logs contain customer data.
• Status communication: Statuspage or a simple internal dashboard with green/yellow/red.
• Framework reference: NIST Cybersecurity Framework 2.0 (CSF 2.0). The Recover function now has two categories — Incident Recovery Plan Execution and Incident Recovery Communication — and a new resilience-of-technology-infrastructure subcategory was added in the 2026 update cycle.

Sample Prompts You Can Steal

Daily Verification: "Below are JSON-formatted backup job logs from the last 24 hours. For each unique system_id, output a row with: system_id, status (success/fail/missing), backup_size_bytes, deviation_from_30d_avg (percentage), and any error messages. Flag systems with deviation greater than 20 percent or missing logs entirely. Format as a markdown table."

Restore Validation: "You are validating a restored Postgres database against expected post-restore state. Run the queries below and compare results to the expected_results JSON. Output: query_id, actual, expected, match (true/false), and a one-line explanation for any mismatch. Do not infer success from query execution alone — only from result comparison."

Incident Triage: "Incident description: [paste]. Asset inventory: [paste]. Backup status as of last 24h: [paste]. Output: list of likely affected systems with rationale, recommended restore order respecting dependencies, estimated data loss window per system in worst case, and any system where backup status is questionable and needs manual verification before restore."

Quarterly SOP Audit: "Review this backup SOP against NIST CSF 2.0 Recover function (RC.RP and RC.CO categories) and SOC 2 Type II Common Criteria CC9.1 (data backup and recovery). Identify: gaps in the SOP, mappings between our controls and NIST CSF 2.0 subcategories (especially RC.RP-03 backup integrity verification), recent industry incidents that suggest new failure modes, and 3 specific improvements ranked by risk reduction."

Roles and Responsibilities

• Data Protection Owner (a named individual): accountable for the entire SOP. Reviews quarterly. Reports to leadership.
• On-Call Engineer (rotating): handles daily verification alerts and runs the monthly restore drill.
• System Owners (per system): define RPO/RTO, validate restores in their domain.
• Security Lead: signs off on encryption, key management, and immutability configuration.
• Compliance Lead (if applicable): ensures the SOP meets regulatory requirements (SOC 2, HIPAA, GDPR, etc.).
• AI Steward: maintains prompt library, validates that AI-driven log analysis is not creating false positives or false negatives.

Common Pitfalls

1. Backups exist, restores never tested. This is the universal failure mode. Schedule the drill, do the drill, document the drill.
2. One person knows the backup system. When that person leaves, you are exposed. Cross-train, document, version everything.
3. Backups stored in the same account or region as production. A compromised admin credential can delete both. Use separate accounts and immutable storage.
4. No RPO/RTO targets. Without targets, you cannot tell if the SOP is succeeding. Define them per tier and put them in writing.
5. AI false confidence. An LLM saying "all backups look fine" based on log summaries is not the same as a successful test restore. Trust the test, not the summary.

Governance and Data Handling

• Backup data is treated with the same sensitivity as production data. Same access controls, same encryption, same audit logging.
• Access to backup storage is least-privilege. Even admins should not have routine delete permissions on immutable backups.
• Encryption keys are rotated annually and stored in a KMS, never in scripts or environment files committed to a repo.
• All restore drills, incidents, and SOP updates are logged in an immutable audit log for compliance.
• AI prompt outputs that contain customer data inherit production data classification. They are not free to share or store casually.

Measuring Whether the SOP Is Working

Track these monthly and review quarterly:

• Backup success rate per system (target 99.5 percent)
• RPO actual vs target per tier
• RTO actual vs target (measured in monthly drills)
• Time from incident declared to restore completed
• Number of "near miss" findings from AI verification per month
• Audit findings closed within 30 days

A healthy program rarely has incidents and consistently passes restore drills under target. A program in trouble shows green dashboards and missed RTOs in the one drill that gets run.

FAQ

Backup and recovery is unsexy work that determines whether your company exists in 12 months if something goes badly wrong. AI cannot do this work for you, but it can keep the SOP alive between the moments when nobody wants to think about it. Run the SOP, test the restores, and you buy yourself the right to focus on growth without a knot in your stomach.