A suspicious Microsoft 365 login, an employee reporting a convincing invoice email, or files suddenly becoming unreadable can turn into a business-wide disruption within minutes. This cyber incident response guide gives SME leaders a practical framework for making calm, informed decisions when systems, data or communications may be under attack.
The aim is not to make every business owner a security specialist. It is to ensure the right people know what to do first, who can make decisions, and how to restore operations without making the incident worse. Good response limits downtime, protects evidence and helps preserve customer trust.
What counts as a cyber incident?
A cyber incident is any event that threatens the confidentiality, integrity or availability of your systems and information. That includes ransomware, compromised email accounts, fraudulent payment requests, unauthorised access to cloud platforms, lost devices, malware infections and denial-of-service attacks.
Not every alert is a major breach. A blocked phishing email may need only routine review, while a staff member entering credentials into a fake sign-in page can require urgent action. The difficulty is that the early signs are often unclear. Treat credible reports seriously until an informed technical assessment says otherwise.
The first objective is simple: stop the situation spreading while keeping the business able to operate where it is safe to do so.
Build your cyber incident response guide before trouble starts
A response plan is most useful when it is short, current and understood. A lengthy policy buried in a shared folder will not help an office manager facing a ransomware note at 8.30 on a Monday morning.
Your plan should name an incident lead with authority to make immediate decisions. For many SMEs, this may be a director, operations lead or internal IT administrator supported by a managed IT provider. It should also identify a deputy, key contacts, critical suppliers, cyber insurance details and the location of backup credentials.
Define what matters most to the business. For a professional services firm, email, client documents and line-of-business software may be essential. For a retailer, card payments, stock systems and connectivity may take priority. A recovery plan cannot sensibly restore everything at once, so rank services by the impact of their loss.
Keep a printed or securely offline copy of essential contacts and procedures. If email, cloud storage or phones are affected, the information held only in those systems may be unavailable when it is needed most.
Agree incident severity levels
Simple severity levels prevent both underreaction and panic. A single suspicious email can be logged and monitored. A confirmed account compromise should trigger password resets, session revocation and investigation. An event affecting several users, financial data, customer records or a core service should be treated as a major incident and escalated immediately.
The exact thresholds depend on your business, but the decision process should be clear. Staff need permission to report concerns early without worrying that they are creating unnecessary work.
The first hour: contain, preserve, assess
The first hour is about control, not finding every answer. Do not delete files, reboot affected machines repeatedly or allow staff to keep investigating from their own accounts. Well-meaning actions can destroy useful evidence or enable an attacker to move further through the network.
Take these immediate actions when a credible incident is identified:
- Record the time, reporter, affected user, device, system and visible symptoms.
- Isolate potentially affected devices from Wi-Fi and wired networks where safe to do so.
- Contact your IT security support provider or designated incident lead using a known, trusted number.
- Secure privileged accounts by changing passwords from a clean device and revoking active sessions where compromise is suspected.
- Pause unusual payments, supplier bank-detail changes and large data transfers until they can be verified.
Isolation does not always mean switching everything off. If a server is actively encrypting files, rapid network isolation may be necessary. If there is evidence of unauthorised cloud access, preserving logs and cutting off attacker sessions may be more valuable than shutting down every workstation. This is where experienced technical support helps: the right action depends on the threat, the systems involved and the risk of further damage.
Preserve evidence without delaying protection
Keep a written timeline from the start. Note what happened, when it was noticed, who took action and what changed. Save suspicious emails, screenshots of alerts, authentication logs and details of any calls or messages connected to the event.
Evidence supports technical investigation, insurance claims and any legal or regulatory reporting that may follow. However, preserving evidence should never become a reason to leave a live threat active. Containment comes first where there is a clear risk to systems or data.
Communicate clearly and avoid speculation
Poor communication can create a second incident. Staff may continue using compromised accounts, customers may receive inconsistent messages, or a director may share details before the facts are known.
Set up a small incident team covering business leadership, IT, operations and communications. Give staff practical instructions, such as not using a particular system, reporting suspicious messages, or using an alternative process for payments. Keep the message factual and avoid blaming individuals. People report faster when they know they will be supported.
External communication requires more care. If personal data may have been exposed, your business may have reporting obligations under UK GDPR or, for Irish organisations, the GDPR and relevant supervisory authority requirements. The need to notify customers, insurers, banks, regulators or law enforcement will depend on what happened and the likely impact. Seek appropriate legal, insurance and specialist guidance rather than making assumptions.
A timely, honest update is usually better than silence when customers are directly affected. It should explain what is known, what action is being taken and what recipients should do next. Do not promise a restoration time or confirm data loss until the investigation supports it.
Recover services safely, not just quickly
Getting systems back online is the visible part of incident response, but hurried recovery can reintroduce the attacker. Before restoring data, establish the likely entry point and check that it has been closed. This may involve removing malicious software, patching vulnerable systems, resetting credentials, enforcing multi-factor authentication or rebuilding devices from a known clean state.
Backups are central to business continuity, but only if they are usable. Check when the last clean backup was created, whether it is isolated from the affected environment and whether priority systems can be restored within an acceptable timeframe. A backup that has never been tested is a hope, not a recovery plan.
Recovery should follow the priorities agreed in advance. Restore identity and secure access first where needed, then core connectivity, business-critical applications and data. Validate each service before users return to it. Look for unexpected administrator accounts, failed login attempts, unauthorised forwarding rules and suspicious scheduled tasks. These checks take time, but they reduce the risk of a repeat compromise.
For some businesses, temporary workarounds are sensible. Staff may use an approved secondary communication channel, process orders manually or work from a clean cloud environment while systems are restored. The trade-off is productivity against risk. Do not move sensitive data into personal email accounts or unapproved apps simply because the usual platform is unavailable.
Learn from the incident while the details are fresh
Once operations are stable, hold a structured review. This is not about assigning blame. It is about identifying where controls, processes or communication need to improve.
Ask how the incident was detected, whether escalation was fast enough, what made containment difficult and whether backups met recovery expectations. Review the technical root cause as well as the business impact: lost working hours, delayed orders, customer calls, emergency supplier costs and reputational risk.
Turn the findings into owned actions with dates. Examples may include improving email filtering, rolling out multi-factor authentication, separating administrator accounts, tightening payment verification, replacing unsupported devices or running staff phishing awareness sessions. Smaller improvements, completed consistently, often make the greatest difference to resilience.
Make response part of day-to-day resilience
Cyber incident response is not a document to review only after an attack. Test it through short, realistic scenarios. Ask what the team would do if a director’s email account sent fraudulent payment instructions, if a laptop containing customer data went missing, or if cloud files became inaccessible during a busy period.
A managed IT partner can provide practical support here by monitoring systems, maintaining backups, managing patches and being available when a genuine incident needs rapid technical action. For Dublin SMEs without a large in-house IT department, that dependable support can mean the difference between a contained disruption and several days of lost productivity.
The most useful plan is the one your people can follow under pressure. Give them clear authority, reliable technical support and tested recovery options, and an unexpected alert becomes a controlled business response rather than a crisis.
