Backup is bought on capacity and judged on recovery. That gap is where most of the disappointment in this category lives. A platform can hold every byte an organisation has produced and still fail the only test that counts, which is bringing a named system back inside the time the business assumed it would take.
This page covers what to specify when buying backup and recovery, what evidence separates vendors who can restore from vendors who can store, and how the commercials usually surprise people. It is written for Australian organisations that report against the ASD Essential Eight or carry obligations under APRA CPS 230.
Recovery time is the requirement, not backup window
Ask a vendor how long a full restore of your largest production database takes, with your data volume, over your network, to your target infrastructure. The answer is frequently longer than the recovery time objective sitting in a business continuity plan that nobody has revisited since it was written.
Do this per system class rather than for the estate as a whole. A file share and a transactional database have different tolerances and different restore mechanics, and an average across them hides the systems that will actually cause the incident to escalate. Requirements written as one global recovery time objective are the single most common defect in this category.
What immutability means when you are buying it
Every vendor in this market now uses the word immutable. It carries at least three different meanings commercially. It may mean object-lock storage where retention cannot be shortened by anyone, including an administrator with full rights. It may mean a software flag the vendor’s own platform enforces, which an attacker with platform credentials can clear. It may mean append-only media.
The question that separates these is simple: who, if anyone, can shorten retention before it expires, and what would it take. Ask for the answer in writing, and ask whether it changes when the platform is administered by the vendor rather than by you.
Ransomware changed what you are buying against
Traditional backup design assumed the threat was hardware failure, accidental deletion or a site event. All three are indiscriminate and none of them look for the backups first. Ransomware operators do, because encrypted backups convert a recoverable incident into a payment negotiation.
That changes the specification in a particular way. The backup control plane needs to be isolated from the production identity domain, so that compromising a domain administrator does not also grant control of the backup platform. If backup administration authenticates against the same directory as everything else, the platform inherits the blast radius of that directory. This is the same argument that applies to privileged access management, and the two decisions are worth making together.
The capabilities to specify separately
Recovery objectives per system class
Group systems into three or four tiers, set a recovery point and recovery time objective for each, and make vendors respond against those tiers. Vendors will otherwise answer against their strongest scenario.
Immutability and retention lock
Specify who can shorten retention, under what authority, and whether that action is alerted. Specify the retention period separately for operational recovery and for any regulatory hold.
Isolation of the backup control plane
Separate credentials, separate directory where practical, multi-party approval for destructive operations, and alerting on retention or policy changes rather than only on job failures.
Restore testing and evidence
Automated restore verification, and a report you can hand to an auditor. Ask whether verification is a checksum, a mountable image, or a genuine application-level start. Those are very different assurances sold under similar language.
Egress, repatriation and exit
If backups sit in the vendor’s cloud, establish the cost and the elapsed time to get every byte back out, and whether that changes if the contract has terminated. Exit terms are cheap to negotiate at signature and expensive afterwards.
What Australian obligations expect
Regular backups is one of the eight mitigation strategies in the ASD Essential Eight. The maturity model is specific in a way that helps requirements writing: it addresses backup frequency aligned to business continuity requirements, retention, and, at higher maturity levels, restricting the ability of privileged accounts to modify or delete backups. If you report against a maturity level, quote that wording directly into your requirements.
For APRA-regulated entities, CPS 230 frames this as operational resilience rather than as a backup control: entities must be able to continue critical operations within tolerance levels they have set themselves. That reframes the buying question from how much data is protected to how quickly a named critical operation resumes. Our CPS 230 due diligence hub covers the supplier side of that obligation.
Where the platform is delivered as a service, the provider becomes part of your recovery path, which makes their own resilience a due diligence question rather than a technical footnote. That belongs with your other vendor and supplier risk management work.
How backup vendors price, and what gets missed
Common bases are per front-end terabyte of protected data, per back-end terabyte after deduplication, per protected workload, and per socket or host. Deduplication ratios are the wild card: a quote built on an assumed ratio will move materially if your real data does not deduplicate the way the model assumed. Ask for the assumed ratio in writing and ask what happens commercially if it is wrong.
The costs most often absent from the first quote are cloud storage tiering and retrieval, egress during a large restore, extra capacity for immutable copies that cannot be aged out early, and the infrastructure needed to actually meet the recovery time objective rather than merely hold the data.
Evidence to request before shortlisting
- A restore time estimate for your largest system, at your volume, on your infrastructure, in writing.
- The immutability mechanism, described precisely enough to identify who can shorten retention.
- A sample restore verification report of the kind an auditor would accept.
- The assumed deduplication ratio behind the price, and the commercial consequence if it is not achieved.
- Exit and repatriation terms, including egress cost and elapsed time after termination.
- Australian reference customers who have performed a large restore as well as a backup rollout.
A defensible evaluation sequence
Write the tiers and recovery objectives first, from the Essential Eight wording and your own continuity requirements, and weight them before any pricing is visible. Then test rather than demonstrate: a proof of value should restore one real system from each tier, timed, on your infrastructure.
Record the reasoning behind the decision while the evidence is in front of you. In this category the decision record has a second use beyond procurement governance, because it is also the document that explains, after an incident, why the recovery capability was scoped the way it was. The guided vendor evaluation process and the Discover, Evaluate, Engage, Assure method produce that record as part of the work.
If an incident is the scenario you are buying against, read this alongside incident response and recovery services, because the two capabilities are exercised at the same moment and are frequently bought by different people.
Sources
- Essential Eight Maturity Model, Australian Signals Directorate.
- Essential Eight Explained, Australian Signals Directorate.
- CPS 230 Operational Risk Management, Australian Prudential Regulation Authority.
- Cybersecurity Framework, National Institute of Standards and Technology.
Where to read more
See Essential Eight procurement and provider evaluation for the wider control set, the enhanced CIRMP rules if you operate critical infrastructure, and cloud security and compliance where backups sit with a hyperscaler.
Also relevant: energy and critical infrastructure technology procurement.
