SEC-01
Least-privilege access
Each integration gets the narrowest scope that lets the work function. Nothing more.
Stage 04 · RunBackup & recovery
A backup you have not restored is a hope
Backup jobs report success for years and then fail the one time it matters — the wrong data, an unusable format, or an encryption key nobody kept.
- Access stays in your accounts
- Every change on record
- Written, auditable deliverables
- C01Set RPO and RTO with the businessIn scope
- C02Back up the whole systemIn scope
- C03Separate and make immutableIn scope
- C04Restore on a scheduleIn scope
- C05Write the runbookIn scope
- C06Rehearse the whole failureIn scope
In short
Backup is the copy; recovery is the capability, and only one of them matters. The two numbers that define it are RPO — how much data you can afford to lose, which sets backup frequency — and RTO — how long you can afford to be down, which sets how recovery is architected. Neither is a technical decision; both are business decisions about acceptable loss. A backup that has never been restored into a working system should be treated as untested, because in practice that is what it is.
- 5
- Warning signals
- that say this is the work
- 6
- Controlled steps
- each ships something you keep
- 4
- Written refusals
- lines we do not cross
Self-audit
Signals this is the work
Tick the ones that are true where you are. Nothing is sent anywhere — the answer is for you, not for us.
If more than one of these is true today, the problem is usually further along than it looks from the outside. That is not a sales line; it is what the cost of waiting does.
Readiness checklistBackup & recovery
0 of 5 true
Nothing ticked yet.
How we do it
The sequence
Each step ships something you keep. You can stop after any of them and still be better off than when you started.
Start with step one- 01
Step 1 of 6
Set RPO and RTO with the business
Ask what an hour of lost data costs and what a day of downtime costs. The architecture follows from the answers rather than preceding them.
- 02
Step 2 of 6
Back up the whole system
Data, configuration, secrets, files and the infrastructure definition. A restore has to produce something that runs.
- 03
Step 3 of 6
Separate and make immutable
Different account, different region, write-once retention. Backups must survive the event that destroys production.
- 04
Step 4 of 6
Restore on a schedule
Into a real environment, timed against the RTO. This is the only evidence that any of it works.
- 05
Step 5 of 6
Write the runbook
Step by step, followable by someone who did not design it, under pressure, possibly at night.
- 06
Step 6 of 6
Rehearse the whole failure
Not just the database restore — the full path including DNS, certificates, integrations and the decision to declare an incident.
Assurance
Secured and auditable by default
These controls apply to every engagement, including this one. They are engineering decisions, not a certificate on a wall — and you can check each of them.
SEC-02
Credentials in your name
Accounts and keys live in your tenancy. You can revoke any of them without asking us.
SEC-03
Every change logged
Changes, deployments and incidents leave a written trail you can audit.
SEC-04
Restores tested, not assumed
A backup only counts once it has been restored. We test, and we report the result.
SEC-05
Separate environments
Development never touches production credentials or unmasked customer data.
SEC-06
A documented exit
Runbooks written as we go. Leaving means revoking our access — nothing is held back.
What we will not do
The refusals
The things we turn down are a better description of how we work than the things we sell.
Standing commitmentsBackup & recovery
- 01
We will not: Report backup success without a restore test behind it.
- 02
We will not: Set an RTO the architecture cannot meet, because it sounds reassuring.
- 03
We will not: Store backups where the same compromise reaches both copies.
- 04
We will not: Write a recovery plan nobody has ever executed.
Questions
Before you ask
Anything else, ask on the first call. There is no charge for working out whether this is the right fit.
Talk about a problemHow often should we test restores?
Quarterly for most businesses, monthly where data loss would be severe, and always after any significant architectural change. The test has to be a real restore into a working environment and timed — a restore that succeeds but takes eleven hours against a four-hour RTO has told you something important.
What is the difference between backup and disaster recovery?
Backup protects data. Disaster recovery restores the service — compute, network, DNS, certificates, integrations and the people doing it. Many organizations have solid backups and no recovery capability, and only discover the gap during the incident.
How do we protect against ransomware?
Immutable backups with write-once retention, in a separate account with separate credentials, plus enough retention depth that you can go back past the point of compromise. Modern ransomware targets backups deliberately, so the ability to reach and delete them is the vulnerability that matters.
What does good recovery cost?
It scales with how fast you need it. Restoring within a day from routine backups is inexpensive. Sub-hour recovery means warm standby infrastructure and costs considerably more. The right spend is whatever downtime actually costs you — which is why the RPO and RTO conversation comes first.
Tell us what isn’t working.
One process, one system, one decision you are stuck on. An engineer replies within one working day with how we would approach it, and whether it needs building at all.