When Something Goes Wrong: How to Build an Incident Response Plan That Works Under Real Pressure

There is a version of cybersecurity preparedness that ends with the firewall, the antivirus, and the backup schedule. Put the controls in place, monitor them, and hope for the best.

Then there is the question that sits underneath all of it: if something goes wrong anyway and the assumption for any serious security posture is that it will what happens in the first sixty minutes?

For most UAE businesses, the honest answer is: people make it up as they go. Not through negligence, but because building an incident response plan tends to sit permanently at the bottom of the priority list. It is easy to deprioritise preparation for something that has not happened yet.

The problem with that logic is that the sixty minutes immediately following a cyberattack are the most consequential in the entire incident. What happens in that window determines whether the damage is contained or catastrophic, whether recovery takes days or weeks, and in some cases whether the business survives at all.

This post walks through what a practical, tested incident response plan looks like for a UAE business and how to build one that holds up when it matters most.

Why Most Businesses Improvise — and Why That Is Expensive

When we speak to UAE businesses about incident response, the most common response is a version of: ‘We have an IT team. They would deal with it.

That confidence is rarely matched by the reality of what happens when an actual incident unfolds. An IT team without a documented plan faces several simultaneous problems under pressure: they do not know who has decision making authority, they do not know which systems to isolate first, they do not know who to call externally, and they have no template for communicating with the rest of the business. Every decision gets made from scratch, in real time, under stress.

The research on incident response consistently shows that organisations with documented, tested plans contain breaches faster, recover faster, and incur significantly lower costs than those that improvise. The difference is not the quality of the IT team. It is the existence of a plan.

An incident response plan is not a technical document. It is a decision making framework designed so that the right actions happen in the right order, by the right people, without anyone having to think too hard under pressure.

The Six Phases of an Effective Incident Response

A well structured incident response plan follows a clear sequence. Here is how each phase works in practice:

The most common mistake in Phase 2 is doing too much too fast shutting down all systems, wiping devices, restarting servers. These actions destroy forensic evidence and can prevent you from understanding how the attacker got in. Contain first. Investigate second.

Who Needs to Be in the Room

One of the most overlooked elements of incident response planning is defining roles before an incident occurs. When a breach is unfolding, the last thing you want is ambiguity about who is in charge, who is communicating with the board, and who is talking to regulators.

These are the core roles every UAE business IR plan should define with a named individual and a named backup for each:

Two points on the external IR retainer in particular: first, this firm should be contracted before an incident, not sourced during one. Trying to negotiate a new vendor engagement while your environment is encrypted is not a position you want to be in. Second, their number should be saved somewhere offline if your systems are down, your contacts stored in cloud tools may be inaccessible.

The Communication Problem Most Plans Miss

Technical response — isolation, investigation, recovery is only half of incident management. The communications side of an incident is equally consequential and almost always less prepared.

Internal communications

Staff need to know what is happening and what they should and should not do particularly around continuing to use systems that may be compromised. An untrained employee trying to ‘help’ by restarting systems or opening emails to check if they are working can cause significant additional damage. Your IR plan should include a pre written internal communication that can be deployed within the first hour.

Client and supplier notifications

Depending on the nature of the incident, clients and suppliers may need to be notified both as a matter of trust and as a contractual obligation. Pre drafted notification templates, reviewed by legal counsel in advance, save critical time and reduce the risk of saying the wrong thing under pressure.

Regulatory notifications in the UAE

This is where many UAE businesses are genuinely underprepared. The regulatory landscape has specific notification obligations that organisations need to understand before an incident occurs:

• The UAE Cybersecurity Council and NCA expect significant incidents to be reported promptly. Organisations should understand their specific sector obligations and reporting timeframes before an incident occurs.
• The CBUAE Cyber Resilience Management Framework requires financial institutions to notify the Central Bank within defined timeframes following a material cybersecurity incident.
• The Dubai Electronic Security Center (DESC) sets notification requirements for entities within the Dubai Government ecosystem, including specific reporting channels and response timeframes.
• Businesses operating under DIFC or ADGM jurisdiction face additional obligations under their respective data protection and cybersecurity frameworks.

Regulatory notification deadlines run from the moment an incident is discovered not from when it is fully understood. Waiting until you have the full picture before notifying is a common mistake that creates additional compliance risk on top of the incident itself.

The Difference Between a Plan and a Tested Plan

A documented incident response plan that has never been exercised is better than nothing. A tested plan is in a different category entirely.

Tabletop exercises structured walkthroughs of a simulated incident scenario are how organisations find out whether their plan actually works before they need it to. They reveal gaps that are invisible on paper: the role with no named backup, the communication channel that requires a system that would be offline in a real incident, the recovery procedure that takes three times as long as assumed.

For UAE businesses, a tabletop exercise does not need to be a significant undertaking. A two hour session with the IR team, working through a realistic scenario, will surface more actionable improvements than months of plan refinement in isolation.

The goal is not to pass the exercise. The goal is to find the gaps while finding them is cheap.

Test your plan at least once a year, and after any significant infrastructure change. The threat landscape shifts. Your environment changes. A plan written eighteen months ago for a different network architecture is not the same plan.

Your Incident Response Readiness Checklist

Use this as a starting point to assess where your plan currently stands:

If you cannot tick every item on this list, you have a starting point. The goal is not perfection it is progress. Each item you address reduces your exposure and improves your ability to respond effectively when it matters.

Closing the Loop on the Series

Across this three part series, we have worked through the three layers of cybersecurity resilience that matter most for UAE businesses right now:

• Understanding the ransomware threat and what infrastructure gaps make UAE businesses vulnerable in Ransomware in the UAE: Why Local Businesses Are Now Prime Targets

• Using vulnerability assessments and penetration testing to find those gaps before an attacker does in You Can’t Protect What You Can’t See: Vulnerability Assessment & VAPT for UAE Businesses

• Building an incident response plan so that when something goes wrong, your organisation responds effectively rather than improvising

These three elements are not independent. A strong infrastructure reduces the likelihood of an incident. A regular vulnerability assessment keeps that infrastructure honest. And a tested incident response plan ensures that when something does get through and the honest assumption is that something eventually will the outcome is manageable rather than catastrophic.

Resilience is not a product you buy. It is a posture you build, deliberately, over time.

Build Your Incident Response Plan With Candor

Candor works with UAE businesses to develop, test, and maintain incident response plans that work under real pressure not just on paper. If your organisation does not yet have a documented IR plan, or has one that has never been tested, we can help.

👉 Get in touch with our team today.

👉 Enterprise IT Solutions