Create an ERP disaster recovery plan that stands up

An ERP disaster recovery plan is the practical playbook for keeping finance, payroll, inventory, purchasing and customer orders moving when the system, its data or a critical connection fails. It covers who makes decisions, which workflows must resume first, how data returns, and how staff will work during downtime. The aim is a recoverable service with controlled disruption, not a guarantee that every application will be instantly available.

For an Australian business, the plan must reflect local operating conditions: bushfires and flooding around Sydney and Melbourne, cyclones in northern Queensland, NBN and mobile network outages, cloud-region failures and cyber incidents such as ransomware. It should also fit the resources of a small firm that may rely on a managed service provider rather than a large internal IT team. Recovery priorities, a resilient technical path, documented actions and regular testing then become a shared operating discipline rather than an IT project that stalls after the policy is signed.

Set ownership, scope and recovery objectives

Begin with a sponsor who can fund recovery decisions and an incident commander who can declare an incident. Name owners for the ERP application, infrastructure, data, networks, security, finance, payroll, warehouse operations and communications. In a mid-sized organisation, one person may hold several roles, so record backups and avoid ambiguous titles. External providers should have named contacts and contractual escalation paths, not just a support portal.

Run a business impact analysis across time-critical workflows. Determine the maximum tolerable downtime for order entry, stock movements, production scheduling, supplier payments, payroll, reporting and statutory reporting. Set a recovery time objective for each service and a recovery point objective showing how much recent data loss is acceptable. A payroll process may tolerate different data loss from a warehouse pick list, so one global target will not work.

Prioritise using financial, customer, safety, contractual and reputational impact. An Australian finance team may need access to ledgers, GST records and business activity statement workflows; an operation may need live inventory before management reporting is restored. Include blackout dates, batch windows and peak trading periods. If a business cannot tolerate the stated recovery time, document a manual bridge or a simpler interim system rather than pretending the ERP alone can meet the need.

Map dependencies and failure scenarios

Create a dependency map from the people and process through to the underlying technology. ERP platforms often rely on identity providers, DNS, email, document storage, payment gateways, bank feeds, e-invoicing tools, warehouse scanners, customer portals and APIs. A seemingly small integration can stop invoice creation or delivery updates. Record the owner, criticality, data location, vendor and fallback for every component, including utilities and office connectivity.

Identify failure scenarios for each critical service: corrupted data, ransomware, an expired certificate, a failed cloud region, database replication lag, a damaged server room, an extended NBN outage and loss of a key administrator. A regional 4G or 5G backup can help, though coverage and carrier availability vary. Australian blackspots and physical disasters mean the failover route must be tested rather than assumed to work from every branch.

Review legal and contractual duties as part of that map. The Privacy Act and Notifiable Data Breaches framework apply where relevant, while APRA-regulated entities must also account for CPS 234 security requirements. State payroll, superannuation and tax obligations can differ by operating footprint, and contracts may dictate notification times or data residency. Have legal and security advisers confirm the rules that apply to the organisation instead of copying a generic compliance checklist.

Map people as well as technology. Include staff in Sydney, Melbourne, Brisbane, Perth, Adelaide and regional depots, plus remote workers and contractors. Time zones, mobile rosters and access to shared multi-factor authentication tokens affect out-of-hours decisions. Record who can authorise payroll overrides, banking changes and emergency vendor spend, and keep an offline contact list because email may be unavailable.

Build backups and a survivable recovery path

Backups are only useful if they can be restored. Follow a retention design that combines protected full backups, incremental or continuous recovery points, and copies held outside the primary environment. Use immutable or offline storage where available so ransomware cannot erase every version. Monitor backup jobs, test sample restores and align retention with legal, tax and recordkeeping requirements. The design must meet the recovery point objective without making restore operations painfully slow.

Choose a recovery architecture appropriate to the application and budget. Options include a warm standby site, a cloud replica in another Australian region, active-active infrastructure, or a documented rebuild onto new hardware. Compare recovery time, licensing, data transfer, specialist skills and recurring cost. Disaster recovery as a service can suit a small business, but the organisation still needs a clear understanding of provider responsibilities, support hours and exit arrangements.

Decide whether failover is automatic, approved by the incident commander, or initiated by the ERP administrator. Prepare DNS, IP addresses, licences, configuration, secrets, network rules and privileged access so the environment can come up without improvised changes. Keep a clean recovery path for malware events, and restrict ordinary administrator accounts from altering immutable copies. Rehearse restoring application data and configuration together; a current database with stale settings is not a healthy ERP.

Plan the physical and network layer. Specify backup power, cooling, generator fuel, fire protection and equipment delivery for the primary site, as well as alternate communications when the NBN is unavailable. Cloud replication helps with system failure, yet it cannot solve every local power or connectivity problem. Include spare devices, secure remote access, multi-factor authentication and a method for staff to confirm their identity when primary authentication services are down.

Document actions, workarounds and communications

Write the plan as a usable runbook rather than a broad policy. Sequence detection, triage, declaration, containment, failover, data validation, return to service and reconciliation. Each action should name a role, expected duration, success test and alternate route. Keep language plain and fair dinkum: an exhausted warehouse supervisor should be able to find the next step quickly, while finance staff should know which approvals remain valid.

Build communication pathways before an incident. The runbook should cover internal channels, SMS or phone bridges, customer notifications, supplier and bank contacts, cyber-insurance claims, the ATO, regulators and law enforcement where appropriate. Give the communications lead message templates and approval rules, while authorised executives decide what customers and regulators need to hear. External links in templates also need ownership and review dates because calls to action can expire or redirect. An example is this free chip offer, where the wording and destination should be checked before reuse in an incident page.

Prepare manual continuity packs for the first hours. These can include approved offline timesheets, stock-count sheets, purchase orders, invoice summaries, payment postponement instructions and secure procedures for storing personal information. State who can authorise manual journals and how they will be entered later without duplication. A short, prioritised checklist is more useful than a binder nobody has opened, and it should be stored in a place staff can reach without the network.

Test, measure and maintain the plan

Test at several levels. Start with a tabletop discussion of a credible scenario, then run technical restores, failover drills and communication exercises without putting live production at risk. Simulate the failure that matters, such as ransomware that removes administrative access or a prolonged site power outage. Measure actual recovery time, data loss, decision delays and manual workarounds against the objectives. Record every gap with an owner and due date rather than leaving findings in meeting notes.

Repeat the full exercise at least annually and after major changes to applications, networks, sites, suppliers or recovery architecture. Review access rights, dormant administrator accounts, contact lists and the location of backup media. Cloud contracts, software licences and Australian support arrangements can expire quietly, while a new office or warehouse can introduce dependencies the map has missed. Train new starters and relief staff, and invite the managed service provider and key vendors to take part.

Track a small set of useful indicators: backup completion and restore success, percentage of critical services meeting recovery objectives, time to declare an incident, time to reach stakeholders, and time to reconcile manual transactions. These measures show whether the ERP is recoverable in practice, not merely configured correctly. Keep the plan under version control, link each procedure to evidence such as test reports, and feed lessons into business continuity, security and procurement decisions. A current disaster recovery plan is an operational control that earns its keep whenever an Australian team needs to get the business back up and running.