Not the attack chain, not the technical play-by-play — what a ransomware attack on an SME actually feels like to live through, day by day, and what incident response really looks like when you're inside one.
Most of what gets written about ransomware describes the attack chain - how the attacker got in, what tooling they used, which CVE did the damage. That's rarely what people actually want to know when they ask "what happens." This is based on a single incident from personal experience, but the shape of it is one most SMEs facing a ransomware attack will recognise.
It rarely starts with a flashing red light in the middle of the night, with a race against time to stop the attack. Any attacker that knows what they're doing will hide their work until the very last minute.
This incident started as a normal Monday morning: there was a team-wide meeting at 9am to talk through plans for the week. During the meeting we started receiving messages from others in the business about systems not being accessible, shared drives not opening. Assuming this was just a virtual server that didn't restart after an update, we sent someone to log in and give it a kick.
The ransom note wasn't something we found by searching for it, we stumbled onto it. Ours was a text file sitting on a random server, found while we were trying to work out why that server wouldn't respond either. That's the moment the problem changes shape: it's no longer "what's broken," it's "what's been done to us, and how far does it go."
Next thing we know an image was sent in Teams showing a ransom note while the technician ran down two flights of stairs to pull every network cable out of every server we could. In the heat of the moment, we had 10 seconds to decide: shut everything down to stop the spread, or isolate it to protect evidence but risk more systems getting corrupted.
The next call is to leadership, and it's a genuinely difficult conversation to have well. We didn't yet know how it happened, how far it had spread, or how bad it was and the honest answer to almost every question in that first call is "I don't know yet." Some leaders would instantly want to start blaming people, but at this moment support and a rational voice will recover the business faster than pressure. The team involved will also have beaten themselves up enough in the meantime.
No matter how well we'd protected ourselves, we instantly feel responsible, we were given the task of protecting the business, and it wasn't enough. Had we taken the entire business down and, in the worst case, forced it to go under if we couldn't recover in time?
3 years on, the answer was no; there are always things that can be done better, but budgets and time will always constrain us so we can't meet "perfect." A business IT and security team is a handful of individuals trying to protect against threats that are sometimes sponsored by entire countries, with a budget that's incomprehensible to most people.
What actually slows you down
Explaining what happened is harder than finding it. The technical investigation has a process to follow. The leadership call doesn't, you're improvising an explanation of something you don't fully understand yet, to people who need certainty you can't give them.
The rest of the day is logs. Not a dramatic chase, hours of pulling login history, file access records, and server events, trying to work out when this actually started, which systems it touched, and whether it's still moving. We're doing this while systems are still down, staff are asking when they can work again, and we genuinely don't know the answer.
At some point someone asks the obvious question: can we just restore from backup? The honest answer, that first day, is usually "we're not sure yet." Not because the backups don't exist, but because we don't know how far back the attacker had access before they triggered anything, restoring from yesterday's backup is worthless if they were already inside a week ago, and we don't have that answer on day one.
Ransomware is like a cancer: if we cut out 99% of it but leave 1%, it'll spread and grow back over the healthy parts. Until we're confident it's been eradicated, we can't risk restoring systems and bringing them back online.
By late evening, most SMEs reach the same conclusion: this is bigger than the internal team can handle alone, and every hour spent trying to figure that out is an hour not spent fixing it. Calling in external ransomware incident response help isn't an admission of failure, it's usually the single decision that most changes how the next two weeks go, and the biggest regret people report afterwards is not making that call sooner.
Quite often the internal team is so focused on fixing the issue that the idea of bringing in someone external doesn't even occur to them. That's where they need a leader to be the voice of reason, to help them take a step back from the detail of the logs and look at this from a different point of view.
Normal incident response teams work 24/7, in this incident, they came into our office around 11pm and we started the handover. I don't think any of us slept much that night.
The external team doesn't walk in and fix it. The first few hours are spent handing over everything we found the day before, while they run their own checks and investigation in parallel, because they don't take our scoping on trust, and they shouldn't. It's often at this point that the backup picture gets worse, not better: the attacker had access for longer than first thought, and some of what we were counting on as a clean restore point turns out to already be compromised.
This is also usually when the insurer and a lawyer get pulled into the room, often for the first time. Cyber insurance policies frequently come with conditions about who can be engaged and how, using the wrong forensics firm or making the wrong statement publicly can affect a claim, and most people don't know that until day two, when someone tells them.
The clock most people don't know about
Under UK GDPR, a breach involving personal data starts a 72-hour countdown to notifying the ICO, measured from the moment you become aware of it, not from the moment you fully understand it. That clock was already running on day one, while cables were still being pulled and nobody yet knew whether personal data was even involved. It's one more reason legal needs to be in the room this early, not later.
Customers are also starting to notice something is wrong, why are requests slow, why is Sales pushing back on meetings? The press is starting to gain visibility of it too. Leaks are always going to happen, and once the press gets involved, they can paint their own version of events.
At this stage we needed someone to oversee external comms, what do we say to customers, what do we say to the press (or what don't we say)? This person should be as far separated from the internal team working the issue as possible; make it something they don't have to worry about.
On a similar theme, what do we tell the rest of the business? They know something is wrong but haven't been given the full picture.
People have the best intentions
During one particular incident we had to have someone from another team stand by the server room door turning staff away. They had the best intentions by bringing the team drinks and snacks, but during this level of incident it will make them feel under even more pressure.
Drafting the first message to staff and customers is harder than it sounds. Say too little and people fill the silence with worse guesses than the truth. Say too much before you actually know what happened and you may have to walk it back later, which damages trust more than the delay would have. Most of that first message ends up being honest about the fact that you're still investigating, and a promise to update people as you know more, which is unsatisfying to write and unsatisfying to receive but is usually the right call.
Around now we also start thinking about communicating with the attacker. We agreed early on that they wouldn't get any money from us. The question came up naturally, but we knew paying would both fund and encourage them to attack others, not something we were ever going to be part of.
We knew that if we didn't communicate with them, our name and data would soon be posted online. So we brought in a ransomware negotiation specialist, a type of firm I hadn't known existed until that week, and one more SMEs should know about before they need one. Their job isn't to get your data back; it's to manage the relationship with the attacker on your behalf: buying time, working out what you're actually dealing with, and, in our case, quietly feeding intelligence about the attackers to law enforcement in multiple countries. Using techniques that sound more like a movie plot than real life, they delayed the group publishing our name for several days and eventually prevented the data getting posted altogether, which is time most organisations badly need and don't otherwise have.
What ransomware actually threatens
Most people believe ransomware is a "pay us and we'll give your data back" arrangement. In reality, most groups now run both threats in parallel, encrypting your systems and threatening to publish stolen data, because the second threat has proven far more convincing on its own than the first ever was. Neither model has replaced the other; expect both.
All of that is just in 36 hours. At this stage we're also noticing the signs of burnout, fatigue and stress in the team. This tempo is not sustainable.
A note on what follows
Day one and day two above are one specific incident, ours. Everything from here on is still first-hand, not a generic industry summary, but told at the level of the pattern rather than the hour. That's a deliberate choice, not a change of source: the shape below is the one that's repeated in every other SME ransomware incident I've since been close to, not just the one I lived through directly.
Throughout the rest of the first week, the pattern repeats. Internal and external comms are critical, recovery is critical, prioritisation is critical.
The one thing that should be most critical, though, is the people. Someone has to put a focus on them — checking in each day, forcing them to go home and go to sleep, forcing them to eat proper food. At times like this, the stress and adrenaline don't let up and will stay high for weeks at a time. It's not unusual for several people to go off sick due to burnout.
But ideally during this week, systems should start to be restored. It's the light at the end of the tunnel. They should come back in priority order, not technical order. Whatever keeps the business actually running, payroll, the system customers use directly, whatever generates revenue that day, gets rebuilt first, ahead of things that are technically easier to fix but matter less. That prioritisation conversation, deciding what "critical" really means when everything can't be restored at once, is one most organisations are having for the first time during the incident itself, not before it.
And the cost is already becoming real. Day rates for incident response consultants, legal counsel, and forensic investigators add up fast, and they're being spent before anyone can say with confidence exactly how the attacker got in, that answer usually takes longer than the first week to land.
Some data is genuinely gone. Not every organisation gets a clean full recovery, and part of week two is accepting that certain files, certain records, certain historical data simply aren't coming back in the form they existed before, and making a judgement call about what that actually means for the business, rather than waiting indefinitely for a better answer.
Systems return in waves as each one is checked, rebuilt, and verified clean, not all at once, and rarely on the timeline leadership was hoping for after the vague honesty of day one. Somewhere in this stretch, someone usually remembers a contract clause requiring breach notification to a specific customer or partner within a set window, which had been completely forgotten until it suddenly mattered.
"Back to normal" is also removed from the plan, and a new normal is created. Normal would put us at risk again, so decisions are made to reduce those risks. Both the external firms and internal teams come up with ideas of how to improve security, and they get implemented as systems are rebuilt. Staff are tired, in a way that doesn't show up on any incident report but is very real in the room.
This is also, eventually, when the delay runs out. Back on day two we'd decided we wouldn't pay, and the negotiation specialists had bought us months, not an unlimited amount of time, by managing that relationship carefully. Now the ransomware group lists the business on their leak portal. Every security researcher, or curious person, can see the business name and samples of the data. They tend to choose samples that look the most damaging, a passport or similar found in someone's email, maybe a file called passwords.txt saved in a personal folder, because the goal is to force payment through the threat of embarrassment, not because the data itself has value to them.
Let's say the recovery takes a month, that would be quick, but not impossible.
The bill, once everything is totalled, is rarely just one number, incident response consultants, legal fees, forensic investigation, whatever was or wasn't paid to the attacker, lost productivity while systems were down, and the insurance excess before any of it was covered. Organisations that go through this describe the final figure as consistently higher than what they expected on day one, when the concern was simply getting email working again.
There's a report from the external firm, in our case, it turned out the exfiltration of data was still in progress at the point the cables were pulled, so very little was actually taken.
The lasting changes tend to be the same ones, wherever the incident happened: multi-factor authentication everywhere, not just on the systems someone thought were important; backups that are actually tested on a schedule, not just assumed to work; and, the one that matters most, an incident response plan that names real people, real roles, and a real first call to make, tested before it's needed rather than written for the first time during day one.
The thing that would have helped most
Not a better tool. Knowing, before day one started, who does what, who gets called first, and what the first few hours are actually supposed to look like — so that morning isn't spent inventing a process under pressure, it's spent following one.
That plan doesn't need to be complicated to be useful. It needs to exist, be specific to your actual systems and people, and be read by the people in it before the day they need it. Before any of that, though, the honest first step for most SMEs is simpler: find out where the actual gaps are today, before a ransomware attack forces you to find out, while there's still time to fix them calmly, rather than at 9am on a Monday with cables in your hand.
However, even with all systems recovered, the people may not be. After a month of very little sleep, running on adrenaline and caffeine, and a level of stress that is rarely experienced, it takes its toll. It might take several more months for everyone to be back at 100%, and the fear of it happening again might never go away completely.
Read the full guide
How to prepare for cyber insurance
A free, editable Incident Response Plan template — roles, severity levels, containment steps, and notification obligations — so day one is spent following a process, not inventing one.