Ransomware Preparedness and Incident Response: A Practical Guide for UAE Businesses

Ransomware remains one of the most consistently disruptive threats facing UAE businesses, not because the technique is novel, but because so many organisations still treat it as a backup problem rather than what it actually is: a full business continuity event that touches IT, operations, legal, and leadership all at once. The businesses that recover quickly aren't the ones that never get hit — they're the ones that had a tested plan before the attack started. This guide covers how ransomware attacks typically unfold, what to have in place beforehand, and what to actually do in the first hours of an incident.

How a typical ransomware attack unfolds

Ransomware is rarely a single, sudden event. In most incidents our team has reviewed, the attack follows a recognisable sequence over days or weeks before the encryption itself:

1. Initial access — commonly through phishing emails, exposed remote desktop protocol (RDP) services, compromised VPN credentials, or an unpatched internet-facing application. Many of the vulnerabilities attackers rely on here are the same ones a network penetration test is designed to surface before anyone exploits them.
2. Foothold and privilege escalation — the attacker establishes persistence and works to obtain domain administrator or equivalent high-level access, often by abusing weak Active Directory configurations.
3. Lateral movement and reconnaissance — the attacker maps the network, identifies backup systems and critical data stores, and often spends this stage specifically locating and disabling or deleting backups before encryption begins.
4. Data exfiltration — increasingly, attackers quietly copy sensitive data out of the network before encrypting anything, turning the event into a double-extortion scenario: pay for a decryption key, and pay again (or the data gets leaked) regardless.
5. Encryption and the ransom note — the final, visible stage, usually triggered outside business hours to maximise the time before anyone notices.

The implication of this sequence matters for planning: by the time encryption is visible, the attacker has often already been inside the network for days, has already found and targeted the backups, and may have already taken a copy of the data. Preparedness has to address all five stages, not just "can we restore from backup."

What needs to be in place before an attack

A tested, offline backup strategy

Backups that are reachable from the same network and the same credentials as production systems are a primary ransomware target, not a safety net. A defensible backup strategy follows the 3-2-1 principle (three copies, two different media types, one copy offline or air-gapped) and — critically — is tested through actual restoration drills, not just confirmed as "completed" by a backup job log. An untested backup is a hope, not a plan.

Network segmentation

Flat networks let ransomware spread from one compromised workstation to every server and backup system within hours. Segmenting production systems, backups, and administrative infrastructure from general user networks slows lateral movement enough to matter — often the difference between losing one department and losing the whole organisation.

An incident response plan, written down and assigned

A ransomware incident response plan should name specific people (not just roles) for technical containment, internal communications, legal/regulatory notification, and executive decision-making, along with contact details that don't depend on systems the attacker might have taken down. It should also pre-answer the two hardest questions an organisation faces mid-incident: who has the authority to decide whether to pay a ransom, and who has the authority to decide whether to take systems offline. Deciding those questions during the incident, under pressure, costs hours that matter.

Regulatory and contractual notification obligations mapped in advance

UAE organisations handling personal data need to know their breach notification obligations under the UAE PDPL in advance, not during the incident. Regulated sectors have additional reporting lines — banks and fintechs to the Central Bank, healthcare entities under ADHICS, government and critical infrastructure entities under NESA or DESC depending on emirate. Knowing which regulator needs to be told, by when, and through what channel is a five-minute lookup if it's documented beforehand, and a costly delay if it isn't.

Cyber insurance reviewed for what it actually covers

Many policies have specific requirements around notification timelines, approved incident response vendors, and evidence preservation that invalidate a claim if not followed. This needs to be read and understood before an incident, not during one.

The first hours of an incident: what actually matters

When ransomware is discovered — usually via a ransom note, locked files, or unusual encryption activity reported by a user — the sequence of early decisions has an outsized effect on the eventual cost and recovery time.

1. Isolate, don't power off. Disconnect affected systems from the network (pull the network cable or disable the network interface) rather than shutting them down. Powering off can destroy forensic evidence in memory that's needed to understand how the attacker got in and whether other systems are compromised.
2. Activate the response plan and notify the pre-assigned team, including legal counsel early — attorney involvement can affect what information is protected from later disclosure, and legal counsel will also drive regulatory notification timing.
3. Preserve evidence before remediation. Take images or at minimum detailed logs of affected systems before wiping or rebuilding them. This matters for understanding root cause, for insurance claims, and for any regulatory reporting that asks what happened.
4. Assume data exfiltration until proven otherwise. Given how common double extortion has become, treat the incident as a potential data breach from the outset rather than waiting for confirmation, so that notification timelines aren't missed while investigation is still ongoing.
5. Don't rush the ransom decision. Paying doesn't guarantee a working decryption key, doesn't guarantee exfiltrated data won't be leaked anyway, and may carry legal exposure depending on the sanctioned status of the threat actor. This decision should involve legal counsel, leadership, and — where a policy exists — the cyber insurer, not be made unilaterally by whoever is online at 2am.
6. Rebuild from known-clean backups, not from the infected environment. Restoring onto a network that still contains the attacker's persistence mechanisms is one of the most common causes of reinfection within days of "recovery."

Why preparedness testing matters more than policy documents

A ransomware response plan that has never been exercised tends to fail in the same predictable ways: the named contacts are out of date, nobody can locate the offline backup keys, and the first two hours are lost figuring out who's actually in charge. A tabletop exercise — walking the response team through a simulated ransomware scenario without touching real systems — reliably surfaces these gaps cheaply, long before a real incident does it expensively. Combining that with periodic technical testing, such as internal and external network penetration testing and a review of how cloud security misconfigurations might expose backup or administrative infrastructure, closes the gap between "we have a plan" and "we know the plan works."

FAQ

How quickly can ransomware spread through a network?

It varies by malware family and network architecture, but modern ransomware can move from initial foothold to widespread encryption within hours once an attacker has obtained privileged access, and in some documented cases within minutes of triggering encryption across a flat, unsegmented network. This is why containment speed and prior network segmentation matter more than any single technical control.

Should we ever pay the ransom?

There's no universal answer — it depends on the availability of clean backups, the sensitivity of exfiltrated data, legal and sanctions considerations, and insurance policy terms. What matters is that the decision is made deliberately by the right people (legal, leadership, insurer where applicable) with full information, rather than under panic in the first hours, which is why this question belongs in the response plan in advance.

Does having backups mean we don't need an incident response plan?

No. Backups address data recovery, but a ransomware incident also involves forensic investigation, regulatory notification, legal exposure, internal and customer communications, and verifying the environment is actually clean before restoring — none of which a backup alone resolves. Organisations with good backups but no plan still routinely lose days to confusion and reinfection.

How often should we test our incident response plan?

Most mature organisations run a tabletop exercise at least annually, and after any significant change to infrastructure, personnel, or the threat landscape. The goal is simply to confirm the plan still matches reality — outdated contact lists and assumptions are the most common things a drill catches.

Make sure your response plan works before you need it

TestUnity supports UAE organisations with the technical testing and ongoing monitoring that underpin real ransomware readiness — from network and infrastructure testing through our AMC managed security services to incident-readiness guidance from a virtual CISO. Get in touch to talk through where your current plan has gaps.