When South Australian Government agencies and councils buy ICT systems, backup and disaster recovery (DR) are no longer a footnote in the security schedule. Ransomware, accidental deletion and regional outages have made recovery objectives a procurement topic in their own right. This guide explains what buyers should require in tenders — recovery time and point objectives (RTO/RPO), immutable and offline copies, restore testing, Australian residency for backups, ransomware considerations and evidence artefacts — and what Adelaide SME suppliers should prepare. It is practical guidance for buyers and suppliers, not legal or insurance advice. Always follow the standards and schedules named in the tender documents.
Why backup and DR sit on the evaluation sheet
Public sector buyers are accountable for continuity of citizen and staff services. A system that cannot be restored to an agreed point in time is a business continuity failure, not only a technical one. Tender questionnaires and panel RFQs commonly ask suppliers to describe:
- How often data is backed up, and how long copies are retained
- Whether backups are offline, immutable or otherwise protected from the same attack that hits production
- Recovery time objective (RTO) and recovery point objective (RPO) for critical services
- Where backup and DR copies are stored (including Australian residency)
- When restores were last tested, and what was proven
These questions sit alongside Essential Eight “regular backups”, agency ISMF processes and Privacy Act security expectations. See our guides to the Essential Eight for SA SMEs, Australian data residency and the SA ISMF for ICT suppliers.
RTO and RPO in plain English
RPO (recovery point objective) is how much data you can afford to lose, measured backwards from the moment of failure. An RPO of four hours means backups (or continuous replication) must be recent enough that you lose no more than about four hours of work.
RTO (recovery time objective) is how long the service can stay unavailable after a failure before the business impact is unacceptable. An RTO of eight hours means restore, reconfiguration and smoke tests must fit inside that window.
| Service class (example) | Typical buyer questions | What a credible answer looks like |
|---|---|---|
| Critical citizen-facing | Can we restore same day? How much data loss is acceptable? | Named RTO/RPO, automated backups, tested restore path, on-call runbook |
| Internal line of business | Is next-business-day recovery enough? | Daily backups, documented restore steps, quarterly restore test evidence |
| Archive / low change | Can we rebuild from longer retention? | Longer RPO, clear retention and legal-hold rules, still a tested restore |
Buyers should set RTO/RPO per service class, not one number for the whole estate. Suppliers should never invent figures they cannot meet under load; a slightly longer, evidenced RTO scores better than an aggressive claim that fails in clarification.
What buyers should require in tenders
Write requirements that are specific and testable:
- Named RTO and RPO for each critical system or tier, with the measurement window defined (for example “from declared disaster to service usable by named user roles”)
- Backup frequency and retention matched to the RPO, including how long daily/weekly/monthly copies are kept
- Immutable or offline copies that ransomware or a compromised admin account cannot quietly delete (for example object-lock, air-gapped or write-once media, or a separate account/subscription)
- Australian residency for backups and DR replicas, with any exception listed and justified (see data residency guidance)
- Restore testing on a stated cadence (for example quarterly for critical systems), with a short evidence note: what was restored, to where, how long it took, and what failed
- Ransomware assumptions: treat production and primary backup credentials as potentially compromised; require a recovery path that does not depend on the same identity store alone
- Evidence artefacts at bid and at acceptance: backup configuration summary, last restore test record, data-flow diagram showing backup destinations, and incident/recovery contacts
- Exit and handover: how the agency gets backup credentials, runbooks and a final export if the contract ends
For broader tender design, see winning SA Government ICT work and our capability statement.
Immutable, offline and “3-2-1” without the slogans
Evaluators have heard “3-2-1 backups” before. What they need is the design behind the slogan:
- Multiple copies so one failure does not erase history
- Different media or systems so a single storage fault is not fatal
- One copy offline or immutable so malware that encrypts production cannot also wipe the only remaining restore point
On AWS and Azure this often means versioned object storage with object lock or immutability policies, cross-account or cross-subscription backup vaults, and carefully separated privileged identities. Confirm that logs, encryption keys and identity backups are in the recovery story — restoring a database without the keys or IdP configuration is not a recovery.
Australian residency for backups
Primary data in Sydney or Australia East with DR or backup copies in an overseas region is a residency and often a Privacy Act issue. Ask explicitly:
- Which Australian regions host production, backups and DR replicas?
- Do any backup agents, SaaS backup tools or support staff pull data offshore?
- Where do encryption keys for backup vaults live?
Residency alone does not equal recoverability. A same-region backup that shares credentials with production can still be lost to ransomware. Design for both location and access separation.
When cloud costs come under pressure, backups and DR are tempting targets. Take savings from idle compute, orphaned storage and log noise first, and keep retention and restore testing matched to the agreed RTO and RPO (see cloud cost control without cutting corners).
Ransomware and recovery assumptions
Modern ransomware targets backups. Credible designs assume:
- Attackers may obtain privileged credentials in the production tenancy
- Soft-delete without immutability is not enough
- Recovery may need a clean identity path and out-of-band communications
- Legal, privacy and cyber-insurance notification clocks start when the incident is declared — keep contact lists current
Essential Eight “regular backups” at Maturity Level 1 already expects offline or immutable copies and tested restores. Higher maturity tightens cadence and coverage. Map your tender answers to that language rather than inventing a proprietary maturity claim.
Evidence artefacts buyers can score
| Artefact | Why it helps evaluators |
|---|---|
| Backup and DR design note (1–2 pages) | Shows RTO/RPO, destinations, immutability and residency in one place |
| Data-flow diagram | Makes backup and DR paths visible alongside production |
| Restore test record | Date, scope, duration, outcome, defects and owner |
| Runbook excerpt | Who declares a disaster, who restores, how users are told |
| Subprocessor / tool list | Named backup SaaS, regions and access model |
| Insurance certificates | Cyber and professional indemnity where the tender asks |
Be honest about gaps. A dated uplift plan with interim compensating controls scores better than a claim you cannot demonstrate in a clarification workshop.
What Adelaide SME suppliers should prepare
- A reusable one-page backup/DR statement for your corporate environment and a template for client solutions
- Documented restore tests (even a small quarterly restore of a non-production dataset is better than none)
- Clear separation between “how we protect EITSAA/our firm” and “what we will design into your system”
- Australian region defaults for AWS and Azure, with Melbourne/Australia Southeast (or the named secondary region) considered for DR where the RTO needs it
- Alignment between security schedule answers, pricing (DR drills cost money) and the delivery plan
- Partnership options if a tender needs specialist cyber forensics or 24×7 SOC beyond your scope — say so plainly
If you need help operationalising backups, monitoring and Essential Eight uplift after award, see our managed IT and cyber security and DevOps and cloud services.
A practical checklist for the next RFT or RFQ
- Classify systems and set RTO/RPO per class before you write the schedule
- Require immutable or offline copies and say what “immutable” means in your environment
- Name Australian regions for production, backup and DR
- Require restore-test evidence at acceptance and on a stated operating cadence
- Ask how recovery works if privileged production identities are compromised
- Score artefacts, not adjectives
- Budget for the first restore test and a DR exercise in the first year of operations
This article summarises commonly seen SA procurement and cyber practice as at late 2026. Framework versions, cloud features and agency policies change — verify the current Essential Eight Maturity Model, ISMF guidance and the tender documents before you lock requirements or claim conformance.
Talk to an Adelaide team
If you are scoping backup, DR or secure cloud operations for an SA agency or council, or preparing a security schedule response, discuss your project with our team or call 0402 401 584. We reply within one business day.