How Do You Know Your Backups Would Actually Restore?

You know your backups would restore when somebody has already restored from them: to a single point in time, with a person checking the result actually worked, and the date written down afterwards. That is the whole test, and it is the bar the Australian Signals Directorate (ASD) sets. Restoration of data, applications and settings from backups to a common point in time is tested as part of disaster recovery exercises appears word for word at all three Essential Eight maturity levels, not just the top one.

If nobody in your business can name the date of the last restore, that is not a failure of attention. Backups are the one control that reports success every day while proving nothing, and the monthly report has a green tick next to them because the job ran. That tick is the most trusted line on the report and the least examined, and it looks the same from inside the 1,500-plus Cyber Strength Audits inSUPPORT has run for Australian businesses.

The reality is that restores fail for reasons a job log has no way to show. The data came back but the application will not start without a licence key nobody kept. Three systems restored to three different afternoons, so the records no longer agree. The backup of the file server was fine and the backup of the database that made it useful was never configured. And then the harder one: ASD's description of the attacker at Maturity Level One, the first level that describes an adversary rather than a gap, notes that depending on their intent, malicious actors may also destroy data, including backups.

So below is the tested backup restore itself, written as checks rather than theory. Nine of them in two groups: five that tell you whether a restore works, and four that tell you whether the backup would still be there after the attack that made you need it. Then four questions to put to whoever runs your IT this week, and the two places the same untested backup fails you.

TL;DR: What to remember

• ✅ A backup job log proves the software ran. A restore proves the business comes back. Only one of those is evidence.
• ✅ Nine checks in two groups: five on whether the restore works, four on whether the backup survives the same attack.
• ✅ ASD requires restoration to a common point in time to be tested as part of disaster recovery exercises at every Essential Eight maturity level, and its assessment guidance puts the floor at least annually. Annually is the floor, not the schedule: you set the interval above it and keep the record.
• ✅ An untested backup fails twice: once against the framework, and again on the day an insurer asks for evidence instead of intention.

Contents

• What a tested restore actually looks like
• Would the backup survive the same attack?
• Four questions to put to your provider this week
• Why an untested backup fails twice
• Backups and restores: the questions people actually ask

What a tested restore actually looks like

A backup job reports on itself. It tells you the software started, read what it was pointed at and finished without an error it recognised. A restore tells you something different and much more useful: that the thing you backed up can be put back in a usable state by the people who would have to do it, in the conditions they would have to do it in. The gap between those two statements is where most recovery plans quietly live.

Run the five checks below against your last tested backup restore. Each one is either true or it is not, and the honest answer to several of them is often "I would have to ask", which is itself the finding.

1. Something real came back, not a green tick

The test has to end with a restored thing a person opened. A database an application connects to, a server that boots and lets somebody log in, a file share the finance team can work from. Reading a successful job log is monitoring, not testing, and the two get conflated constantly because one of them takes four seconds and the other takes an afternoon.

ASD's assessment guidance draws a harder line here than most people expect, and it is the sentence worth carrying into your next conversation about this: business-as-usual recovery of user files is not sufficient for the control, and the intent is the restoration of a significant component of a system as part of a scheduled exercise. Pulling back the spreadsheet somebody deleted on Tuesday is a helpdesk ticket. It is not a restore test, and a year of those tickets does not add up to one.

2. It came back to one point in time

ASD's wording is precise on this and worth borrowing: backups of data, applications and settings are synchronised to enable restoration to a common point in time. Systems that depend on each other have to come back agreeing with each other. A database restored to Tuesday morning and an application restored to Sunday night will both report success and will not reconcile, and you find that out during the recovery rather than during a test.

This is also the check that catches settings. Data usually gets backed up. The configuration that made the data mean something, the integrations, the mailbox rules, the network settings, is what people discover they are rebuilding by memory at two in the morning.

3. Somebody checked the restored thing actually works

Restored is not the same as working. The check is that a person who uses the system opened it and confirmed it behaves, rather than an engineer confirming the files landed. Applications need licences, certificates, service accounts and dependencies, and a restore that returns the data without them returns a shape of the system. Bring the person who would actually be under pressure on the day into the test, because their questions are the ones that matter.

4. The result is written down, including what failed

Write down what was restored, when, how long it took, who did it, and what did not work. The failures are the valuable half: a test where everything worked first time usually means the test was small. ASD's Information security manual puts data restoration processes and supporting procedures alongside backup processes as things to develop, implement and maintain, and a record of tests is how you demonstrate the second half of that rather than assert it.

There is a practical reason too. An assessor, a client or an insurer asking about backups is asking for an artefact. A dated test record is an artefact. A confident answer is not. ASD's assessment guidance says as much about what an assessor should find: the discussion covers whether exercises have been conducted, how often, when the last one was, and whether restoration was partial or full, and ideally some form of after-action review or post-exercise report is available to show what was exercised and what was learnt.

5. A named person owns the test

Not a department, a person, with the next test in their calendar. Backup testing is the classic task that belongs to everyone and therefore to nobody, and it stops happening not through a decision but through a quiet twelve months in which it was always next month. If your arrangement is that the provider does it, the owner is still someone on your side who reads the record and notices when it stops arriving.

Would the backup survive the same attack?

The five checks above assume the backup is there to restore from. Modern ransomware assumes it can be, which is why attackers go looking for the backup platform first. ASD's Information security manual is blunt about the mechanism: as malicious actors routinely seek to access backup infrastructure using credentials harvested from production environments, backup infrastructure should be segregated from such environments and use a separate authentication mechanism for administrative access.

So the second group of checks is about survival rather than success. This is also where the Essential Eight's maturity levels do their work, because the difference between them on backups is almost entirely about who can reach and delete them.

6. An administrator account cannot quietly delete it

At Maturity Level One, ASD requires only that unprivileged user accounts cannot access other people's backups and are prevented from modifying and deleting them. Level Two extends the same restriction to privileged accounts other than the backup administrator, and Level Three goes further again, preventing even backup administrator accounts from modifying or deleting backups during their retention period. Read that progression from an attacker's point of view and it is a single question: how many stolen passwords away is your backup from being deleted?

Separately from the maturity model, the Information security manual's September 2026 release added a control for storing backups using a technically enforced immutability mechanism that prevents modification or deletion for the retention period. It is not part of the Essential Eight requirements and is worth knowing about anyway, because it is the version of this control that does not depend on an account staying honest.

7. The backup system has its own front door

The same September 2026 release added a companion control: backup infrastructure, including backup servers, repositories and management consoles, segregated from production environments and using a separate authentication mechanism for administrative access. In plain terms, the credentials that run your business should not also open the place your business is recoverable from. Ask which account can log into the backup console, and whether it is the same one that administers the environment being backed up.

8. You keep enough history to reach a clean day

Backups are to be performed and retained in accordance with business criticality and business continuity requirements, which is ASD leaving the retention period to you on purpose, because it depends on your business. The test that makes it concrete is this: if something was tampered with six weeks ago and nobody noticed until today, does a copy from before that exist? Fourteen days of history is a fine answer to a deleted folder and a poor one to an intrusion that sat quietly.

9. Your cloud data is on the list, not assumed

Ask for the written scope of what is backed up, then read it for what is missing. The usual gaps are the things nobody thinks of as a server: the Microsoft 365 or Google tenant, the accounting platform, the line-of-business application a vendor hosts, the file sync that people treat as a backup because it has a version history. A hosted platform's own resilience protects against its failure, which is not the same as protecting you against your own deletion, and the check list for an environment you have just taken over starts in the same place, with an inventory rather than an assumption.

Four questions to put to your provider this week

The nine checks are things about your environment. These four are things about your arrangement, and you can send them in an email this afternoon. None of them requires you to be technical, and all four can be answered in plain English by anyone who is actually doing the work.

1. When did you last test a restore for us, and what came back? A straight answer is a date and a list. A screenshot of a monitoring dashboard is an answer to a different question, and if the date is the same as the date you asked, you have learned something too. ASD's assessment guidance puts the floor at least annually, so a date more than a year old is a finding rather than a detail.
2. How long did it take, and in what order would systems come back? The order should follow what your business needs first rather than what is easiest to restore first, and somebody should have decided it in advance. The hours matter commercially: the downtime calculator does the wages arithmetic for a day nobody can work, which is the real cost of a restore that takes three days instead of one.
3. Which accounts can delete our backups? You want a short list of named accounts and a statement about whether the backup platform uses separate credentials from the rest of the environment. If the answer is that the domain administrator can, that is check 6 answered.
4. What is not backed up, and why? Every environment has exclusions and most of them are deliberate and sensible. The problem is the undocumented exclusion, which is indistinguishable from an oversight until the day you need the thing. Ask for the scope in writing and read the bottom of it.

Why an untested backup fails twice

The first failure is against the framework, and it is the one most businesses do not expect. Regular backups is one of ASD's eight strategies, and the testing requirement sits at Maturity Level One, which is the floor rather than the ambition. A business that backs up diligently and has never restored does not have a partial position on that control. It has an untested one, and an assessor records what the evidence shows.

Worth being accurate about what that means: there is no requirement for organisations to have their Essential Eight implementation certified by an independent party, though an assessment may be required by a government directive or policy, a regulator, or a contract. The Essential Eight is a minimum set of preventative measures, and ASD says plainly that it will not mitigate all cyber threats. It is a floor you can be measured against, not a certificate you hold. Check the current wording rather than a copy of it, because these documents move: the maturity model page was last updated on 27 November 2023, the assessment process guide on 2 October 2024, and the Information security manual guidance quoted above is dated 3 September 2026. ASD has also consulted on evolving the Essential Eight into a broader Essentials series grounded in the Information security manual. That consultation ran until 12 July 2026 and is closed, and no changed requirement has been published since. ASD's own note to organisations already using the Essential Eight is that they can expect strong alignment with their existing controls and investments. Backups that get restored are not going to stop being the point.

The second failure arrives with a questionnaire. The Insurance Council of Australia describes what happens when a cyber policy is written: insurers need to access their client's data and IT processes and potentially test their cyber defences to analyse and price the risk, and the Council endorses the Essential Eight Maturity Model as a good first step towards improved cyber security health. Whatever any policy does in a given event remains a matter for its terms and the insurer's assessment. What you control is whether you answer the backup questions from a dated test record or from memory, and what underwriters look at before they cover a business puts tested restores alongside multi-factor authentication as the two controls that get read line by line.

This is why the backup and recovery line in inSUPPORT's Cyber Strength Audit is written as the two questions above rather than one: not whether backups run, but whether they have been tested and whether they would survive the same breach. It is also why Compliant Backup is quoted as its own line item beside the monthly support fee rather than folded into it. A backup nobody has tested is a hope rather than a plan, and you are entitled to see what you are paying for either way.

Backups and restores: the questions people actually ask

How often does a tested backup restore need to happen?

At least annually. The Essential Eight maturity model's requirement text does not name a frequency, but ASD's assessment guidance does: restoration should be tested as part of regular disaster recovery exercises, at least annually, and not left until after the first major security incident. Treat annually as the floor rather than the plan, because a business that could not afford to lose a week of work needs to know more often than once a year. Set an interval above that floor, test again after any change to the backup platform or a major system, and keep the record.

Can we test a restore ourselves, or does it need our IT provider?

You can and should be in the room, because the useful half of the test is a person who uses the system confirming it works. The technical work usually needs whoever administers the environment, since a real test restores into an isolated place rather than over the top of live data, and getting that wrong is its own incident. The practical split is that your provider performs the restore and produces the record, and somebody on your side opens the restored system and signs the record.

What does it mean if a test restore fails?

It means the test worked. A failure found on a quiet Tuesday is a task with a date on it; the same failure found during an incident is an outage you cannot end. Write down exactly where it stopped, fix that specific thing, then run the test again rather than assuming the fix held. Most first tests fail somewhere, usually on a dependency nobody had written down, which is the reason for testing rather than an argument against it.

Nobody here has ever tested a restore. Where do we start?

Start with one system that matters and one afternoon. Ask for the written scope of what is backed up, pick the most business-critical thing on it, and have it restored somewhere isolated while somebody who uses it watches. That single exercise answers most of the nine checks above, and the gaps it exposes become a short list with prices rather than a worry. If you would rather see the whole environment assessed at once, that is what an audit is for.

Citations

• "Essential Eight maturity model, Australian Signals Directorate", The regular backups control at each maturity level, including the requirement that restoration to a common point in time is tested as part of disaster recovery exercises, the escalating restrictions on which accounts can delete backups, and ASD's statements that the Essential Eight is a minimum set of measures and needs no independent certification. First published 30 June 2017, last updated 27 November 2023. cyber.gov.au
• "Guidelines for system management, Australian Signals Directorate", The Information security manual controls behind the checks above: backup and restoration processes (ISM-1547, ISM-1548), testing restoration to a common point in time (ISM-1515), and the September 2026 additions on technically enforced immutability (ISM-2151) and segregated backup infrastructure with separate administrative authentication (ISM-2152). Dated 3 September 2026. cyber.gov.au
• "Essential Eight assessment process guide, Australian Signals Directorate", The testing cadence and what an assessor looks for. Under Regular backups: restoration from backups should be tested as part of regular (at least annually) disaster recovery exercises and not left until after the first major security incident; business-as-usual recovery of user files is not sufficient for the control, whose intent is restoration of a significant component of a system as part of a scheduled exercise; and an after-action review or post-exercise report should ideally be available. First published 24 November 2022, last updated 2 October 2024. cyber.gov.au
• "Consultation on evolution of Essential Eight, Australian Signals Directorate", The review-date sentence above. ASD's announcement that it consulted on evolving the Essential Eight into an Essentials series grounded in the Information security manual, beginning with Essentials for enterprise IT, with consultation running until 12 July 2026, and its note that organisations already using the Essential Eight can expect strong alignment with their existing controls and investments. cyber.gov.au
• "Cyber risk, Insurance Council of Australia", The insurance industry's own account of what happens when a cyber policy is written, that insurers access a client's data and IT processes and may test their defences to price the risk, and the Council's endorsement of the Essential Eight Maturity Model as a first step for small and medium businesses. insurancecouncil.com.au

Related Reading

• What Does IT Downtime Cost?
• What Underwriters Check Before They Cover an Australian Business
• You Have Inherited an IT Environment. What to Check First.
• What is Disaster Recovery?
• The 6 Step Cyber Strength System

Content reviewed by Probably Genius for accuracy and relevance.

inSUPPORT provides managed IT and cyber security services. It is not an insurer, insurance broker or underwriter and does not hold an Australian Financial Services Licence. Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment, the policy terms and the Product Disclosure Statement and Target Market Determination. This article is general information about IT and security practice, not financial product advice, and it does not take account of your objectives, financial situation or needs.