Security

ERP backup and disaster recovery checklist for Australian businesses

A practical checklist for testing ERP backups, restore limits, integration recovery, cyber resilience, and business continuity before an outage becomes a crisis.

Cloud ERP does not remove the need for a recovery plan. The software provider may protect the core database, but your business still owns the recovery of integrations, identity access, reports, documents, payment files, operational workarounds, and the decisions that bring people safely back online.

A useful ERP disaster recovery plan starts with business consequences. How long can order entry stop? Which finance transactions must be reconstructed? What happens if the ERP returns before the warehouse, bank feed, payroll interface, ecommerce platform, or identity service?

Use this checklist to turn backup promises into a tested recovery capability with named owners, realistic time targets, and evidence from an actual restore exercise.

1. Define the services the business must recover

• List the ERP processes that protect cash, customers, inventory, payroll, statutory reporting, and supplier continuity. Rank them by the maximum tolerable outage and data loss.
• Set a recovery time objective for each critical process and a recovery point objective for the data behind it. Avoid one blanket target for the whole ERP estate.
• Document minimum viable operations for the first hours of an outage, including manual order capture, dispatch authority, payment controls, customer communication, and transaction back-entry.
• Identify peak-risk periods such as month end, payroll cut-off, seasonal fulfilment, BAS preparation, stocktake, and payment runs.

2. Map the complete ERP recovery boundary

• Include the core ERP environment, identity provider, integrations, middleware, ecommerce, EDI, bank feeds, payment files, document storage, reporting platforms, data warehouse, labels, scanners, and custom extensions.
• Record which party owns backup and recovery for every component: software provider, implementation partner, managed service provider, internal IT, or business process owner.
• Capture configuration and software dependencies as well as transactional data. Australian Cyber Security Centre guidance specifically includes important data, software, and configuration settings in a resilient backup design.
• Synchronise recovery points where systems exchange transactions. Restoring the ERP and its integration platform to materially different points in time can create duplicates, omissions, and broken reconciliations.

3. Verify what the cloud ERP provider will actually restore

• Ask for the documented retention window, restore frequency, permitted restore destinations, regional limits, administrator permissions, monthly restore limits, expected duration, and support escalation path.
• Microsoft currently documents a self-service Business Central environment restore window of up to 28 days and a limit of 10 restores per environment in a calendar month. It also notes that linked Power Platform environments are not restored with the Business Central environment.
• Treat these product limits as design inputs, not as the entire recovery plan. A restored database does not automatically recover every connected service, app registration, extension, job queue, integration credential, or business transaction completed elsewhere.
• Require the implementation partner to identify every component that sits outside the provider restore boundary and show how it will be rebuilt or reconciled.

4. Protect backups from the same incident

• Restrict access so ordinary and unprivileged accounts cannot modify or delete backups. Separate backup administration from day-to-day ERP administration where practical.
• Keep recovery copies resilient against ransomware, credential compromise, accidental deletion, and a failure at one physical or cloud location.
• Review encryption, privileged access, immutable or protected retention options, alerting, and the process for emergency access to recovery tooling.
• Confirm that losing the normal administrator account or identity service does not make the recovery procedure impossible to start.

5. Test a coordinated restore, not just a backup status screen

• Run a scheduled exercise that restores a meaningful ERP environment and the dependent services needed for one end-to-end business process.
• Time each stage: incident declaration, access to recovery tools, environment restore, extension validation, integration reconnection, reconciliation, user acceptance, and controlled return to service.
• Test whether job queues, automated postings, interfaces, and outbound messages remain paused until the restored data has been checked. This reduces the chance of a recovery creating a second incident.
• Reconcile control totals across the ERP and connected systems before reopening. Include orders, shipments, invoices, payments, inventory movements, payroll-related transactions, and interface queues where relevant.
• Record lessons, owners, and due dates after every exercise. A green backup dashboard is not evidence that the business can recover.

6. Prepare the cyber and privacy response path

• Keep the technical recovery plan connected to the incident response plan. A ransomware event may require containment and forensic decisions before systems are restored.
• Define who assesses whether personal information was accessed, disclosed, or lost and who coordinates legal, privacy, insurer, customer, employee, and regulator communications.
• The Office of the Australian Information Commissioner says eligible data breaches involve likely serious harm and an inability to prevent that risk through remedial action. Build the assessment and escalation path before an incident.
• Preserve the logs, timestamps, affected-record evidence, and recovery decisions needed to support incident assessment without delaying safe operational recovery.

7. Put recovery obligations into partner and vendor agreements

• State recovery time, recovery point, retention, test frequency, support availability, escalation, evidence, and post-incident review requirements in clear operational language.
• Name who pays for restore exercises, emergency partner support, integration repair, data reconciliation, and extended hypercare.
• Require current runbooks and environment inventories to be handed over when staff, partners, or managed service providers change.
• Ensure the business can access essential documentation, credentials, source code or deployment packages, licence information, and vendor contacts without relying on one person.

A practical ERP recovery exercise

• Scenario: ransomware or administrator error makes the production ERP unreliable at 10:00 am on a busy trading day.
• Objective: restore to a safe point, recover one order-to-cash or procure-to-pay flow, reconcile the missing transaction window, and resume controlled operations.
• Evidence: elapsed time, restored timestamp, component checklist, access approvals, reconciliation totals, user sign-off, unresolved gaps, and follow-up actions.
• Pass condition: the business meets its agreed recovery targets without uncontrolled postings, duplicate transactions, missing audit evidence, or reliance on undocumented individual knowledge.

Questions to ask before approving the plan

• What is the oldest and newest point we can restore to, and who is authorised to do it?
• Which systems, documents, credentials, and integrations are outside the ERP provider backup?
• When did we last restore a meaningful environment and complete an end-to-end business process?
• How will we identify and reconcile transactions created between the recovery point and the outage?
• Can the recovery start if our normal administrator identity, implementation partner, or primary office is unavailable?
• Who decides that the recovered environment is safe for users, integrations, and automated jobs to resume?

Sources used

• Australian Cyber Security Centre: Essential Eight guidance and the technical example for regular backups.
• Australian Cyber Security Centre: Securing customer personal data.
• Australian Government business.gov.au: Develop an emergency management plan.
• Office of the Australian Information Commissioner: Data breach response plan and Notifiable Data Breaches guidance.
• Microsoft Learn: Restoring a Business Central environment in the administration centre.