Ransomware Response Plan for SMEs | Cobweb

Ransomware Response Plan for SMEs: What to Decide Before an Attack

Home » Content Hub » Ransomware Response Plan for SMEs: What to Decide Before an Attack

Most ransomware response plans are written during the attack.

Someone notices files will not open, a ransom note appears, and the first hour goes on working out who is in charge and whether to switch everything off.

A response plan settles those questions beforehand, so the time is spent containing the damage and getting the business working again.

Download our incident response plan template here, or talk to us about ransomware protection and testing or developing your recovery plan.

What is a ransomware response plan?

A ransomware response plan is an agreed set of roles, decisions and actions covering the period between discovering a ransomware incident and returning the business to normal operations.

It should sit alongside your wider cyber incident response plan, as well as your backup and disaster recovery arrangements.

Although preventative controls such as multi-factor authentication, endpoint protection and employee awareness are intended to make an attack less likely to succeed, a response plan answers a different question: what happens if an attacker gets through anyway?

You would of course hope you would never have to use your ransomware response plan, but it’s far better to have one in place if you ever did need to. For an SME, a useful plan should cover five things:

  • who makes decisions
  • how the attack will be contained
  • who needs to be contacted
  • which systems will be recovered first
  • what evidence needs to be preserved

It’s important you also keep it concise and so that it can be understood by everyone in the business.

1. Who leads the response, and how will they communicate?

Who is in charge?

This is the main question your plan should answer. They should have sufficient authority to make decisions quickly, making sure you also have someone as deputy in case that person is unavailable.

If a ransomware incident did occur, decisions involving business operations, IT, customers, employees, insurance, finance and legal obligations will all be considerations – not just technical!
Responsibilities should therefore be agreed for the relevant people across IT, senior management, finance, HR and customer communications.
The next questions is how these people will contact each other – your usual tools may not be an option! If your systems are down, so might email or Teams and so you will need another communication route.

Keeping an offline contact list of internal contacts is vital, including:

  • Your IT/Managed Service Provider and backup providers
  • Your cyber insurer
  • Legal advisors
  • technology suppliers/critical line-of-business software vendors

2. What should happen in the first hour?

Limit further damage

The first hour of a ransomware incident response is about limiting further damage without destroying useful evidence.

After the incident lead has been contacted, affected devices should be isolated from networks (wired-connections/WiFi) as quickly as possible. Where possible, avoid simply wiping or unnecessarily powering down equipment before specialist advice, because information held on compromised systems may help investigators understand what happened.

Isolation is not the same as eradication – you still need to establish how the attacker got in, what they have accessed and whether they have other routes into your system.

Compromised accounts may therefore need to be disabled and credentials reset using a clean device. Your managed service provider or IT provider should investigate suspicious admin accounts, mailbox rules, remote-access software and other changes that might give the attacker continuing access.

Checking backups

Now, you need to check your backups. Confirm your backup copies are isolated and protected from the compromised environment. Do not assume that because backups ran successfully yesterday they are safe today! Your attacker could have targeted your backups because destroying an organisation’s ability to recover increases payment pressure to the ransom.

Take a written account

Finally, start a written timeline.

Record what was discovered by whom, when each decision was made and what action was taken. Keep logs and evidence rather than deleting or altering them. Your timeline can become invaluable for your managed service provider, insurer, legal adviser and any other involved parties.

3. Who needs to be told, and when?

A ransomware attack quickly becomes more than an IT problem. Your response plan should identify organisations and people that may need to know about it, along with who has the authority to contact them.

Contact your cyber insurer

If you have cyber insurance, notify your insurer as early as possible.

Policies can contain specific notification requirements, and insurers may provide or specify incident response, forensic and legal specialists. Before appointing external specialists independently, check your policy so that you understand its requirements.

Keep both the policy information and claims contact details available offline.

Notifying the ICO (Information Commissioners Office)

A ransomware attack can also become a personal data breach.

UK GDPR’s definition of this includes accidental or unlawful destruction, loss or alteration of personal data, as well ad unauthorised disclosure or access. That means losing availability of personal data that can potentially constitute a breach, even where there is no evidence that the information was stolen.

Where a breach is likely to result in a risk to people’s rights and freedoms, organisations generally need to notify to ICO without delay, and where feasible, within 72 hours of becoming aware of it.

A ransomware incident does not mean you automatically need to report to the ICO. Your plan should establish who will assess the data protection impact and involve appropriate legal/data protection expertise when needed.

Report and seek appropriate support

The plan should also identify the appropriate route for reporting the incident as a crime, and when specialist cyber security support should be engaged.

The National Cyber Security Centre (NCSC) publishes specific guidance on ransomware, as well as response and recovery guidance for smaller organisations. Those resources (so long as they are up to date) are worth including directly in the response documentation.

Decide how you will communicate with customers, suppliers and employees

You may need to communicate with employees, customers, suppliers and partners. In your plan, decide who should:

  • Write the incident communications
  • Who approves these
  • Who handles incoming questions
  • Which stakeholders are contacted at which stage

Be careful to make definitive statements too early – saying ‘data has not been accessed’ for example is different from saying ‘there is currently no evidence that data has been accessed’.

4. Should the business pay the ransom?

This is arguably the hardest decision a business could face during a ransomware attack, which makes it one of the worst decisions to consider for the first time during one.

UK authorities including the NCSC do not encourage, endorse or condone the payment of ransomware demands.

There are good reasons for that. Paying a ransom does not guarantee that systems can be successfully decrypted. It does not guarantee that stolen information will be deleted. And paying does not remove an organisation’s data protection or other legal responsibilities.

There can also be significant legal considerations, including sanctions risk. If a ransomware demand is received, the business should obtain appropriate legal advice and consult its cyber insurer before taking action or communicating with an attacker.

The UK’s policy on ransomware payments and incident reporting is also developing. Government proposals have considered measures intended to reduce payments to ransomware criminals and increase incident reporting. Businesses should therefore check current UK government guidance rather than treating a response plan written today as fixed indefinitely.

Ultimately, one factor dramatically changes the position a business finds itself in: whether it can recover without a decryption key from the attacker.

That is why a ransomware response plan and tested backups belong together.

5. How will the business recover and get back to work?

Trying to decide which application to restore first while half the company is unable to work is difficult.

That’s why it’s best to decide it now.

Create an agreed recovery order covering the systems the business cannot operate without. Depending on the organisation, that could include identity and authentication services, customer databases, finance systems, communications platforms, order processing or other operational applications.

Your ransomware recovery plan should also establish suitable recovery time objectives (RTOs) and recovery point objectives (RPOs).

An RTO describes how quickly a service needs to be restored, while an RPO addresses how much data loss the business can tolerate. Together, they turn “get everything back as quickly as possible” into measurable recovery priorities.

Crucially, do not restore systems simply because a backup is available.

Backups should be clean and tested, and affected systems may need to be rebuilt or verified before data is restored. Restoring your data onto an environment an attacker can still access risks creating a second incident.

Take a look at our backup and disaster recovery services if you’re looking to build greater resilience into your recovery arrangements.

Plan how the business operates in the meantime

Technology recovery is only part of the problem.

Think about the essential work that still has to happen if core systems are offline for a day, several days or longer.

How will the business:

  • receive customer orders?
  • contact customers?
  • access critical supplier information?
  • process urgent payments?
  • pay employees?
  • record work completed while systems are unavailable?

Document simple manual workarounds for the most important processes, including where the information and forms needed to use them will be kept.

When technology is restored, validate the recovered data carefully and incorporate information generated during the outage back into the relevant systems. Enhanced security monitoring should continue after recovery so suspicious activity or signs of continued attacker access can be investigated quickly.

6. How should the ransomware response plan be tested?

An untested response plan contains assumptions. Testing tells you which ones are wrong.

One of the simplest approaches for an SME is a tabletop exercise once or twice a year.

Bring together the people named in the response plan and give them a realistic scenario. For example:

It is 7.10am on a Monday. An employee reports a ransom message on their computer. Within 20 minutes, three other employees report that shared files are inaccessible. The finance director cannot access email. What happens next?

Work through the incident step by step: Who makes the first decision? Who contacts the IT provider? Can someone find the cyber insurance details without accessing the corporate network? Who can authorise customer communications? If email is unavailable, how does everybody communicate?

Record every gap and give it an owner.

Choose a priority system and perform a controlled recovery test. Record how long restoration takes, whether the required data is present and whether the application operates correctly afterwards.

Review the plan when important employees leave or change roles, when new systems are introduced, when suppliers change and following any genuine cyber incident.

Response planning is a cycle. Lessons from recovery should improve both the response plan and the controls used to prevent the next attack.

Ransomware response checklist

For a more structured template, please download our incident response plan.

DecisionWhat to have written down
Who leads?Incident lead, deputy and responsibilities for each team
Who do we call?Offline contacts for the incident lead/deputy, IT provider, insurer, legal adviser and critical suppliers
What happens first?Device isolation, account containment, evidence preservation and backup protection procedures
Who needs to know?Employees, customers, legal advisers, your cyber insurer, managed service provider and potentially the ICO (and any other regulatory bodies)
What comes back first?Prioritised restore order, including RTOs and RPOs
How do we know it works?Dates and results from tabletop exercises and restore tests, plus owners for identified actions

Ransomware response plan FAQs

Begin by containing the incident. Isolate affected devices from the network, protect backups from the compromised environment and activate your incident response process. Contact the nominated incident lead and appropriate IT or incident response provider, and notify your cyber insurer in accordance with your policy.

Avoid destroying potential evidence unnecessarily while the extent of the attack is being established.

Not every ransomware attack automatically requires notification to the Information Commissioners Office (ICO). However, some scenarios (where a personal data breach is likely to result in a risk to people’s rights and freedoms) mean the organisation needs to notify the ICO without delay and, where feasible, within 72 hours of becoming aware of the breach.

UK authorities do not encourage, endorse or condone ransom payments. Businesses should know payment does not guarantee that the attackers will recover your data/systems or that stolen data will be deleted.

Seek specialist legal and insurer advice before making decisions about a ransom demand.

There is no standard recovery time. It depends on factors including how many systems were affected, how quickly the attack was contained, the condition of the backups and whether the organisation has previously tested its restoration process.

A measured restore test of your priority systems provides a much more meaningful recovery estimate than simply checking whether backups have completed successfully.

A disaster recovery plan primarily covers how technology and data will be restored following disruption. A ransomware response plan is broader. It addresses containment, roles and responsibilities, evidence preservation, regulatory and contractual reporting, stakeholder communications and other decisions required during a ransomware incident, as well as the eventual recovery of technology.

Prepare the decisions before you need them!

Nobody wants to test their ransomware arrangements for the first time during a real attack.

Download our incident response plan template to start documenting the people, contacts and actions your organisation will need during an incident.

If you want greater confidence in your cyber security processes and recovery plans, our cyber security specialists are more than happy to talk about ransomware protection and test your recovery arrangements – please just contact us here. A practical recovery test can establish whether your backups and procedures will actually get the systems your business depends on running again when it matters.

Ransomware protection

Giving your business peace of mind