A cyber attack does not become a business crisis only when systems are encrypted or accounts are compromised. It becomes a crisis when people do not know which services to restore first, who can approve emergency spending, how staff should communicate, or whether the latest backup can be trusted. A business continuity plan after cyber attack gives your organisation a workable route through those decisions while protecting customers, revenue and confidence.
For Irish businesses, this is not simply an IT document. It is an operational plan covering the people, suppliers, data and systems needed to continue serving customers. The best plans are clear enough for an office manager or managing director to use under pressure, while giving internal IT teams and external specialists the technical detail needed to act quickly.
Start with business impact, not technology
Many continuity plans begin with a list of servers, laptops and software. That inventory matters, but it is not the starting point. First identify the activities that cannot stop for long without causing serious commercial, legal or safety consequences.
For one business, that may be taking customer orders and processing payments. For another, it may be accessing production schedules, dispatching field teams, issuing payroll or communicating securely with clients. A professional services firm may need access to case files and email, while a multi-site organisation may depend on its internet connection, phones and line-of-business applications at every location.
For each critical activity, agree a realistic maximum period of disruption. This is often called a recovery time objective. Then define how much data loss is acceptable, known as a recovery point objective. A finance system may need recovery to the previous hour; archived marketing files may reasonably be restored from the previous day.
These decisions involve trade-offs. Near-instant recovery and highly frequent backups cost more than a standard overnight backup arrangement. The right answer depends on the cost of downtime, the sensitivity of the information involved and the expectations your customers place on you. The key is to make those choices before an incident, rather than during it.
Separate incident response from continuity and disaster recovery
A cyber incident response plan focuses on containing and investigating the attack. It sets out who isolates affected devices, preserves evidence, engages specialist support and determines how the attacker gained access. A disaster recovery plan focuses on restoring systems, data and infrastructure.
Business continuity sits across both. It asks how the company will operate while that work is taking place. Can staff take orders manually? Can a secure alternative communications channel be used? Can payroll be processed from a clean environment? Can a temporary workspace support a critical team if a site network is unavailable?
These plans should work together, but they should not be treated as interchangeable. Rebuilding a server does not automatically mean the business can resume normal operations. Equally, asking staff to use personal email or unapproved file-sharing services may keep work moving briefly while creating a further security and data protection problem.
Build a business continuity plan after cyber attack around decisions
A useful plan assigns authority as well as tasks. During a ransomware event or major account compromise, staff need to know who is leading the response, who has the authority to take systems offline, and who can approve specialist support, replacement equipment or emergency cloud capacity.
Create a small incident management team with named primary and deputy contacts. It should typically include a senior business decision-maker, the person responsible for IT, an operations lead, a communications lead and someone responsible for data protection or legal advice. Record personal contact details outside the affected network, with a printed copy held securely where appropriate.
The plan should also define clear escalation points. For example, an alert from endpoint protection may need technical investigation, while evidence of encrypted shared files, fraudulent payments or customer data exposure should trigger immediate executive involvement. Avoid vague instructions such as “notify management as soon as possible”. State who must be contacted, in what order, and how quickly.
Put people and communications first
Technical recovery can take hours or days. Poor communication can cause damage within minutes. Employees need simple instructions on what to do when they suspect an attack: stop using the affected device if advised, do not delete emails or files, do not attempt a fix themselves, and report the issue through an agreed channel.
Prepare communication templates for staff, customers, suppliers and insurers. They should not speculate about the cause or scale of an incident. Early messages can acknowledge a service issue, explain the practical impact and set expectations for the next update. Consistent communication protects trust and reduces the risk of different teams providing conflicting information.
If personal data may have been exposed, the organisation may also have obligations under data protection law. Where a breach is likely to pose a risk to individuals’ rights and freedoms, notification to the Data Protection Commission may be required within 72 hours of becoming aware of it. Your plan should include a route to legal and data protection advice, rather than assuming that every cyber incident requires the same response.
Make backups recoverable, not merely present
A backup report showing a successful job is not proof that your business can recover. Attackers increasingly target backup systems, administrator accounts and cloud file repositories because they know recovery is the business’s strongest protection against extortion.
A sound approach keeps more than one copy of important data, with at least one copy isolated from the main environment. It should include servers, cloud data, critical applications, configurations and, where necessary, the devices required to run specialist software. Microsoft 365 provides valuable collaboration tools, but retention and native recovery options do not always meet an organisation’s complete backup and continuity requirements.
Recovery testing is where assumptions become facts. Test whether data can be restored, how long it takes, whether permissions return correctly and whether a restored application works with connected services. Run a scenario in which administrator credentials have been compromised. Can the recovery process still be controlled from a clean account and a separate management environment?
Document the order of restoration. In many cases, identity services, network security, connectivity and core file access must be restored before business applications can function. However, the correct sequence should be based on the impact assessment, not on which system happens to be easiest to rebuild.
Plan for clean recovery environments
Restoring infected systems too quickly can reintroduce the attacker. The recovery section of your plan should require a decision on when an environment is safe to bring back into service. That normally involves resetting privileged credentials, reviewing access controls, patching known weaknesses and checking for malicious persistence before reconnecting systems.
A clean recovery environment may be a separate network, replacement hardware, a cloud-based recovery platform or a combination of these. The approach depends on your size, infrastructure and recovery objectives. A small business may prioritise secure cloud access and replacement laptops, while a complex enterprise may need segregated networks, replicated infrastructure and coordinated recovery across several sites.
Do not overlook ordinary equipment. If staff cannot securely access email, phones, printers, Wi-Fi or line-of-business systems, a technically successful server recovery may still leave operations at a standstill. Keep an up-to-date register of hardware, licences, supplier contacts and network diagrams so replacement and configuration work can begin without delay.
Test the plan with realistic scenarios
A continuity plan that has not been tested is a set of good intentions. Testing does not always require a full shutdown. Start with a structured tabletop exercise where the incident team works through a ransomware scenario, a compromised Microsoft 365 account or an outage at a key supplier.
Ask practical questions. How would staff receive instructions if email is unavailable? Who can contact the bank if a payment system is affected? Can your organisation identify the latest clean backup? What would customer-facing teams say if services were limited for two days?
Then test technical recovery in stages. Restore a sample of critical data, validate a key application in an isolated environment and rehearse a communications escalation. Record what took longer than expected, what information was missing and where decision-making became unclear. Update the plan after each exercise and after every significant technology, office or supplier change.
Treat continuity as an operational responsibility
Cyber resilience is not achieved by buying a security tool and filing away a policy. It comes from knowing what matters most to the business, protecting the routes back to operation and practising the decisions that must be made under pressure.
For organisations without a large internal IT function, an experienced managed services partner can help turn technical backup, security monitoring, cloud services and recovery processes into a plan the whole business can use. LANCAST works with businesses to make IT more dependable, practical and ready for the moments when continuity matters most.
The most valuable outcome is not a thick document. It is the confidence that, if an attack interrupts normal operations tomorrow morning, your people know how to keep the business moving safely.