A working cyber incident response plan defines who decides, what counts as an incident, how it is escalated, who must be notified and within what timeframe, and what the first hour looks like. For UAE organisations it must also account for regulatory notification under PDPL and any sector obligations. Length is not the measure of quality — most plans fail because they were never rehearsed, not because they were too short.
Key Takeaways
- Severity criteria must be concrete enough that a tired analyst can apply them at 3am.
- Decision authority — including who can shut down production — has to be named in advance.
- Regulatory notification clocks start at detection, so detection capability is part of the plan.
- Out-of-band communications matter: your plan cannot assume email and Teams still work.
- An unrehearsed plan is a document, not a capability.
What belongs in the plan
A plan that works under pressure is short, specific and immediately actionable. The essential components:
- Roles and authority. Incident commander, technical lead, communications lead, legal and executive sponsor — each with a named deputy. Critically, who is authorised to disconnect systems or halt production.
- Severity classification. Objective criteria that distinguish a contained malware detection from a confirmed data breach, because severity drives everything that follows.
- Escalation paths. Who is contacted at each severity, through which channel, within what timeframe, including out of hours.
- Notification obligations. Regulatory, contractual, insurance and law enforcement — with the owner and deadline for each.
- Evidence handling. What to preserve before remediation begins, because rebuilding a server destroys the evidence needed to understand the intrusion.
- External contacts. Incident response retainer, legal counsel, insurer, key suppliers — stored where they remain reachable if your systems are down.
Severity criteria that survive 3am
Vague severity definitions are the most common weakness we see. “High: significant business impact” tells an analyst at 3am nothing useful.
Workable criteria are concrete: confirmed unauthorised access to a system holding personal data; ransomware encryption observed on any server; privileged account compromise; any incident affecting a system with an RTO under four hours; any suspected data exfiltration.
The test is simple — could a newly joined analyst classify correctly using only the written criteria, with no one to ask? If not, the criteria are not finished.
Regulatory notification in the UAE
Notification obligations are the part most plans handle weakest, usually because they are drafted by technical teams.
- UAE PDPL. Personal data breaches require assessment and, where thresholds are met, notification to the UAE Data Office and potentially to affected individuals.
- Sector regulators. CBUAE for financial institutions, Department of Health for ADHICS entities, DESC for Dubai government-linked organisations, and NESA for critical infrastructure.
- Contractual. Customer agreements frequently carry notification clauses with shorter deadlines than regulation.
- Insurance. Policies typically require prompt notification, and late notice can affect cover.
Each obligation needs a named owner and a deadline measured from detection. Which means detection capability is itself part of the plan — you cannot report within a deadline you have no way of noticing.
The first hour
- Confirm and classify. Establish what is actually happening and assign severity before mobilising everyone.
- Contain without destroying evidence. Isolate affected hosts at the network level rather than powering them off, and preserve memory and logs.
- Mobilise the team. Incident commander appointed, bridge opened, roles confirmed.
- Start the log. A timestamped record of what was observed, decided and done — this becomes your regulatory evidence and your post-incident review.
- Assess notification triggers. Do not wait for full understanding; start the assessment clock immediately.
- Communicate internally. A holding message to staff prevents rumour and stops well-meaning people taking independent action.
Where in-house capability is thin, a digital forensics and incident response retainer means step three is a phone call rather than a procurement exercise.
What most plans get wrong
- Too long to use. A hundred-page document nobody opens during an incident. Keep a two-page action card at the front.
- Assumes the network works. If email and chat are compromised or down, how does the team coordinate? Out-of-band communications need to be arranged in advance.
- No supplier scenario. Many incidents start at a third party. The plan should cover what you do when your provider is breached — see third-party risk management.
- Never rehearsed. The single biggest failure. A tabletop exercise reveals expired retainers, missing authority and contact lists that have not been updated in two years.
- No post-incident loop. Lessons captured but never turned into tracked remediation, so the same gap causes the next incident.
Frequently Asked Questions
What should a cyber incident response plan contain?
Named roles and decision authority, objective severity criteria, escalation paths with timeframes, regulatory and contractual notification obligations with owners, evidence preservation guidance, external contacts, and a short action card for the first hour. Everything else is supporting detail.
Who should lead a cyber incident?
A designated incident commander with the authority to make containment decisions, supported by technical, communications, legal and executive leads. The commander coordinates rather than performing the technical work, and that separation matters once an incident runs beyond a few hours.
How quickly must a data breach be reported in the UAE?
Under PDPL, personal data breaches must be assessed and, where thresholds are met, notified to the UAE Data Office without undue delay, with affected individuals notified where the risk warrants it. Sector regulators such as CBUAE and the Department of Health set their own timelines, which are often shorter.
Should we isolate or power off an infected machine?
Isolate at the network level rather than powering off. Shutting down destroys memory-resident evidence that forensics needs to understand how the intrusion worked and what was accessed. Network isolation stops the spread while preserving the investigation.
How often should an incident response plan be tested?
At least annually through a tabletop exercise, and after significant changes to systems, suppliers or leadership. Include executives and communications staff — the hardest decisions in a serious incident are commercial and legal rather than technical.
Do we need an incident response retainer?
If you do not have forensic capability in-house, yes. A retainer means the specialists are already contracted, scoped and familiar with your environment, so the response begins in hours rather than after a procurement cycle while an attacker is still active.
Talk to a UAE Cybersecurity Team
Cybersecurity MEA helps UAE organisations build incident response plans that work under pressure, runs tabletop exercises with executive teams, and provides 24/7 incident response and digital forensics on retainer. Talk to us before you need the number.