Read the backup requirements in the ASD's Essential Eight maturity model and something stands out immediately. Only one of them is about taking backups. The rest are about who can reach them.
That ordering is not accidental. The maturity model's own threat description says that, depending on their intent, malicious actors may destroy data including backups — and at the next level, all data including backups accessible to an account with special privileges. A backup an attacker can reach with the credentials they already stole is not a recovery plan.
What the baseline actually requires
At Maturity Level One, regular backups — one of the eight strategies in the Essential Eight, alongside patching, multi-factor authentication and restricting administrative privileges — requires that:
- backups of data, applications and settings are performed and retained in accordance with business criticality and business continuity requirements
- backups are synchronised to enable restoration to a common point in time
- backups are retained in a secure and resilient manner
- restoration to a common point in time is tested as part of disaster recovery exercises
- unprivileged accounts cannot access backups belonging to other user accounts
- unprivileged accounts are prevented from modifying and deleting backups
The higher levels tighten the same theme rather than adding new backup routines. Maturity Level Two extends the access restriction to privileged accounts other than backup administrators. Maturity Level Three goes further again, so that unprivileged accounts cannot even access their own backups.
The pattern is consistent: separate the ability to work with data from the ability to destroy its copies.
"Restoration is tested" is the requirement, not "backups run"
The wording is worth reading closely. The requirement is that restoration is tested as part of disaster recovery exercises — not that backup jobs complete, and not that the console shows green.
Most practices have never tested a restore. Backups run, alerts stay quiet, and everyone assumes the two facts are connected. They frequently are not: the job succeeds while excluding a folder someone moved, the retention window silently shortened, the mailbox export never included shared mailboxes, or the encryption key lives only on the machine being restored.
Nothing about that is discoverable without restoring.
What to back up in a migration practice
"In accordance with business criticality" means you have to make the judgment. Four categories matter, and the last two are the ones that get missed.
Client files. Applications, agreements and variations, correspondence, records of oral communications, invoices and receipts, and the client's own documents. This is the material the Code requires you to keep for seven years after the last action on the file.
Financial records. The client-money ledger and the evidence supporting every movement in it.
Email. Still where a great deal of client correspondence lives, and frequently outside whatever backup regime covers the file server. A cloud mailbox is not backed up by the fact that it is in the cloud; retention policies and deleted-item recovery are not the same as a backup you control.
Configuration. The maturity model says data, applications and settings. In practice: user accounts and permissions, matter templates, document templates, integration configurations. A restore that recovers documents but loses the structure that made them findable has recovered an archive, not a practice.
The retention connection nobody makes
Backups sit at an awkward intersection of two obligations pointing in opposite directions, and it is worth naming.
The Code requires you to take all reasonable steps to ensure a client file is kept for seven years after the last action on it. If your only copy of a closed matter is a backup you have never restored from, you have not established that you can produce that file. Our guide to client file retention covers what the file has to contain.
At the same time, Australian Privacy Principle 11 expects personal information to be destroyed or de-identified once it is no longer needed and no law requires its retention. Backups are where that goes wrong quietly: a practice can delete a client's data from the live system and still hold it in twelve monthly snapshots nobody can selectively edit.
The practical answer is not to attempt surgical deletion inside backup sets. It is to set backup retention deliberately, so that copies age out on a schedule you chose, and to document that reasoning as part of the disposal process.
An exercise you can run in a morning
The ASD's small business guidance recommends regular backups and testing; here is a version scaled to a practice with no IT team.
- Pick a closed matter from two years ago. Not a recent one — recent files are usually still in every layer.
- Restore it to somewhere isolated, not over the live copy.
- Check it against the Code's list. Application, agreements and variations, written communications including electronic, records of oral communications, third-party communications, invoices and receipts, the client's documents, evidence of return of originals.
- Time it. How long from decision to usable file? That number is your real recovery objective, whatever the plan says.
- Restore one mailbox item and one configuration item. Both are where restores fail.
- Write down what did not work, and fix one thing.
- Record the date. The requirement is that restoration is tested; an undocumented test does not evidence anything.
The recovery test
- When did you last restore something, as opposed to check that a backup ran?
- Could a compromised staff account delete or encrypt the backups?
- Is email inside the backup regime, or assumed to be?
- Are settings and permissions backed up, or only documents?
- Is the encryption key or credential for the backups stored somewhere that survives losing the office?
- What is your actual recovery time for one matter, measured rather than estimated?
- How long do backups persist, and was that a decision?
The scenarios worth planning for
Ransomware gets the attention, and the maturity model's threat descriptions make clear why backup isolation matters most there. But three quieter scenarios cause more lost days in small practices:
- A departing staff member deletes or takes material, deliberately or otherwise.
- A vendor fails or is lost — an app is discontinued, an account is closed for non-payment, or a provider suffers its own incident. Data inside someone else's service is only as recoverable as your export.
- An accidental deletion discovered months later, past the retention window of the recycle bin everyone was relying on.
Where a system helps
The honest position is that a practice with client information spread across a laptop, a shared drive, three mailboxes and two cloud services does not have a backup problem. It has an inventory problem that presents as a backup problem.
Consolidation makes the question answerable. When matters, documents, correspondence and financial records live in one system, "what would we need to restore" has a single answer, the provider's backup regime is a thing you can ask about and verify, and an export is a control you can test rather than a project.
LodgeHQ keeps the whole matter in one place, which is what makes both recovery and retention testable. Our guide to moving off legacy tools covers the transition, and the Code compliance checklist covers the record-keeping duties behind it.
Verify before you rely on it
The Essential Eight maturity model is revised regularly and the requirements quoted here should be checked against the current version. If you use a cloud provider, confirm in writing what they back up, for how long, and what you would receive in an export — assumptions in this area are expensive.
This is general information for migration practices, not security advice tailored to your environment. Where continuity of a specific matter is critical, plan for it specifically rather than relying on a general regime.