ERP OperationsFree templatePDF, Excel, Word exportDiscrete Manufacturing

Disaster Recovery Plan Template for Manufacturing IT

When the ERP or the plant network goes down, nobody wants to write the plan from scratch. This template gives IT managers in manufacturing a ready structure: recovery objectives, roles, declaration criteria, recovery order, manual fallback and testing. Fill in the fields and export it as a Word or PDF document.

Fill in

Company name

Site

Plan owner

Version

Plan date

ERP system

MES and plant systems

ERP target recovery time (RTO)

ERP data loss tolerance (RPO)

MES target recovery time (RTO)

Recovery site

Backup approach

Manual operations fallback

Test frequency

Live preview

Download:

Manufacturing IT Disaster Recovery Plan Template

Disaster Recovery Plan: Plant 1, Dayton

Company: Acme Precision Ltd Plan owner: IT Manager Version: 1.0 Date: 2026-10-20 Systems in scope: Infor SyteLine 10 (on-premise, 2 VMs); MES server, 3 SCADA servers, historian

1. Purpose and scope

This plan describes how Acme Precision Ltd restores IT services at Plant 1, Dayton after an event that stops them, such as ransomware, hardware failure, fire, flood or loss of power or network. It covers ERP, MES, plant floor servers, network and user access. It does not replace safety or evacuation procedures.

2. Recovery objectives

System	RTO (time to restore)	RPO (data loss tolerance)	Priority
ERP: Infor SyteLine 10 (on-premise, 2 VMs)	8 hours	1 hour	1
MES: MES server, 3 SCADA servers, historian	4 hours		1
Network core and firewalls			1
Directory services and authentication			1
Email and collaboration			2
Engineering and PLM file shares			2

3. Roles and contacts

Role	Name	Phone	Backup person
Incident commander
IT recovery lead
ERP administrator
Network and security lead
Plant operations lead
Communications lead
ERP and backup vendor contacts

4. Declaring a disaster

The incident commander declares a disaster when a priority 1 system is expected to be unavailable longer than its RTO, when data corruption or malicious activity is confirmed, or when the building or server room is unusable. Record the time of declaration, the decision maker and the first known cause. Isolate affected systems from the network before restoring anything.

5. Recovery approach

Recovery site: Secondary data center, Columbus, plus cloud backup vault

Backup approach: Hourly database log backups, nightly full backups, weekly offsite copy to immutable storage. Restore tested quarterly.

Recovery order: 1) network, firewalls and authentication; 2) database and ERP application servers; 3) MES and plant floor servers; 4) printers, label and barcode services; 5) secondary services. Verify backups are clean before restoring after a malware event.

6. Manual operations fallback

Paper travelers and printed schedules held at each cell. Shipping uses manual packing lists. Receiving logs to a spreadsheet until ERP returns.

7. Recovery steps and verification

Step	Action	Owner	Target time	Done
1	Isolate affected systems and preserve logs
2	Confirm which backup set to restore
3	Restore network and authentication
4	Restore ERP database and application tier
5	Run ERP smoke test: log in, view order, post a test receipt
6	Restore MES and plant interfaces, verify scanner and label printing
7	Reconcile transactions entered during the outage
8	Notify users and customers that service is restored

8. Communication

The communications lead informs plant management, customers with open shipments, key suppliers and, where required, regulators and insurers. Use a channel that does not depend on the affected systems, such as personal mobile phones or an external messaging service. Keep a time-stamped log of decisions.

9. Testing and maintenance

Test frequency: Twice a year. Each test records the date, scenario, actual restore times against RTO and RPO, problems found and owners for fixes. Review this plan after any major change to the ERP, network, plant systems or key staff.

Approvals

IT Manager / Date

Plant Manager / Date

Finance or Risk owner / Date

A starting point to adapt, not legal or insurance advice. Insert your real RTO and RPO values based on the cost of downtime, and test the plan with an actual restore. Keep a printed copy offsite because the plan is no use if it is stored only on the failed server.

Optional review of your DR plan

Send us your completed plan and we will comment on gaps in the ERP and plant recovery sequence.

Optional. The tool and every export work without this. No spam.

How to use the template

Complete the fields at the top, then edit the tables for your own systems and people. Start with recovery objectives: agree with plant and finance leaders how long each system can be down (RTO) and how much recent data you can afford to lose (RPO). Those numbers drive backup design and cost. Print the final document and store copies offsite, because the soft copy may be on the server that failed.

Get plant and finance sign-off on RTO and RPO
Name a backup person for every role
Keep a printed contact list that works without email

The thinking behind the structure

The plan follows common IT continuity practice: define scope, set recovery objectives per system, assign roles, define when a disaster is declared, restore in dependency order, communicate, and test. Dependency order matters in manufacturing: authentication and network must return before the ERP database, and the ERP before integrations such as MES, EDI and label printing. The manual fallback section recognises that production often continues on paper while systems recover.

Checking your plan against reality

A plan is only credible if restore times were measured. Run a test restore of the ERP database to a spare server and write down the elapsed time, then compare it with the RTO. Test that a user can log in, view an order and post a receipt. Check that you can find licence keys, service accounts and vendor contacts without the failed systems. Many plans fail on small items such as an encryption key stored on the server that burned.

Common mistakes

Common failures include RTO values that nobody agreed to, backups that were never restored, and a recovery site that lacks the licences or capacity to run the ERP. Another is ignoring the plant: scanners, label printers and SCADA servers are often outside the IT backup scope. Teams also forget to plan the return of data entered on paper, which needs a reconciliation step. Review the plan after every major system change.

Frequently Asked Questions

What is the difference between RTO and RPO?

RTO is how long a system can be unavailable before the impact is unacceptable. RPO is how much recent data you can afford to lose, measured as time. An RPO of one hour means backups or replication must capture changes at least hourly.

How is a DR plan different from a backup policy?

Backups are one ingredient. A DR plan covers the people, order of recovery, decisions, communication and testing that turn backups into a working service again. Without it, teams lose hours deciding what to do first.

How often should we test the plan?

At least yearly for a full scenario and more often for restore tests of critical systems such as the ERP database. Test after major changes to infrastructure, cloud services or the ERP version.

Does this template meet ISO 27001 or customer audit requirements?

It provides a structure commonly expected in such audits, but each standard and customer has its own wording and evidence needs. Treat it as a starting document and adapt it with your auditor or compliance owner.

If you want help turning this plan into tested runbooks for your ERP, Netray can review your ERP recovery steps and automate verification checks. We work with partner ERP specialists where needed.

Talk to an Expert Explore More Free Tools

Related Tools

ERP Operations

More ERP Operations tools

See all

Back to All Tools