IT Disaster Recovery Planning for Small Irish Businesses

Cyber attacks, a failed server, or a flooded office can stop work far faster than most owners expect. IT disaster recovery gives your business a practical route back, with clear priorities, usable backups, and named people who know what to do.

For a small Irish business, a proportionate disaster recovery plan prioritises the systems that keep invoices moving, customers informed, and staff productive. It isn’t an expensive duplicate data centre.

Start by deciding what your business cannot afford to lose, then shape your IT disaster recovery around those priorities.

Key Takeaways

• Build IT disaster recovery around the systems your business cannot afford to lose, rather than treating every application as equally urgent.
• Set realistic recovery time objectives (RTOs) and recovery point objectives (RPOs), then match them with achievable backup, restoration and authentication processes.
• Keep separate, protected backups using the 3-2-1 principle, with immutable or offline copies that ransomware cannot easily alter or delete.
• Write short recovery playbooks with named decision-makers, restoration priorities, communication steps and failback instructions.
• Test restores regularly, including logins, permissions, integrations and business processes, and update the plan after major changes or incidents.

What IT disaster recovery covers, and what it does not

IT disaster recovery is the technology-focused part of business continuity. It covers restoring data, software applications, devices, internet access and communications after an incident.

Business continuity is wider. It includes how staff will work, how you will speak to customers, whether suppliers can still deliver, and how the business operates during disruption. A good continuity plan may say that staff can work remotely. The disaster recovery plan explains how they can securely access email, files, phones and business systems.

Recovery starts with real business priorities

A payroll platform, accounts package, customer database, shared files and email rarely have the same urgency. Regulatory compliance may affect these priorities too, but this article offers practical guidance, not legal advice. Treating every system as equally urgent wastes money and creates confusion during an incident.

For example, a small logistics firm may need its transport management system within two hours, while archived delivery records can wait until the next day. A dental practice may need appointment information quickly, but can temporarily use a paper diary if necessary.

Disasters are wider than fires and floods

Ransomware is a common trigger, but recovery planning must also cover everyday mishaps. A member of staff can delete a SharePoint folder, a laptop can fail before files sync, or a cloud supplier can suffer an outage.

Power loss and flooding matter too, as do other natural disasters. A server stored under a leaking roof, or a broadband router without battery backup, can bring an office to a halt. Use a risk assessment to rank likely threats, business impact and existing controls before choosing recovery measures.

The NIST contingency planning guide remains a useful reference for separating technical recovery tasks from the broader business response. It supports contingency planning, but does not replace an Irish or sector-specific assessment.

Map systems before choosing technology

Buying more cloud storage does not fix an unknown dependency. Good IT disaster recovery starts by mapping the business’s IT infrastructure before buying more storage or other technology.

Include SaaS applications, local servers, network equipment, laptops, mobile phones, printers, identity services, internet connections, payment terminals, and third-party support contacts. Map their application dependencies across SaaS tools, identity services, staff phones, broadband, and payment systems. For example, a cloud accounting tool may depend on email for password resets, multi-factor authentication on a staff phone, and a working broadband connection.

Run a short business impact analysis

Ask each department what stops when a system is unavailable. Then record the financial, legal, operational, and customer effect after two hours, one day, and several days.

Use a simple spreadsheet as the system register. Its columns should cover:

• The system owner and a deputy who can make decisions if they are unavailable.
• Its business purpose, users, data held, and key technical dependencies.
• The consequences after two hours, one day, and several days, plus the maximum tolerable downtime.
• The maximum tolerable data loss, meaning the recently created or changed information the business can afford to lose.
• Where backups sit, who can access them, the restoration method, supplier contracts, support numbers, licence details, and renewal dates.

Store the register independently of the production systems it describes. Keep a printed copy in a secure location and an encrypted copy off-site.

Put systems into recovery tiers

Tiering prevents an expensive plan from trying to restore everything at once. Place customer-facing and revenue-critical systems first, followed by core operations, supporting tools, and archives. Use these tiers to set the restoration order in the disaster recovery plan.

A backup is only useful when the business can locate it, access it, and restore it under pressure.

This exercise often exposes simple weaknesses. For instance, one director may hold the only administrator account, or a broadband router may be the single route to all cloud services.

Set recovery time and data loss limits

Two measures turn vague expectations into workable decisions: RTO and RPO. They sound technical, but both are simple business choices within IT disaster recovery.

The recovery time objective, or RTO, measures acceptable system downtime. The recovery point objective, or RPO, sets the maximum recent data loss the business can afford.

Match backup frequency to the RPO

If a business can lose no more than four hours of order data, it needs backups or replication at least every four hours. A nightly backup does not meet that target.

Likewise, an RTO of two hours means the team needs a proven way to restore service within two hours. Downloading hundreds of gigabytes over a slow connection may take far longer.

Compare each RTO with actual download, restore and authentication times. Compare each RPO with backup or replication frequency. This shows whether the targets are achievable in practice.

The examples below are illustrative. Validate them with staff, suppliers and customers before adopting them.

These targets are business decisions, not vendor promises, and should reflect actual consequences rather than a hopeful promise made during a crisis.

Spend money where downtime costs more

A small manufacturer may accept a day without a staff intranet. It may not accept a day without production files or shipping labels. A second internet connection, a spare firewall, or high availability may be justified for systems with a short RTO. Such measures can reduce interruption for a critical service, but they don’t replace independent backups.

For less urgent systems, a lower-cost backup and manual workaround may be enough. Most small businesses don’t need multiple backup sites; a tested local recovery route plus a suitable off-site or cloud copy may be more affordable. The best approach is proportionate to the business, rather than built around the most expensive option.

Build backups that survive ransomware

For IT disaster recovery, the 3-2-1 principle is a sensible minimum for data backup. Keep three copies of important data, on two different types of storage, with one copy off-site.

For a small office, that could mean live data in Microsoft 365 or a server, a local encrypted backup for rapid restores, and a separate cloud or offline copy. Cloud-hosted files and SaaS services still need independent recovery arrangements as part of cloud disaster recovery. Accidental deletion, ransomware sync, retention rules, or account compromise can affect them.

The CISA 3-2-1 backup guidance gives a clear explanation of this approach. A small business usually needs one resilient off-site copy, not several dedicated backup sites. That secondary location could be a reputable EU-hosted provider or secure offline media stored away from the office.

Use immutable or offline copies

Ransomware often targets backup folders and administrator accounts. Snapshot replication can copy corruption or ransomware quickly, so pair it with versioned, immutable or offline recovery points. An immutable backup cannot be changed or deleted for a set retention period. An offline copy is disconnected when it is not actively backing up.

Neither option removes the need for good access controls. Limit backup administration rights, use multi-factor authentication, and keep credentials separate from day-to-day email accounts. Encryption, restricted access and sensible retention support data protection responsibilities under GDPR when backups contain personal data.

For a ransomware incident, disconnect affected machines from the network, preserve evidence, contact your IT provider, and avoid restoring files until the infection route is understood. Restoring too early can place the same malware back into a clean environment.

Cover accidental deletion and hardware failure

Version history can restore a deleted document quickly, but it may not protect a full system or a large folder deletion discovered weeks later. Test retention periods for Microsoft 365, Google Workspace and document management platforms, confirming that older versions can be restored.

Hardware failure needs a different response, so record device specifications, who has encryption-key access, software licences, and supplier details. A spare laptop checklist should cover approved security tools, current patches, required accounts, and a charger. It can get an administrator or customer service worker back online while a replacement arrives.

Write a recovery plan people can use at 3am

A useful IT disaster recovery plan is a short operational document, not a long policy. It should be detailed enough to prevent guesswork under stress. Store a printed copy and a digital version securely, somewhere that doesn’t rely on the failed system.

Create clear incident playbooks

Write separate playbooks for ransomware, server failure, accidental data deletion, cloud service outage, and loss of office power or access. Each one should set out the first incident response actions, escalation route, decision-maker, evidence to preserve, and customer communication process.

For a cloud outage, staff may need a temporary email address, a phone diversion, and a manual order process. For flooding or power loss, safety comes first. Don’t send staff into a damaged building to retrieve equipment.

Your recovery procedures should also include a one-page playbook checklist:

1. Name the person who declares the incident and contacts the IT provider and insurer. Keep a call list for directors, IT support, internet providers, software suppliers, and key customers.
2. Record which systems to isolate, along with administrator accounts, password-vault access, MFA recovery methods, and encryption keys.
3. State how customers are updated and where manual order forms are stored.
4. Set a restoration order that puts dependent services before applications.
5. Name the person who approves restoration and signs off that systems work before users return to normal work.

Plan failback before a failure occurs

Failover means switching work to a backup environment using failover mechanisms. A small firm may fail over to a provider-hosted environment or alternate workspace rather than maintain costly dedicated backup sites. Failback means returning safely to the main system afterwards. Businesses often document the first part and forget the second.

Before failing back, compare records created during the outage, check that data has synchronised, confirm users can log in, and agree a cutover time. Keep the backup environment available until the business owner signs off. Otherwise, you risk losing orders created during recovery.

Test recovery, rather than trusting a green tick

Backup software may report success even when a backup is incomplete, encrypted with an unavailable key, or impossible to restore within the RTO. Testing is where assumptions become facts and shows whether IT disaster recovery works in practice.

Start with one controlled sample-file restore every quarter. Restore a full application or server, including virtual machines where used, in an isolated test environment at least once a year. Time each stage against the RTO and confirm recovered data against the RPO. Keep a written issue log recording what failed, what needs updating, the owner, and the deadline. Make it a cycle of continuous testing after major changes, incidents, and supplier updates.

Test the whole chain

A recovery test should cover more than data. Check user logins, multi-factor authentication, printing, integrations, email alerts, shared folders, permissions, and the ability to process a sample order or invoice.

A retail business might restore its stock system into an isolated test environment and process a sample sale. A professional services firm could retrieve a closed client matter and confirm that permissions still apply.

The Irish National Cyber Security Centre publishes cybersecurity guidance documents that can help small organisations strengthen their wider security arrangements.

Choose providers with recovery evidence

Managed IT providers and suppliers offering disaster recovery as a service can reduce the cost of maintaining duplicate hardware. They don’t, however, take responsibility for choosing recovery targets, checking contracts, or testing restores.

Evaluate whether the contract provides complete backup and recovery, rather than storage-only provision. Request written RTO and RPO commitments, data location details, retention periods, restoration fees, support hours, encryption arrangements, exit terms, ownership, and recent test evidence.

Ask whether the supplier’s data backup service can restore individual files, whole systems, and Microsoft 365 data, because these are different services. Ask who owns the backup data and how you’ll retrieve it if you change provider.

Request a low-cost test restore before signing or renewing. A low monthly price means little if a full restore costs thousands of euro or takes days.

Irish and EU obligations after a data incident

Recovery and legal reporting often run at the same time. Consider regulatory compliance, contractual duties and sector obligations alongside restoration priorities. Keep an incident log recording when the issue began, when the business became aware, affected systems and data categories, approximate numbers of people or records, actions and containment steps, processor involvement, notification decisions, and supporting evidence.

Where a personal data breach is likely to risk individuals, the controller must notify the DPC without undue delay and, where feasible, within 72 hours of becoming aware of it. This 72-hour period concerns awareness of the breach, not necessarily completion of the technical investigation. The DPC’s breach notification guidance explains the process. Keep records even where notification is not required.

Do not treat every outage as a reportable breach

A power cut with no personal data exposure is not automatically a GDPR breach or a reportable incident. Equally, ransomware may be reportable if it affects the confidentiality, integrity or availability of personal data.

If the breach is likely to create a high risk to people, the organisation may also need to tell those affected without undue delay. Check current Irish guidance and speak to the DPC, a qualified data protection adviser, or a solicitor when facts are unclear, especially in healthcare, financial services, transport, or other regulated sectors. This is general information, not legal advice.

NIS2 obligations can apply based on sector, size, and national implementation or designation. Most micro and small firms are not automatically in scope, but do not assume an exemption. Small suppliers may still face contractual security requirements or be indirectly affected when serving a larger regulated customer. Check current Irish guidance and obtain specialist advice if your organisation provides services in a covered sector or supplies a larger regulated customer.

Frequently Asked Questions

What is IT disaster recovery?

IT disaster recovery is the technology-focused process of restoring data, applications, devices, communications and connectivity after an incident. It supports wider business continuity, which also covers staff, customers, suppliers and day-to-day operations.

How often should a small business back up its data?

Backup frequency should match the business’s recovery point objective (RPO), meaning the maximum recent data loss it can tolerate. If the business can lose no more than four hours of order data, backups or replication should run at least every four hours.

Is cloud storage enough for disaster recovery?

Cloud storage alone may not protect against accidental deletion, ransomware, account compromise or a cloud provider outage. Keep an independent recovery arrangement, such as a local encrypted backup combined with a separate off-site, immutable or offline copy.

How often should disaster recovery plans be tested?

Test a controlled sample-file restore at least quarterly and a full application or server recovery at least annually. Test the whole chain, including user logins, MFA, permissions, integrations and the ability to complete a sample business transaction.

Does every cyber incident need to be reported to the DPC?

No. An outage is not automatically a reportable personal data breach, but ransomware or another incident may require notification if it affects personal data and is likely to risk individuals. Keep an incident record and seek current DPC or specialist advice when the facts are unclear.

Keep recovery plans alive

A sound recovery plan protects the work that keeps your business open. It sets priorities, honest recovery targets, separate backups, and calm, clear instructions. Your disaster recovery plan is a living document, changing as systems, suppliers, and staff change.

Floodwater, ransomware, and a deleted folder demand different responses. Yet each exposes the same question: can you restore the right data, in the right order, within the time your business can tolerate? That is operational resilience in practice: continuing essential work with a tested, affordable arrangement, not an elaborate plan nobody can follow.

IT disaster recovery stays current when reviewed after major system or supplier changes, incidents, or tests, with an owner and date recorded.