How Often Should Businesses Test Backups?

Most Australian businesses should test critical system backups monthly. Important systems should be tested quarterly. All systems should be verified automatically after every backup job. Beyond the regular schedule, seven specific events trigger an immediate test regardless of when the last one was done. This guide gives you the exact schedule, the triggers, and the compliance requirements so you can stop guessing and start knowing.

Key Takeaways

• Monthly testing is the recommended standard for critical systems. Quarterly testing is the absolute minimum for any business system.
• Automated daily verification is separate from manual restore testing. Both are required. One tells you the backup job ran. The other confirms you can actually get your data back.
• Seven events trigger an immediate test regardless of your regular schedule: ransomware attack, major software upgrade, cloud migration, server hardware change, backup platform version update, staff departure of the backup administrator, and any failed backup job alert.
• The Essential Eight framework at Maturity Level 1 requires that backups are tested regularly. Levels 2 and 3 require documented RTO and RPO targets to be validated during each test.
• According to Sophos State of Ransomware 2025, 75% of organisations hit by ransomware could not fully restore from backup. Irregular or untested backup schedules are a primary contributing factor.
• Microsoft 365 data (Exchange Online, SharePoint, OneDrive, Teams) needs separate testing because Microsoft does not provide a complete backup restore service. Your dedicated M365 backup platform needs its own testing schedule.

The Core Distinction Most Businesses Miss

Most businesses check that backup jobs complete. They see a green status in the backup console and move on.

That is not backup testing.

A completed backup job means files were copied. It does not mean those files are readable. It does not mean an application will function correctly after a restore. It does not mean the restore will complete within your acceptable timeframe. It does not mean the data you copied was clean and not already affected by an attacker lurking in your environment.

Real backup testing means performing an actual restore, in an isolated environment, and verifying the outcome against defined criteria. It is the only way to know your backup will work when you actually need it.

The question of how often to test is really the question of how long you are willing to go without knowing whether your recovery plan works. The answer to that question differs by system, by industry, and by risk tolerance.

The Recommended Testing Schedule by System Tier

Not all systems need the same testing frequency. The most effective approach matches testing intensity to business impact. Here is the schedule that reflects current best practice for Australian businesses.

These are minimum recommendations. Businesses in regulated industries (financial services, healthcare, legal, NDIS providers) or those with Essential Eight Maturity Level 2 and 3 requirements should test at the higher frequency within each tier.

If you have not categorised your systems into tiers yet, that is the first thing to do. Without knowing which systems matter most, there is no rational basis for a testing schedule.

What Each Type of Test Actually Involves

The schedule above references three types of testing. Each one serves a different purpose and takes a different amount of time.

Automated Daily Verification

Your backup platform runs a check after each job completes. It mounts the backup image, confirms the system boots, takes a screenshot, and logs the result. You review a dashboard that shows pass or fail for every recent job.

This takes zero manual effort once configured. It tells you quickly whether a backup job produced a readable, bootable image. It does not confirm application functionality or measure recovery time.

Tools that include this: Veeam SureBackup, Datto Continuity verification, Acronis backup validation.

Enable automated verification on every backup job where your platform supports it. If your platform does not support this, that is worth reconsidering.

Granular File or Mailbox Restore Test

A team member initiates a restore of a specific file, email, database record, or folder from a recent backup. The restore goes to an alternate location, not the original. The test confirms the data is intact, readable, and matches the expected version at that recovery point.

This takes 15 to 45 minutes depending on data size. It validates that backup data is readable and that your platform can retrieve specific items. It does not confirm full system recovery.

For Microsoft 365, this means restoring a specific email to a test mailbox, restoring a specific SharePoint document version, and restoring a specific OneDrive file to an alternate location.

Full System Restore Test

A complete server, virtual machine, or application stack is restored from backup into a fully isolated environment with no connection to production systems. The team confirms the system boots, applications start, users can authenticate, and data is present at the correct recovery point. The elapsed time is measured and compared to the defined Recovery Time Objective.

This takes several hours for a complex system. It is the only test that validates you can actually recover your business operations within your acceptable downtime window.

For each full system restore test, document the start time, the recovery point used, the applications tested, the outcome, and the total elapsed time. Compare that time to your documented RTO. If the actual time exceeds your RTO, that is a gap to address before an incident forces the issue.

Our guide on how to test backups without risking production data covers the isolated environment setup in detail.

The 7 Triggers That Require an Immediate Test

Your regular schedule is the baseline. These seven events require an additional test immediately, regardless of when the last one occurred.

Trigger 1: After a Ransomware Incident or Security Event

If your environment has experienced a ransomware attack, a confirmed compromise, or a suspected breach, your existing backup data may already contain corrupted or attacker-modified files. Before you declare recovery complete, verify the clean recovery point by restoring into an isolated environment and confirming the restored system shows no signs of compromise.

This is also the moment when most businesses discover their backup strategy had gaps. Use the incident as a diagnostic exercise. Document what the backup was able to recover and what it could not.

Trigger 2: After Any Major Software Upgrade or New Application Deployment

A new application may not be captured by your existing backup jobs. A software upgrade may change data structures in ways that affect restorability. A new application installed on a server that is being backed up will only be recoverable if the backup job was reconfigured to include its data paths and any new dependencies.

After every major software change, run a full system restore test to confirm the upgraded system restores correctly and the application functions in the restored environment.

Trigger 3: After a Cloud Migration

Moving systems or data to a new cloud environment resets your backup coverage. Your on-premise backup agent no longer applies to cloud-hosted systems. Your cloud backup configuration must be rebuilt and tested for the new environment.

After completing any cloud migration, test restores for every migrated system before you decommission the old environment. This is the window where data loss is most likely to occur undetected.

For Australian businesses considering cloud migration, see our cloud migration guide for the broader planning considerations.

Trigger 4: After Backup Platform Version Updates or Infrastructure Changes

A backup platform software update can introduce incompatibilities with existing backup jobs. A new storage system, a replaced NAS, a hardware refresh, a change to network segmentation: all of these can break a backup job that was working correctly before the change.

Any change to your backup infrastructure or the infrastructure it protects requires a verification test. This is a frequently skipped step during hardware refresh projects and one of the most common sources of undetected backup failure.

Trigger 5: After Any Failed Backup Job Alert

A failed backup job alert should never be dismissed or acknowledged and ignored. Every failed backup job must be investigated. The investigation must confirm whether the failure was a transient error that was resolved automatically or a persistent issue that left a gap in your backup coverage.

After any confirmed backup job failure, run a restore test for the affected system once the failure is resolved. This confirms the backup is working correctly again and closes the uncertainty about what data is and is not protected.

Trigger 6: When the Backup Administrator Leaves the Organisation

If the person who built and manages your backup environment departs, there is often a period where backup jobs run without anyone actively monitoring them. There may also be credentials, configuration knowledge, or platform access that only the departing staff member had.

During any staff transition involving someone responsible for backup management, run a full test of all critical system backups. Confirm that the incoming person can access the backup platform, interpret the results, and initiate a restore. Document everything that was previously undocumented.

This connects directly to the identity lifecycle management principle: access and knowledge should not be dependent on any single individual. See our identity lifecycle management guide for the broader offboarding framework.

Trigger 7: Before and After Any Major Business Event

This includes mergers and acquisitions, office relocations, opening new sites, and any period of significant business transformation. During these events, IT environments change rapidly and backup coverage can fall behind. Run a full test before the event to establish a clean baseline, and run another test after the event to confirm coverage has been maintained.

How Ransomware Should Change Your Testing Assumptions

If your backup testing schedule was designed before ransomware became a primary concern, it may not account for the most important variable: attacker dwell time.

According to Mandiant M-Trends 2025, attackers spend an average of 17 days inside a network before deploying ransomware in cases where they are detected, but in undetected cases, dwell time extends to months. This means your most recent backup snapshots may already contain files modified by an attacker. The backup looks healthy because it completed successfully, but it backed up compromised data.

This changes what testing needs to validate. Beyond confirming a backup is readable, you need to confirm that recovery points from multiple points in time are available and that you can identify which recovery points pre-date any suspected compromise.

This is why backup platforms that maintain 90 or more days of versioned recovery points are essential for ransomware scenarios, and why testing should occasionally validate recovery points from beyond the most recent 30 days.

If you can only restore from the last 7 days and an attacker has been present for 14 days, your backup cannot help you get to a clean state without significant data loss.

Testing Microsoft 365 Backups: A Separate Schedule Is Required

Microsoft 365 backup testing is the most commonly neglected part of a business backup programme. Most organisations assume Microsoft handles it. Microsoft does not provide a full backup.

Microsoft guarantees service availability, not data recovery. Deleted items are recoverable for a maximum of 93 days. Version history is limited. If a ransomware group gains admin access to your Microsoft 365 tenant and bulk deletes mailboxes, SharePoint sites, and OneDrive content, Microsoft’s built-in protections are insufficient for full recovery.

If you use a dedicated Microsoft 365 backup platform (Microsoft 365 Backup, Datto SaaS Protection, Veeam Backup for Microsoft 365, or equivalent), your testing schedule should include:

Monthly granular restore tests: Pick a specific email from Exchange Online and restore it to a test mailbox. Pick a specific SharePoint document version and restore it to an alternate location. Pick an OneDrive file and restore it to a different path. Confirm each restore returns the correct version of the data.

Quarterly full mailbox restore tests: Restore a complete mailbox for a test user. Confirm all folders, emails, contacts, and calendar items are present. Confirm the mailbox is accessible and usable. Measure the total restore time and compare to your RTO for email availability.

After any Microsoft 365 tenant changes: Any change to conditional access policies, admin account configurations, or connected applications should prompt a test to confirm backup coverage is unaffected.

Our M365 backup solutions guide and Datto SaaS Protection guide cover the specific platforms and their restore capabilities.

What Happens When You Skip Tests: The Real Cost

Skipping backup tests does not reduce cost. It transfers cost forward to the moment of failure, where it is far higher.

The direct costs of discovering a backup failure during an actual incident include:

Extended downtime while the IT team diagnoses the backup failure and attempts alternative recovery methods. Every hour of additional downtime has a real cost in lost revenue and staff productivity.

Emergency data recovery services if the backup data is partially recoverable. Specialist forensic data recovery typically costs several thousand dollars per incident and takes days to weeks.

Regulatory fines and investigation costs if the failure results in a notifiable data breach under the Privacy Act 1988 and the backups that would have limited the scope of the breach were unavailable or inadequate.

Ransom payments if ransomware is the cause and backup recovery proves impossible. According to Sophos State of Ransomware 2025, the median ransom paid globally is US$200,000. Australian SMBs are not exempt from this risk.

The indirect costs include client trust damage, insurer premium increases or coverage refusals at renewal, and the staff hours spent on emergency response instead of productive work.

A monthly backup test for a critical system typically takes one to two hours of IT staff time. That investment is trivially small compared to any of the costs above.

Australian Compliance Requirements for Backup Testing

ACSC Essential Eight

The Essential Eight maturity framework addresses backup testing directly.

At Maturity Level 1, backups of important data, software, and configuration settings must exist, must be tested, and must be restorable. The frequency is not specified precisely at this level, but the intent is regular and confirmed testing.

At Maturity Level 2, backups must be tested on a schedule that aligns with the criticality of the data. Recovery from backup must be verified within defined timeframes. Backup testing must include confirmation that critical systems can be recovered within acceptable timeframes.

At Maturity Level 3, all critical systems must have documented RTO and RPO targets. Recovery capability must be tested against these targets. Testing must include scenarios that reflect realistic incident conditions, not just clean restore drills.

Most Australian businesses targeting Essential Eight compliance should be aiming for at least Maturity Level 2, which means monthly testing for critical systems with documented RTO and RPO validation.

Privacy Act 1988 and Notifiable Data Breaches Scheme

Under the NDB scheme, organisations must be able to investigate and assess the scope of a data breach if one occurs. This requires knowing what data was in the backup at the time of a compromise, whether that backup data was clean, and whether it can be used to restore affected systems.

Regular backup testing creates the documentation trail that supports this investigation. Without test records, you cannot demonstrate what your backup contained at any given point in time, which makes scope assessment harder and regulatory compliance harder to demonstrate.

Cyber Security Act 2024

Under the Cyber Security Act 2024, Australian businesses with more than $3 million annual turnover must report ransomware payments to the ACSC within 72 hours of making or intending to make one. A backup programme that is regularly tested and can support full recovery reduces the probability of reaching the point of paying a ransom.

If a ransom is paid because backups failed at recovery, the failure to maintain adequate and tested backup systems may be examined as part of any subsequent regulatory review.

For the full Essential Eight mapping, see our Essential Eight checklist.

What Good Backup Testing Documentation Looks Like

Testing without documentation produces no lasting value. The test results exist in someone’s memory, and a week later the organisation has no record of what was tested, what worked, or what gaps were found.

After every backup test, record the following:

The date and time of the test. The system or data that was tested. The type of test conducted (automated verification, granular restore, or full system restore). The recovery point used: which backup snapshot was restored from and how old it was. The elapsed time from initiating the restore to achieving full application function. The outcome assessed against defined pass criteria. Any issues, errors, or gaps identified. The actions taken to resolve identified issues. The name of the person who conducted the test. The scheduled date of the next test for this system.

Store all backup test records in a centralised location accessible to the whole IT team, not on the backup administrator’s device. Include backup test summaries in quarterly security reviews. Provide test documentation to your cyber insurer at renewal when requested.

See our IT documentation best practices guide for the documentation system structure that backup test records should sit within.

Quick Reference: Backup Testing Schedule Summary

Use this as a starting point. Adjust frequencies upward based on your industry, compliance obligations, and risk tolerance.

Plus: immediate testing after any of the seven triggers listed above, regardless of when the last scheduled test occurred.

A Real Example: What Skipping Tests Costs

A professional services firm in Sydney had been running daily backups of their primary server for two years. Backup jobs completed successfully every night without exception. No restore test had ever been conducted.

When a staff member accidentally overwrote a critical database used for client billing, the firm initiated a restore from the previous night’s backup. The restore completed after four hours. The billing application would not start. Investigation revealed that a SQL Server dependency had been changed as part of a software update six months earlier. The backup contained the updated application but the recovery environment was missing the updated dependency. The backup was usable, but the restore process was not.

The firm spent an additional seven hours resolving the dependency issue before the billing system was operational again. Total downtime was 11 hours. Their stated RTO was 4 hours. The gap between expectation and reality was discovered during a live incident with clients waiting.

If the firm had run a quarterly full restore test, the dependency gap would have been discovered during a routine drill with no client impact and no business pressure. The fix would have been documented in the recovery runbook. The actual incident would have resolved in under 4 hours.

Testing costs time. Not testing costs more.

For a backup posture assessment or a structured testing programme for your Australian business, contact our team.

Related Reading

• How to Test Backups Without Risking Production Data — The step-by-step guide for conducting each type of backup test safely
• Why Backups Fail During Ransomware Attacks — The specific failure modes that regular testing prevents
• M365 Backup Solutions — Backup platforms for Microsoft 365 with built-in testing features
• Datto SaaS Protection — Immutable Microsoft 365 backup with automated restore verification
• Cloud Backup Strategy — Designing a backup architecture that supports structured testing
• The Role of Disaster Recovery in Cybersecurity — How backup testing fits within the broader disaster recovery framework
• Disaster Recovery Plan Checklist — The full recovery planning framework your backup tests should validate
• IT Documentation Best Practices — Documenting test results and maintaining recovery runbooks
• Essential Eight Checklist 2025 — Where backup testing sits within the Essential Eight compliance framework

Frequently Asked Questions

How often should businesses test their backups?

Most businesses should test critical system backups monthly using a full restore into an isolated environment. Important systems should be tested quarterly. All systems should have automated verification running after every backup job. Beyond the regular schedule, immediate testing is required after seven specific events: a security incident, a major software upgrade, a cloud migration, backup platform changes, infrastructure hardware changes, departure of the backup administrator, and any failed backup job alert. Monthly testing for critical systems is the current best practice recommendation aligned with the ACSC Essential Eight framework.

What is the minimum acceptable backup testing frequency?

Quarterly testing is generally considered the absolute minimum for any business system. Testing less than quarterly means you may go three or more months without knowing whether your backup is readable or your restore process works. Given that ransomware attackers spend an average of 17 days inside a network before being detected (and significantly longer in undetected cases), a quarterly gap leaves substantial time during which backup failures could go unnoticed. For critical systems, monthly testing is strongly recommended over quarterly.

Does Microsoft back up Microsoft 365 data automatically?

Microsoft does not provide a full backup of Microsoft 365 data in the sense that businesses typically require. Microsoft maintains infrastructure redundancy and service availability, and provides a recycle bin for deleted items with a maximum retention of 93 days. This is not a substitute for a dedicated backup. If a ransomware group gains admin access to your Microsoft 365 tenant and bulk deletes mailboxes and SharePoint sites, or if data is deleted beyond the 93-day window, Microsoft cannot provide full recovery. A dedicated Microsoft 365 backup platform (Microsoft 365 Backup, Veeam for Microsoft 365, Datto SaaS Protection, or equivalent) is required and must be tested separately on its own schedule.

What should be included in backup test documentation?

After every backup test, record the date and time of the test, the system or data tested, the type of test conducted, the recovery point used and its age, the elapsed time from initiating the restore to full application function, the outcome assessed against your defined pass criteria, any issues or gaps identified and their resolution status, the name of the person who conducted the test, and the date of the next scheduled test. Store this documentation centrally and include backup test summaries in quarterly IT security reviews. This documentation is also required as evidence during Essential Eight assessments and cyber insurance renewals.

Does the Essential Eight require backup testing?

Yes. The ACSC Essential Eight maturity framework explicitly requires that backups are tested at all maturity levels. At Maturity Level 1, backups of important data, software, and configuration settings must exist and be confirmed as testable. At Maturity Level 2, backups must be tested on a schedule appropriate to data criticality and recovery must be achievable within defined timeframes. At Maturity Level 3, all critical systems must have documented Recovery Time Objectives and Recovery Point Objectives that are validated during testing. Backup test records are typically requested as evidence during an Essential Eight assessment.

What happens when an untested backup fails during a real incident?

When a backup fails during a real incident, the consequences extend well beyond the immediate data loss. Extended downtime occurs while the IT team diagnoses the failure and attempts alternative recovery paths. Emergency data recovery services may be needed, typically costing several thousand dollars and taking days to complete. If personal data was exposed, a Privacy Act notifiable data breach assessment is required and notification to the OAIC may be mandatory within 30 days. If ransom payment becomes necessary because backup recovery is impossible, the Cyber Security Act 2024 requires businesses over $3 million turnover to report that payment to the ACSC within 72 hours. Testing prevents these outcomes by catching backup failures when the stakes are low.

Should I test backups after every change to my IT environment?

Yes. Any significant change to your IT environment should trigger an immediate backup test, regardless of your regular schedule. This includes major software upgrades, cloud migrations, hardware replacements, backup platform version updates, new application deployments, and changes to network segmentation. Changes frequently break backup jobs in ways that are not immediately obvious. A backup job may continue to report success while missing new data paths, skipping updated applications, or producing images that cannot restore correctly to the changed environment. Testing after every significant change is the only way to confirm your backup coverage kept pace with the change.