Backup, continuity, and recovery for startups: from 3-2-1 to a lean continuity plan

Why continuity is an architecture decision at a startup

In a startup or fintech, data is the product: customer records, transaction ledgers, models, integrations with acquirers and banks. The loss or unavailability of this data isn't an isolated IT incident, it's a direct interruption of revenue and, in a regulated environment, a problem of compliance and partner trust.

The common mistake is treating backup as an infrastructure task delegated to the cloud provider. Automatic snapshots and cross-zone replication protect against hardware failure, but not against accidental deletion, logical corruption, credential compromise, or ransomware that encrypts precisely the volumes and their snapshots. Resilience requires deliberate decisions about where, how, and with what isolation the copies live.

NIST SP 800-34 (Contingency Planning) and ISO 22301 (Business Continuity) organize this reasoning around an impact analysis: identifying critical processes, how long the company can tolerate being without them, and how much data it can lose. For a startup, this doesn't need to become a months-long project; it needs to become a one-page document that guides the next architecture choices.

The 3-2-1 rule and its modern variations

The recognized baseline (present in the CIS Controls, the Data Recovery control) is 3-2-1: keep three copies of your data, on two distinct types of media or technology, with at least one copy outside the primary environment. Production counts as one copy; that means at least two additional backups, and never all in the same provider, same account, or same region.

The 3-2-1-1-0 variations harden the rule for the ransomware era: the extra first '1' requires an immutable or offline (air-gapped) copy, and the '0' requires zero errors in backup verification. For a cloud startup, this translates to using object lock on object storage, a separate account or tenant for backups, and automated integrity checks after each job.

Separate the identity plane as well: if the same credential that administers production can also delete or alter the backups, you have a copy, not a backup. Use dedicated accounts, with least privilege and MFA, and keep long-retention copies out of reach of day-to-day operations.

If during this design you realize there's no one to monitor unauthorized access attempts to the backups or to respond when an alert fires, that's exactly the kind of gap Decripte covers. Our continuous monitoring and incident response work as an external security team for startups that don't yet have their own SOC, and there's a free plan to start building visibility before you need it in a crisis.

RTO and RPO: measuring what continuity means

RTO (Recovery Time Objective) is how long a system can be unavailable before the impact becomes unacceptable. RPO (Recovery Point Objective) is how much data, measured in time, the company accepts losing — that is, the maximum distance between the last valid backup and the moment of failure. These two numbers, defined per system, are what separate planned continuity from improvisation.

The values aren't uniform. A fintech's transaction ledger may require an RPO of minutes and an RTO of a few hours, justifying continuous replication and frequent backups. An analytical data warehouse, on the other hand, may tolerate an RPO of 24 hours and an RTO of a full day. Setting everything to the most aggressive tier is expensive and unnecessary; setting everything to the loosest is risky.

The RPO directly governs backup frequency: if the RPO is one hour, daily backups won't cut it. The RTO governs the recovery architecture: short targets call for pre-warmed environments or infrastructure-as-code ready to recreate everything quickly. Document these targets alongside each critical system and revisit them when the architecture changes.

Immutable and offline backups against ransomware

Modern ransomware targets backups before encrypting production, because an intact backup neutralizes the extortion. That's why the decisive property of a copy isn't its frequency, it's the impossibility of being altered by whoever compromised the environment. Immutability and isolation are what keep a copy trustworthy during an attack.

WORM (write once, read many) immutability on object storage, via object lock in compliance mode, prevents even a compromised administrator from deleting or overwriting the data during the retention period. It's the most practical mechanism for cloud startups, since it requires no dedicated hardware and integrates with existing pipelines.

Offline or air-gapped isolation, logical or physical, complements immutability: a copy that's only accessible through a separate channel, with distinct credentials, and that stays disconnected from the operational network most of the time. Combine long immutable retention with periodic offline copies for the most critical data, and keep at least one set of backups outside the cloud or the account where production runs.

Restore testing: the backup no one restored doesn't exist

The costliest failure in continuity isn't lacking a backup, it's discovering at incident time that the backup is corrupted, incomplete, or that no one knows how to restore it within the promised RTO. NIST SP 800-34 treats testing the plan as inseparable from it; a backup never restored is a hypothesis, not a guarantee.

Test the restore regularly and in an isolated environment, not in production. Restore a full database, bring the application up against it, validate referential integrity, and time the process end to end. The measured time is your real RTO; if it exceeds the target, adjust the architecture or the goal before reality adjusts it for you.

Document every test: what was restored, how long it took, what failed, and what has changed since. This trail becomes compliance evidence and, more importantly, the runbook the team will follow under pressure. Include adverse scenarios in the test, such as restoring from the immutable copy assuming the production account is compromised.

A lean continuity plan (BCP/DRP) for teams with few people

A BCP (Business Continuity Plan) describes how the business keeps operating during a disruption; a DRP (Disaster Recovery Plan) details how the technology comes back online. For a startup, both should be short and executable: a few pages that answer who decides, who executes, in what order systems come back, and who to communicate with, including customers and regulators when applicable.

Structure it around concrete scenarios, not theory: loss of the primary cloud region, credential compromise, accidental database deletion, ransomware. For each one, record the recovery steps, the target RTO/RPO, the owners, and the escalation contacts, including the external incident-response partner. Keep a copy of the plan outside the systems it protects.

ISO 22301 treats continuity as a cycle: plan, exercise, review, and improve. For a startup, this means reviewing the plan on every relevant architecture change and exercising it at least with a tabletop simulation per period. A lean plan that is read, tested, and updated beats, in every real scenario, the lengthy manual no one has opened since the audit.

Practical checklist

1. 1

   1. Inventory data and define criticality

   List the systems and datasets, flag those critical to revenue and compliance, and record where they live. Without an inventory, any backup strategy has blind spots.

2. 2

   2. Define RTO and RPO per system

   For each critical system, determine the maximum tolerable downtime (RTO) and the maximum acceptable data loss (RPO). These numbers drive backup frequency and recovery architecture.

3. 3

   3. Implement 3-2-1 with isolation

   Ensure three copies, two media, one off-site, always in an account or provider separate from production, and with dedicated credentials and MFA to access the backups.

4. 4

   4. Add an immutable or offline copy

   Enable WORM object lock on the backup storage and keep at least one air-gapped copy of the most critical data, beyond the reach of operational credentials.

5. 5

   5. Automate integrity verification

   Configure automatic checks after each backup job and alerts for failures. A backup that fails silently is worse than none, because it creates false confidence.

6. 6

   6. Test and time the restore

   Restore periodically in an isolated environment, validate integrity, and measure total time. Compare against the target RTO and adjust the architecture or goal based on the real result.

7. 7

   7. Document and exercise the BCP/DRP

   Write a short plan with roles, recovery order, and escalation contacts, keep a copy outside the systems it protects, and exercise it with periodic simulations.

Frequently asked questions