Module 6 of StartCloud's Essential Eight for Australian Business learning pathway, in five short units with a knowledge check: what ASD's regular backups control actually asks for (data, software and settings, retained to suit business continuity, restoration tested, access restricted), why attackers deal with backups first and how ASD's Maturity Level Two and Level Three descriptions explain it, what a tested restore means to an assessor as opposed to a green tick in a dashboard, and why holding admin rights should not automatically grant access to the backups.
Backups You Can Actually Restore
The control nobody can bluff
Regular backups is the last of ASD's eight controls, and it is the odd one out. The other seven are about stopping bad things happening. This one exists for the day when all of that failed anyway, which is a humbling thing for a security framework to admit and the reason the framework is any good.
It is also the only control you cannot talk your way through. Patching can be described. Admin privileges can be summarised. Backups end with someone saying "show me", and either a file comes back or it does not.
Backups of the data, the software and the settings your business needs to keep running. Kept for as long as your continuity needs require. Restoration tested rather than assumed. And access to those backups restricted, so the people and accounts that can reach them are few and deliberate.
A backup product with a green tick, bought some years ago, never restored from. Data covered, settings and software not. Reachable by the same admin account that does everything else. Nobody has checked what is inside it since the day it was configured.
People hear "backups" and think documents. The control is broader on purpose. If a ransomware attack takes out your systems, restoring the files is only part of getting trading again. You also need the software and the configuration that made those files useful, the settings on the server, the way the line of business application was set up. Businesses that only backed up data find that out during the worst week of their year.
There is a reason this control talks about restricting access rather than just taking copies. Anyone serious about extorting a business knows that a working backup is the difference between a payday and a wasted fortnight. So the backups get dealt with first, before anything is encrypted or announced.
ASD's maturity model describes what attackers are doing at each level, and read in this light it stops being abstract and starts being a checklist for your own setup.
They destroy everything the compromised account could reach
ASD describes attackers at this level going after credentials with phishing, using technical and social engineering to get around weak multi-factor authentication. Once they hold a privileged account, they may destroy all data, including any backups that account can reach.
- The backup is not attacked directly, it is simply deleted by an account with permission
- Nothing has to be broken, because the rights were already there
- This is why the admin account that runs everything should not also control the backups
They go quiet, go wide, and clean up after themselves
ASD describes these attackers getting around stronger multi-factor authentication by stealing authentication token values, actively seeking privileged credentials and password hashes, moving from system to system across the network, and covering their tracks as they go.
- Time inside the network is the point, so damage can be prepared before it is triggered
- Covering tracks means you may not know how far back the problem goes
- Backups that cannot be changed after they are written matter enormously here
Backups accessible to a compromised privileged account can be destroyed along with everything else. Not hacked. Deleted, by an account that was allowed to delete them. If your backup lives behind the same login that runs the rest of your business, then in the scenario that matters most, you have one copy of your data wearing two hats.
When attackers spend weeks inside a network before triggering anything, a backup from last night may already be carrying the problem. Enough history to go back past the day things started is what makes recovery possible. How far back that needs to go is your call, based on how long your business could survive without its systems and how long a problem might plausibly go unnoticed.
"Tested" is the word doing the heavy lifting in this control, and it means something specific to an assessor. It does not mean the backup job completed. It means data came back out and somebody confirmed it was usable.
The distinction matters because backup software is very good at telling you it worked. What it cannot tell you is whether the right things were included, whether the restore process is understood by anyone still working there, or how long a real recovery would take on a bad morning with the phones ringing.
- Something was actually restored, not just reported as backed up
- It happened on a date somebody wrote down, with a name against it
- The restored thing was checked and found to be complete and usable
- The test covered a realistic case, not only the smallest file in the set
- It happens on a schedule, so the answer stays true rather than ageing
- A green tick in a dashboard, which only says the job ran
- An email report nobody has opened since the year it was set up
- "The vendor tests it", when nobody can say when or what
- A restore done four years ago on a system that has since been replaced
- A vague confidence that it will be fine on the day
The maturity model sets out how often restoration must be tested and how much of it must be covered, and the answer changes as you move up the levels. Rather than quoting a frequency here that may not match your situation, ask whoever is assessing you which level applies, then read the requirement for that level in the current model. What does not change at any level is the principle: somebody has to actually restore something.
The last piece of the control is the one people skip, and it is the one that decides whether your backup survives the attack it was bought for. Taking copies is the easy half. Making sure the wrong account cannot reach them is the half that matters.
Not to other people's backups, and not to the history of their own. If a regular account can browse and delete backup data, then any phishing email is a threat to your recovery as well as your files.
This is the part small businesses trip over. The person who administers your systems and the person who administers your backups can be the same human being, but they should not be the same account with one set of rights covering both.
Often sold as immutable or write once storage. The point is simple: even an account with rights cannot go back and change or remove what is already there, which is precisely the move an attacker needs to make.
Different system, different credentials, ideally a different physical place. If reaching your live systems also reaches your backups, then one bad day takes both, and that is the situation the whole control is written to prevent.
There is a specific trap for cloud-first businesses: assuming that because the data lives in Microsoft's data centres, it is backed up. Microsoft keeps the service running, you own the data inside it, and the recycle bins and retention windows are shorter than most people expect. Our Microsoft 365 backups and retention module goes through the real numbers and what a genuine third-party backup adds.
One closing thought. Of all eight controls, this is the one where the gap between "we have it" and "we could use it" is widest, and the gap only ever shows up on the worst possible day. Asking for a restore once a year is a small, slightly annoying task that turns a promise into a fact. Ask for one this month.
- cyber.gov.au: Essential Eight explained, Australian Signals Directorate
- cyber.gov.au: Essential Eight maturity model, including the regular backups requirements by level
Current at the time of writing (August 2026). ASD updates the maturity model regularly, and the specific testing frequency and access restrictions for each maturity level sit in its appendices, so read them there for the level you are being assessed against.
Knowledge check
5 quick questions. Get 4 right and the module is yours.
1. Why do attackers deal with backups before they encrypt or announce anything?
2. ASD describes Maturity Level Two attackers as able to destroy data 'including backups accessible to a compromised privileged account'. What does that tell you?
3. What does a 'tested restore' mean to an assessor?
4. Which of these best reflects the access restrictions in the regular backups control?
5. Beyond files and data, what else does the regular backups control expect you to be able to restore?