A textile factory in the Vale do Ave with 120 employees lost 14 hours of production because the backup server had been switched off for three months — no one had tested whether the recovery plan actually worked. The problem is not rare: in 2024, CERT.PT recorded 2,758 cybersecurity incidents in Portugal, a 36% increase compared to 2023, and around 78% occurred in private entities. Disaster recovery is not a document filed away in a folder. It is a set of procedures that are only worth anything if they are rehearsed before the crisis. This guide offers a checklist of 16 practical controls to audit your recovery plan in 4 hours, identify failures and document what to test each quarter.
What you need before you start
Before auditing the plan, confirm that you have these five elements in place: a complete inventory of critical systems (ERP, WMS, POS, BI, email, shared files, IoT machines connected to the network); documentation of dependencies — which system, if it goes down, paralyses operations in less than 2 hours; up-to-date emergency contacts (infrastructure provider, backup manager, IT lead, operations director, financial director); a definition of RTO (maximum tolerable downtime) and RPO (maximum amount of data you can lose) for each system; access to an isolated test environment where you can simulate a recovery without affecting production.
Step 1: Audit the backup infrastructure
Start here. Without valid backups, there is no possible recovery. Check that backups are being run every day. Access the backup tool's log history — look for silent failures: tasks marked as "success" but with 0 bytes copied. This happens frequently when the storage unit is full or switched off, and the software does not raise an alert because the scheduler did not technically fail — it simply copied nothing.
Confirm that at least one offline copy exists (external disk, tape, or cloud disconnected from the main system). An online copy only protects against software failures, not against ransomware or sabotage. If an attacker gains access to your datacenter, they can delete all online backups in minutes — a physical copy in a safe or in a cloud with immutable retention is the only defence.
Test access to the backups: can you restore a file from 30 days ago? Can you list the contents of a backup from 6 months ago without restoring everything? Validate integrity — does the backup tool perform checksum or CRC verification? If not, a backup may be corrupted and you will only find out when you need it. Finally, document the restore time: how long does it take to restore a 50 GB database? And an entire virtual machine? Write down the figures — do not estimate.
A backup that has never been restored is just a file taking up disk space.
Step 2: Validate the RTO and RPO of each critical system
RTO and RPO define what can fail and for how long. If you have not defined them, the recovery plan is speculation. Fill in this table with your systems — if you cannot define a realistic RTO, it means the system is more critical than you thought and you should consider active redundancy.
| System | RTO (maximum downtime) | RPO (maximum data loss) | Recovery strategy | Tested on (date) |
|---|---|---|---|---|
| ERP (MULTI, QAD) | 4 hours | 1 hour | Backup restore + DB replication | — |
| WMS / KORA Inventory | 2 hours | 30 minutes | Failover to secondary server | — |
| POS / MAXIRETAIL | 1 hour | 15 minutes | Local offline mode + subsequent synchronisation | — |
| Corporate email | 8 hours | 4 hours | Email backup restore | — |
| Shared files | 6 hours | 1 hour | Snapshot or incremental backup restore | — |
Step 3: Test data restoration in an isolated environment
This is the heart of the test. Do not skip it. Choose a backup from 2-3 weeks ago and restore it to a test server — never to production. Document the exact start and end time. Validate data integrity: does the restored database pass the consistency tests (DBCC CHECKDB on SQL Server, CHECK TABLE on MySQL)? Are the indexes intact?
Test the application against the restored data. Can you log in? Can you look up a sales order from 2 months ago? Can you generate an invoice? Simulate a disk failure: remove the backup disk (or simulate a network drop) and try to restore. How long does it take to detect the failure? How long does it take to switch to the secondary backup? Record everything — start time, end time, errors encountered, time for each phase (file copy, DB initialisation, data validation, application tests). This record is your proof that the procedure works.
Step 4: Audit the procedure documentation
Written procedures are only worth anything if they are clear enough for a new technician to follow them without help. Open your disaster recovery manual. Can a new technician restore the ERP in 3 hours by following only the document? Test it: ask someone who does not work in IT to read the procedure and say whether they can follow it. Check that the procedure includes prerequisites (software, credentials, access), numbered and sequential steps, exact commands (not "run the restore script" — give the full path to the file), estimated time for each phase, support contacts if something fails.
Confirm that the procedure is up to date. If your ERP was updated 6 months ago, was the recovery procedure also revised? If not, it is obsolete. Document the dependencies: "Before restoring the ERP, make sure the SQL database has been restored and is accessible at [IP/hostname]". A common mistake is to leave the procedure in the hands of a single technician — if that technician leaves the company or falls ill on the day of the crisis, no one can recover anything.
Step 5: Test network and communications failover
Data recovery is useless if the team cannot communicate or access the systems. Simulate an internet outage: switch off the main router and confirm that access to the internal network still works. Can users access the ERP via an emergency VPN? Test emergency communication — can employees receive an SMS or WhatsApp message if email goes down? Do you have a written communication plan (who alerts whom, and in what order)?
Validate remote access: if the factory loses physical access (fire, flood), can the IT manager access the servers remotely? Do you have emergency access credentials (not dependent on the AD, which may be offline)? Test connectivity with critical suppliers — if your ERP integrates with a customer's or supplier's system via API or EDI, can the integration recover automatically after an outage?
Step 6: Simulate a complete crisis scenario (mandatory annual test)
Once a year, run an end-to-end test. Set aside a Saturday or Sunday. Simulate a real failure: the main production server has failed completely. Objective: recover the ERP, WMS and email in less than 6 hours. Start time: 09:00. Deadline: 15:00.
Gather the team (IT, operations, finance). Each person has a defined role in the recovery procedure. No one improvises. Document each decision: "At 09:15 we decided to restore from yesterday's backup because today's backup was corrupted. Impact: we lost 8 hours of sales data." After the test, gather the team and identify what failed: incomplete procedures, out-of-date contacts, recovery software that did not work, missing credentials, undocumented dependencies. Update the plan with the lessons learned. Mark the date of the next test on the calendar.
Step 7: Regulatory compliance and auditing
NIS2 requires medium and large companies in critical sectors (including industry) to have a tested business continuity plan. Decree-Law No. 65/2025, which transposes Directive (EU) 2022/2555, requires evidence of testing — this is not optional. Confirm that your recovery plan is documented and that it has been tested at least once in the last 12 months.
If you have ISO 27001 certification, your auditor will ask: "When was the last disaster recovery test? What was the result?" If you have no record, you fail the audit. Document who approved the plan: CEO, CFO, operations director. Digital signatures via Chave Móvel Digital or qualified signatures count towards compliance. Keep a test record: date, scenario, duration, failures found, corrective actions, who tested. This record is your proof of due diligence before an auditor or a regulatory authority.
Checklist of 16 controls — use this in tomorrow's meeting
| Control | Yes | No | Partial | Corrective action |
|---|---|---|---|---|
| Backups run daily (verified in logs) | ☐ | ☐ | ☐ | |
| An offline copy exists (disk, tape or disconnected cloud) | ☐ | ☐ | ☐ | |
| Backup successfully restored in the last 3 months | ☐ | ☐ | ☐ | |
| RTO and RPO defined for each critical system | ☐ | ☐ | ☐ | |
| Recovery procedure documented and up to date | ☐ | ☐ | ☐ | |
| Emergency contacts up to date (IT, provider, management) | ☐ | ☐ | ☐ | |
| Emergency access credentials stored securely (safe, not email) | ☐ | ☐ | ☐ | |
| Data restoration test carried out in an isolated environment | ☐ | ☐ | ☐ | |
| Restore time measured and documented | ☐ | ☐ | ☐ | |
| Backup integrity validated (checksum, DB verification) | ☐ | ☐ | ☐ | |
| Network failover test carried out | ☐ | ☐ | ☐ | |
| Emergency remote access tested (VPN, credentials) | ☐ | ☐ | ☐ | |
| Crisis communication plan documented | ☐ | ☐ | ☐ | |
| Complete recovery test carried out in the last 12 months | ☐ | ☐ | ☐ | |
| Plan approved by CEO, CFO and operations director (signed) | ☐ | ☐ | ☐ | |
| Test record kept and accessible to auditors | ☐ | ☐ | ☐ |
Fill in this table in a meeting with IT, operations and management. If more than three controls are marked as "No" or "Partial", your recovery plan is not ready — set aside two 2-week sprints to fix the essentials. Start with the backup controls (rows 1-3), then the tests (rows 8-9), then the documentation (rows 5-6). The rest follows.
Frequently asked questions
What is disaster recovery and why is it important to test it?
Disaster recovery is a set of procedures for recovering systems and data after a critical failure. It is not a document filed away in a folder — it only works if it is tested regularly. The article gives the example of a textile factory that lost 14 hours of production because the backup server had been switched off for three months and no one had validated the plan.
What are the five essential elements before auditing the plan?
A complete inventory of critical systems (ERP, WMS, POS, BI, email, shared files); documentation of dependencies between systems; up-to-date emergency contacts (infrastructure provider, backup manager, IT lead, operations and financial directors); a definition of RTO and RPO for each system; and access to an isolated test environment to simulate recoveries without affecting production.
What do RTO and RPO mean and how do you define them?
RTO is the maximum tolerable downtime; RPO is the maximum amount of data you can lose. The article recommends filling in a table with each critical system. For example, an ERP might have an RTO of 4 hours and an RPO of 1 hour. If you cannot define a realistic RTO, it means the system is more critical and you should consider active redundancy.
Why is it important to have an offline backup copy?
An online copy only protects against software failures. If an attacker gains access to the datacenter, they can delete all online backups in minutes. A physical copy in a safe or in a cloud with immutable retention is the only defence against ransomware or sabotage.
How do you test whether a backup really works?
Choose a backup from 2-3 weeks ago and restore it to an isolated test server. Document the exact start and end time. Validate data integrity (database consistency tests), test the application (login, queries, document generation) and record all errors encountered and the time for each phase.
What is the most common mistake in recovery procedures?
Leaving the procedure in the hands of a single technician. If that technician leaves the company or falls ill on the day of the crisis, no one can recover anything. Procedures should be clear enough for a new technician to follow them without help, with numbered steps, exact commands and support contacts.
How long should a complete audit of the disaster recovery plan take?
The article offers a checklist of 16 practical controls that you can complete in 4 hours. This time allows you to identify failures and document what to test each quarter, without the need for prolonged intervention in operations.
Sources
- CERT.PT — Report on Cybersecurity Incidents in Portugal 2024 (Instituto Nacional de Cibersegurança)
- Standard ISO/IEC 27031:2021 — Guidelines for information and communication technology readiness for business continuity
- Directive (EU) 2022/2555 (NIS2) — Network and Information Security Directive, operational continuity requirements for critical entities
- ENISA — Guidelines on Disaster Recovery and Business Continuity (European Union Agency for Cybersecurity)
- Banco de Portugal — Recommendations on Business Continuity Plans for Financial Institutions (Circular 4/2020)