Most businesses imagine that if they were hacked, the priority would be to fix it. The actual priority in the first day is different: stop it spreading, keep the evidence, get the right help, and notify the right people. Fixing comes after.
The difference matters because the instinctive reactions in the first hour are frequently the wrong ones. Switching everything off. Wiping the infected laptop. Emailing the whole team about what is happening. Resetting every password immediately. Each of those feels responsible, and each can make the situation worse.
This guide sets out what to do, in order, across the first 24 hours. It draws on the incident response guidance published by the US National Institute of Standards and Technology, the ransomware response checklist from the US Cybersecurity and Infrastructure Security Agency, and the UK National Cyber Security Centre, together with the UAE's official reporting routes and data protection rules. It is written for owners and managers, not security specialists.
Read it before you need it. The best time to understand this is on an ordinary day, when you can prepare the one-page plan described at the end.
The first 24 hours at a glance
The whole first day comes down to five blocks of work, in this order: contain, organise, preserve, understand, then begin recovery. Each is covered in detail below; this is the version to keep next to the phone.
| When | What to do | What not to do |
|---|---|---|
| First 15 minutes | Disconnect affected machines from the network. Switch to phone calls. | Switch machines off, unless disconnecting is impossible. |
| First hour | Name one incident lead. Start a written log. Call IT, a specialist, your insurer, and your bank if money is involved. | Discuss the incident on email or chat. |
| Hours 1 to 4 | Capture evidence: disk and memory images, logs, cloud snapshots. Lock down any account clearly taken over. | Wipe or rebuild anything. Reset every password. |
| Hours 2 to 8 | Work out what was affected, how the attacker got in, and whether they are still inside. Report to the police. Check which data protection rules apply. | Guess publicly about the cause or scale. |
| Hours 8 to 24 | Check backups, then restore critical systems in priority order. Tell staff and, when accurate, customers. | Restore unchecked backups. Declare everything fixed. |
The timings are approximate. A small incident may move through them in an afternoon; a serious one may spend the whole day on the first three rows. What matters is the order. Each block protects the next one: containing first keeps the damage small, organising first keeps the response coherent, and preserving evidence first means you can later prove the attacker is gone.
How do you know it is really an attack?
Often you will not be certain at first, and you do not need to be before acting. If you see a ransom message, unexplained payments or payment requests, or emails going out from your business that nobody sent, treat it as an attack until proven otherwise.
The UK National Cyber Security Centre lists the signs to watch for: computers running slowly, staff locked out of their accounts, documents that cannot be opened, messages demanding a ransom, people reporting strange emails coming from your domain, redirected internet searches, requests for unauthorised payments, and unusual account activity [1].
Some of those have innocent explanations. A slow computer is usually just a slow computer. But a combination of them, or any one of the more serious ones, is reason enough to start the steps below. Starting and finding it was a false alarm costs an hour. Waiting until you are sure can cost weeks.
The NCSC also suggests noting two things straight away: when the problem first appeared or came to your attention, and which parts of the business are affected [1]. Write both down. They are the first entries in your log.
The first hour: stop it spreading
The first action is to disconnect affected computers from the network, not to switch them off. CISA's ransomware guide states it directly: determine which systems are affected and immediately isolate them [2].
In practical terms:
For one or two machines, unplug the network cable or disconnect them from Wi-Fi.
If several machines or a whole office appear affected, CISA advises taking the network offline at the switch, since disconnecting machines one by one may not be feasible during an active incident [2].
Prioritise the systems the business depends on, isolating critical systems first [2].
For cloud systems, CISA suggests taking a snapshot of affected volumes, giving investigators a point-in-time copy to examine later [2].
Cut the cable, not the power
This is the single most common mistake, and it is an understandable one. Switching a machine off feels like the safest possible action.
CISA's guidance treats powering down as a last resort, to be used only when you cannot disconnect a device from the network any other way. The reason is that switching off destroys evidence held in the machine's memory, which investigators may need to understand what the attacker did [2].
Disconnecting stops the spread and keeps the evidence. Powering off stops the spread and loses some of it. If disconnection is genuinely impossible, powering off is better than letting the problem spread, but try disconnection first.
Talk by phone, not email
Attackers who have got into a business often watch its communications to see whether they have been noticed. CISA warns about exactly this and advises coordinating the response through out-of-band channels such as phone calls, so the attacker is not tipped off that you are responding [2].
If your email or chat might be compromised, do not use it to discuss the incident. Use phones. Use personal numbers if necessary. A message to the whole team saying "we have been hacked, IT is disconnecting the servers at 3pm" is a message the attacker may read.
Put one person in charge and start a log
One named person should lead the response, and everything that happens should be written down from the first minute. NIST recommends designating an incident lead for each incident [3].
In a small business, the lead is usually the owner, a senior manager or whoever manages IT. Their job is not to fix everything personally. It is to make decisions, coordinate outside help, and make sure nobody acts on their own initiative in ways that destroy evidence or alert the attacker.
The log matters more than it seems in the moment. You will need it for your insurer, for the police, for any regulator, and for your own review afterwards, and memory under stress is unreliable. NIST notes that facts discovered and actions taken can be recorded in many ways, including a paper logbook [3].
A paper notebook is ideal, precisely because it does not depend on systems that may be compromised. For each entry, note:
The time.
What was seen or done.
Who did it.
Which machines or accounts were involved.
It takes seconds per entry and saves days of reconstruction later.
Call for help early
Bring in outside help in the first hour or two, not after a day of trying to handle it internally. NIST recommends contacting your incident response service provider to request assistance, and starting other relevant plans such as business continuity [3].
Who to call, roughly in this order:
Your IT provider or internal IT person. They know your systems. If the incident is beyond their experience, which most serious incidents are, they should say so.
An incident response specialist, for anything beyond a single infected laptop. Capturing evidence properly and confirming that an attacker has genuinely gone are specialist skills, and a general IT provider may not have the tools. A few days of specialist time costs far less than an incomplete clean-up.
Your cyber insurer, if you have a policy. CISA lists the cyber insurance company among the stakeholders to inform [2]. Many policies expect prompt notification, and some require you to use approved response providers or seek consent before certain actions. Acting outside the policy's conditions can put cover at risk, so read the relevant section or call them before taking major decisions.
Your bank, immediately, if money has been sent or is at risk. Speed matters for any chance of stopping a payment.
Keep the evidence before you clean up
Do not wipe or rebuild affected machines until evidence has been captured. Wiping destroys the record of how the attacker got in and what they did, which you need in order to be confident they are gone.
CISA recommends taking a disk image and a memory capture of a sample of affected devices, including workstations, servers and cloud servers, and collecting relevant logs. It specifically highlights preserving evidence that is volatile or kept only briefly, such as system memory, security logs and firewall logs [2].
This is work for your IT provider or specialist, not for the business owner. Your role is to make sure it happens before anybody starts cleaning.
NIST makes a useful point here: most incidents never lead to a prosecution, but the data collected is still evidence and should be treated that way [3]. You may need it for insurance, for a regulator, for a dispute with a supplier, or simply to answer the question "are we sure it is over?"
Passwords: two stages, not one
Resetting every password immediately feels right and can be exactly wrong. If the attacker still has access to your systems, new passwords may simply be captured as they are set.
CISA's guidance places the organisation-wide password reset late in the process: once the environment has been fully cleaned and rebuilt, including removing anything the attacker left behind to get back in [2].
That does not mean doing nothing about accounts in the meantime. A specific account that has clearly been taken over, such as a hijacked mailbox sending fraudulent emails, may need locking down quickly to stop active harm. That is a judgement call for whoever is helping you respond, and it is different from resetting everything at once.
The principle is simple: contain first, clean second, reset everything third.
Hours two to eight: work out what happened
Once the spread is stopped and help is on the way, the next task is understanding the scope: what was affected, how the attacker got in, and whether they are still there.
The questions your responder will work through, and which you can help answer:
Which systems and accounts are affected? Computers, servers, email accounts, cloud services, the accounting system, the website.
What data might have been accessed or taken? Customer records, employee records, financial information, anything confidential.
How did the attacker get in? Until the entry point is closed, the attacker can come back the same way.
Are they still inside? Many attackers leave hidden ways back in.
CISA's checklist includes agreeing and documenting an initial understanding of what has occurred [2]. That early picture will change as more is learned, which is normal, but writing it down gives everyone the same starting point.
On how attackers usually get in: the UAE Cyber Security Council said in April 2026 that more than 75 per cent of cyber breaches begin with phishing emails or fraudulent messages [4]. So one of the first questions worth asking staff, gently and without blame, is whether anybody clicked a link, opened an attachment or entered a password somewhere unusual in the days before the problem appeared. People who fear punishment hide exactly the information you most need.
If it is ransomware
If your files are encrypted and there is a ransom demand, do not pay without taking advice, and know that every official body we checked advises against paying.
The joint guide from CISA, the FBI, the NSA and the Multi-State Information Sharing and Analysis Center states that the authorities do not recommend paying ransom. It explains that payment does not ensure your data is decrypted, does not ensure your systems are no longer compromised, and does not ensure your data will not be leaked, and it notes that paying may carry sanctions risks [2].
The FBI states that it does not support paying a ransom, adding that payment encourages attackers to target more victims [5]. The UK NCSC says law enforcement does not encourage, endorse or condone paying ransom demands, and notes that paying makes you more likely to be targeted again [6].
We looked for an official UAE statement on paying ransoms and did not find one, so we cannot tell you what UAE authorities advise. Take legal advice before any contact with attackers.
Two things to check before anybody considers paying:
Free decryptors. CISA advises consulting law enforcement about available decryption tools, because security researchers have found flaws in some ransomware and released free tools [2].
Clean backups. Restoring from backups that survived the attack avoids the question entirely, which is why tested backups are the most valuable preparation of all. More on that below.
If your email was taken over
A compromised mailbox is serious even if nothing else appears affected, because an attacker with your email can impersonate you to everyone you deal with.
With access to email, an attacker can read past conversations, learn who you pay and who pays you, set up hidden rules that forward or delete messages, and send convincing emails from your real address, including fake invoices and changed bank details.
Four things to do quickly:
Check for forwarding rules and filters you did not create. Attackers use them to keep receiving copies of your email after the password changes.
Check sign-in activity for unfamiliar locations or devices.
Lock the account down with the help of your responder, including signing out all sessions and turning on multi-factor authentication.
Warn customers and suppliers you regularly exchange invoices with, by phone or through a channel the attacker cannot see, that they should not act on any payment instructions from you without confirming by phone.
Our guide on changed bank details fraud covers how this form of attack turns into lost money, and how to stop it. Our guide on email authentication covers making it harder for anybody to send email pretending to be your domain.
Reporting to the police in the UAE
Report the attack through an official UAE channel. The UAE government portal lists the Ministry of Interior's eCrimes platform, available through the Ministry's app; the Dubai Police eCrime website; the Abu Dhabi Police Aman service [10]; the Federal Public Prosecution's My Safe Society app; local police stations; and 999 in an emergency [7]. The UAE Cyber Security Council also runs an incident reporting page [8].
Choose the channel that fits your location and the nature of the incident. We were not able to open every one of these services directly to confirm exactly which kinds of report each accepts, so if you are unsure, a local police station can direct you.
Hacking is a criminal offence under UAE law. Federal Decree-Law No. 34 of 2021 on Combatting Rumours and Cybercrimes, in force since 2 January 2022, includes articles dealing with hacking, with harming information systems, and with infringing the data of financial, commercial and economic establishments [9].
Why report even if recovery seems likely? An official report creates a record that insurers may ask for, that may matter if a bank or customer is involved, and that contributes to the wider picture authorities use to warn others. The Cyber Security Council has noted that rapid reporting enables response teams to analyse threats and take preventive measures [4].
Personal data: which rules apply to you
If personal data about customers or staff may have been exposed, you may have legal duties to notify a regulator and the affected people, and the rules depend on where your business is licensed. This is the part where legal advice matters most.
Onshore UAE businesses fall under the federal Personal Data Protection Law, Federal Decree-Law No. 45 of 2021. Article 9 requires a controller, on becoming aware of a breach that would prejudice the privacy, confidentiality and security of personal data, to notify the regulator, which the law names as the UAE Data Office, and to notify affected individuals where the breach would prejudice their privacy. It also requires processors, such as an IT or cloud provider, to tell the controller as soon as they become aware of a breach [11].
However, the law leaves the deadline and procedure to Executive Regulations, and we could not find an official publication of those regulations [11]. So we cannot give you an onshore deadline in hours, and if you see a confident 72-hour figure for onshore businesses, ask for the official source. The sensible course is to act promptly, document everything, and take legal advice on your specific position. Our guide on PDPL compliance explains that in June 2026 the Data Office was brought into the new Federal Authority for Artificial Intelligence and Data, and covers the current status of the law.
Businesses in the DIFC fall under the DIFC Data Protection Law. It requires notifying the Commissioner of Data Protection of a qualifying breach as soon as practicable in the circumstances, and informing affected individuals as soon as practicable where the risk to them is high, or promptly where there is an immediate risk of damage. It also requires breaches to be documented in writing [12]. The DIFC provides an online breach reporting form [13].
Businesses in ADGM fall under the ADGM Data Protection Regulations 2021. They require notifying the Commissioner of Data Protection without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. A later notification must give reasons for the delay, and individuals must be told without undue delay where the risk to them is high [14].
The DIFC and ADGM rules both allow information to follow in stages. You do not need the complete picture before making a first notification, which is important because in the first day you will not have it. Your log is the basis of what you report.
Telling customers and staff
Tell staff enough to stop them making things worse, and tell customers the truth once you know enough to say something accurate.
For staff, the message is practical:
Do not switch affected machines on or off.
Do not try to fix anything yourself.
Do not discuss the incident on email or chat, which may be compromised.
Report anything unusual to the incident lead by phone.
Do not discuss it publicly or on social media.
Staff who are kept informed are far less likely to act on rumour or make well-meaning mistakes.
For customers, the time to speak is when you can be accurate. Say what happened in plain terms, what information may be affected, what you are doing about it, and what they should do, such as treating payment instructions from you with caution. Do not speculate about who the attacker was, and do not minimise the problem before you understand it. A statement you later have to retract does more damage than a short delay.
If personal data is involved, check the notification rules above before drafting anything, since what you say to customers may need to align with what you report to a regulator.
On keeping it quiet: discretion about details is sensible. Silence about the fact of an incident, where customers or suppliers are affected, tends to damage trust more than the incident itself, and they will often find out anyway.
Hours eight to twenty-four: starting to recover
Recovery begins once you understand how the attacker got in and are confident they have been removed, and not before. Restoring onto systems that are still compromised puts you straight back where you started.
Check backups before restoring from them. NIST's guidance is explicit: verify the integrity of backups and other restoration assets before using them, checking for signs of compromise, corruption and other problems [3]. A backup taken after the attacker got in may contain whatever they left behind.
Be wary of backups that sync automatically. CISA warns that automated cloud backups may not be sufficient on their own, because if files on a computer are encrypted, the encrypted versions can sync to the cloud and overwrite the good copies [2]. Backups kept offline, or protected so they cannot be changed, are the ones most likely to survive.
Restore in priority order. CISA advises triaging systems for recovery, prioritising those critical to safety, revenue and essential services [2]. Bring back what the business most depends on first, carefully, and the rest in order.
Set realistic expectations. NIST observes that incidents that once took a day or two to resolve now often take weeks or months, because of their breadth and complexity [3]. The first 24 hours are for containing damage, keeping evidence, getting help and notifying the right people. Telling staff, customers and management that early avoids the pressure to declare everything fixed before it genuinely is. Our guide on business continuity and disaster recovery covers keeping the business running during a longer recovery.
What not to do
The most common first-day mistakes are switching machines off, wiping them before evidence is captured, discussing the response on compromised email, and resetting every password too early. The full list:
Do not switch machines off unless you cannot disconnect them from the network.
Do not wipe or rebuild before evidence has been captured.
Do not coordinate on email or chat that may be compromised.
Do not reset every password while the attacker may still be inside.
Do not restore from backups you have not checked.
Do not contact or pay the attackers without legal and specialist advice.
Do not let staff try to fix things on their own initiative.
Do not announce that everything is fixed before you are sure.
Preparing before it happens
The businesses that come through an attack best are the ones that prepared four simple things on an ordinary day.
1. Backups that survive an attack. CISA recommends offline, encrypted backups of critical data, with regular testing of their availability and integrity [2]. The testing matters as much as the backup: a backup that has never been restored is a hope, not a plan.
2. Multi-factor authentication on email and every important account. The UAE Cyber Security Council specifically advised enabling it when warning that most breaches begin with phishing [4]. It means a stolen password alone is not enough to get in. Start with email, then banking, cloud services and accounting software.
3. A one-page incident plan, printed. Who is in charge. Who to call, with their phone numbers. How to disconnect the network. Where the backups are. Which reporting channel applies. The first steps in order. It must be on paper or somewhere outside your normal systems, because during an attack those systems may be unavailable.
4. Help agreed in advance. Know who your incident response provider would be, have your insurer's claims number written down, and know what your policy requires. Searching for a specialist in the middle of an attack wastes the hours that matter most.
Our guides on cybersecurity for small businesses and phishing awareness training cover the preventive side in more depth, and our guide on who to call when something breaks covers setting up support arrangements before you need them.
After an incident, hold a short review once things are stable. NIST treats lessons learned as part of incident response rather than an optional extra [3]. Ask what let the attacker in, what slowed the response, and what would have made the first hour easier. Each answer becomes an action with an owner.
What preparation costs
A one-page incident procedure, with severity levels, an escalation path and a contact list for your team, starts from around AED 1,500 with us. A wider security assessment for a small office starts from around AED 5,000. No official body publishes rates for this work, so these are our own figures. Hands-on incident response during an attack is scoped to the situation. Final pricing depends on scope.
Whether or not you use anybody, write the one-page plan today and print it. It takes an hour and costs nothing. If the day ever comes, it will be the most valuable document in the building, precisely because it will still be readable when your computers are not.
References
- UK National Cyber Security Centre, small business guide: response and recovery, identify what's happening
- CISA, #StopRansomware Guide
- NIST, SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- WAM, UAE Cyber Security Council: 75% of cyberattacks start with phishing
- FBI Internet Crime Complaint Center, ransomware
- UK National Cyber Security Centre, mitigating malware and ransomware attacks
- The Official Portal of the UAE Government, cyber safety and digital security
- UAE Cyber Security Council, report a cybersecurity incident
- UAE Legislation, Federal Decree-Law on Countering Rumors and Cybercrimes
- Abu Dhabi Police, Aman service
- UAE Legislation, Federal Decree by Law No. 45 of 2021 on the Protection of Personal Data
- DIFC, Data Protection Law, DIFC Law No. 5 of 2020
- DIFC, Commissioner of Data Protection, security breach reporting
- ADGM, Data Protection Regulations 2021
- SKIMBOX, cybersecurity for small businesses in the UAE
- SKIMBOX, business continuity and disaster recovery in the UAE
- SKIMBOX, who do you call when it breaks
This article summarises published guidance and legislation and is not legal advice. Data protection obligations depend on where your business is licensed and what data is involved; confirm your position with a qualified adviser. We could not confirm that the PDPL Executive Regulations had been officially published at the time of writing, so check the current position.
