Backups an attacker with admin rights cannot delete
Immutable backups in an isolated recovery account, plus regular restore drills, so an attacker with admin access still cannot destroy your way back.
Overview
Most ransomware playbooks for cloud are simple: steal an admin credential, delete the snapshots, then encrypt or wipe the data. If your backups sit in the same account under the same identities as production, they go with it.
We move your backups behind a wall. Copies land in a separate recovery account with object lock or vault lock, under identities production cannot touch. Then we restore from them on a schedule, so you know the copies are complete and your team knows the steps.
Signs you need this
- Backups live in the same cloud account as production
- A single admin role can delete both data and every copy of it
- Nobody has restored a full database from backup in the last quarter
- Your backup policy covers databases but not object storage, secrets or cluster state
What you get
- Backup coverage audit
- A list of every data store, what is backed up, how often, where the copy lives and who can delete it.
- Isolated recovery account
- A separate account or subscription with its own access controls, receiving copies that production identities cannot change.
- Immutable backup policies
- AWS Backup Vault Lock, S3 Object Lock or Azure immutable storage set up with retention periods you have agreed.
- Restore automation
- Scripts or pipelines that rebuild a database, bucket or cluster from the recovery account into a clean environment.
- Restore drill programme
- A calendar of restore tests with pass criteria, and a record of the first drills run with your team.
How the work runs
- 1
Coverage audit
1 to 2 weeks
Inventory data stores, current backup jobs, retention settings and the identities that can delete them.
- 2
Isolation design
1 week
Design the recovery account, cross-account copy rules, encryption keys and break-glass access.
- 3
Implementation
2 to 4 weeks
Set up vaults, locks, copy jobs and alerting on backup failures, all in infrastructure code.
- 4
Restore drills
1 to 2 weeks
Restore real systems into a clean environment, check data integrity and record how long each restore took.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- Backup copies that a production admin account cannot delete, confirmed by trying it
- A full database restore into a clean environment that you have watched succeed
- Alerts that fire when a backup job fails or a data store has no backup
- A restore drill on the calendar with a named owner
Tools we work with
- AWS Backup
- AWS Backup Vault Lock
- Amazon S3 Object Lock
- AWS Organizations
- Azure Backup
- Azure immutable blob storage
- Velero
- Kasten K10
- pgBackRest
- Terraform
Questions buyers ask
- Will this affect production performance?
- Backup jobs use the provider's snapshot and copy features, which have little effect on running workloads. We schedule larger copies outside your busy hours.
- What access do you need?
- Administrator access in a new recovery account and a scoped role in your production accounts. Once the work is done, we hand over the recovery account's break-glass access to you and remove ours.
- Can we still delete data for GDPR or retention reasons?
- Yes. We set retention periods that match your legal duties, and copies expire on schedule once that period ends.
- Does this replace an incident response plan?
- No. It makes sure you have clean data to restore. We document how the restore fits into your wider incident process, but forensics and legal response are outside our scope.
Talk to us about backup and ransomware recovery engineering.
Tell us what you run and where. We reply within one business day with questions or a quote.