We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Audit and compliance
  3. Incident response plan
Incident response plan development, UAE

The plan that fails is the one nobody has read, stored on the file share that just got encrypted.

An incident response plan is judged on one occasion, under time pressure, by people who did not write it. That means it has to be short, findable offline, specific about who decides what, and exercised often enough that the first time is not the real time.

Book an incident response planning sessionSee what a usable plan contains
Incident response plan development for UAE organisations
  • Findable offlineBecause the file share may be unavailable
  • Named decisionsWho declares, who authorises, who speaks
  • ExercisedA plan never rehearsed is a document
  • CIS Control 17Incident response management, in the eighteen
What a usable plan contains

Seven things that separate a plan from a document.

NIST published revision 3 of its incident response guidance in April 2025, under the title Incident Response Recommendations and Considerations for Cybersecurity Risk Management, a CSF 2.0 Community Profile. Its stated aims are to help organisations prepare, reduce incident frequency and impact, and improve the efficiency of detection, response and recovery.

Named people, named deputies, and current numbers

Roles rather than names ages badly, and names without deputies fail the moment somebody is on a flight. A usable plan lists the person, the deputy, and how to reach both by a route that does not depend on corporate email or the corporate network, because both may be unavailable or untrusted at the moment you need them.

A declaration threshold somebody can apply at 3am

The most consequential decision in any incident is when it becomes one. A plan that says the security team will assess severity and respond appropriately provides no help to the person holding the phone. A threshold that describes observable conditions, and names who can declare, is what converts hesitation into action.

Decision rights, especially the expensive ones

Who can take a production system offline. Who can disconnect a site. Who can authorise engaging external responders, and up to what value. Who can decide not to pay. Those decisions get made under pressure by whoever is present, and a plan that pre-authorises them removes the worst delay in most real incidents.

External contacts, gathered before you need them

Incident response retainer, cyber insurer notification route and policy number, legal counsel, the regulator contact where an obligation exists, key suppliers, and the account team at each critical vendor. Assembling that list is an afternoon of work in peacetime and a very bad hour during an incident.

Scenario playbooks, not one general procedure

Ransomware, business email compromise, data exfiltration, insider action and a critical supplier outage behave differently and need different first moves. A single general procedure covers all of them badly. Three or four scenario playbooks, each two pages, cover the realistic cases well and are actually read.

Exercised, because that is where the plan gets fixed

A tabletop exercise finds the gaps that reading never does: the contact who left, the decision nobody could make, the assumption that a system would be available. NIST frames its guidance around preparing for incident responses, and exercise is where preparation becomes real rather than documented.

Available when the network is not

A plan stored only on the file share, or only in the collaboration platform, is unavailable in exactly the incidents where it matters most. Printed copies with the people who need them, plus a copy held outside the environment, is unglamorous and it is the difference between having a plan and having had one.

The three questions every real incident asks first

Is this an incident, who decides, and can we take that system offline.

Almost every plan we review answers none of the three in a way somebody could act on at two in the morning.

  • Is this an incident. A threshold expressed as observable conditions, not as a judgement about severity, so the person on call can apply it without needing to be the most senior person available.
  • Who decides. A named individual and a named deputy, reachable by a route that does not depend on the corporate network or corporate email, both of which may be unavailable or untrusted.
  • Can we take that offline. Pre-authorised containment decisions with a named authoriser and a clear boundary, because the delay between recognising containment is needed and being permitted to do it is where most damage accumulates.
  • Everything else in a plan matters less than these three. A two-page document that answers them well is more valuable than a forty-page document that answers them in principle and cannot be found during the incident.
Ask us to review your existing plan
How we approach it

Four things that make a plan work on the day.

We have been in enough real incidents to know which parts of a plan get used and which parts never get opened. The ratio is not what most plans assume.

We agree the decisions before we write the document

Who declares, at what threshold, who can take systems offline, who can authorise spend, who speaks externally. Those are the plan. A document written before those are agreed is a well-formatted set of open questions, and the questions get asked again at the worst possible moment.

We keep it short enough to be read under pressure

A core plan somebody can read in ten minutes, with two-page scenario playbooks for the realistic cases. Length correlates negatively with use. The comprehensive plan that covers every eventuality is the one nobody opens, because at two in the morning nobody is reading forty pages.

We verify the contact pack by calling it

Incident response retainer, insurer with the policy number, legal counsel, regulator route where an obligation exists, critical suppliers and vendor account teams. An untested contact list is a list of assumptions. Calling each one in peacetime takes an afternoon and reliably finds two or three that are wrong.

We exercise it before we call it finished

A tabletop with the actual response team, against a scenario relevant to the business. The exercise output is a correction list rather than a score, because the point is to find the gaps while they are cheap. A plan that has never been exercised is a draft, regardless of how well it reads.

How we build it

Four phases, and the exercise is where the plan is finished.

A plan written and delivered is a draft. It becomes a plan when it has been run against a scenario by the people who would run it, and corrected for what that revealed.
  1. 01
    Weeks 1 to 2

    Establish the decisions before the document

    Who declares an incident, at what threshold, who authorises containment, who authorises spend, who speaks externally and who notifies whom. Those decisions are the plan. Writing the document before agreeing them produces a well-formatted set of unanswered questions.

    • Declaration threshold expressed in observable conditions
    • Named decision makers with named deputies
    • Pre-authorised containment boundaries
    • Spend authority for external response agreed in advance
  2. 02
    Weeks 3 to 4

    Write it short, and build the contact pack

    A core plan short enough to be read during an incident, with scenario playbooks of about two pages each. Then the external contact pack: responders, insurer, legal, regulator where applicable, critical suppliers and vendor account teams, verified rather than copied from an old document.

    • A core plan of a length somebody will actually read
    • Scenario playbooks for the realistic cases
    • A verified external contact pack, tested by calling
    • Out-of-band communication arrangements agreed
  3. 03
    Weeks 5 to 6

    Exercise it, and fix what the exercise finds

    A tabletop with the people who would actually respond, run against a scenario relevant to your business. The output is not a pass or fail, it is a list of corrections: the contact who has left, the decision nobody felt able to take, the system everyone assumed would be available.

    • A tabletop exercise with the real response team
    • A findings list from the exercise, not a certificate
    • Plan corrected against what the exercise revealed
    • Second exercise scheduled before the engagement closes
  4. 04
    Ongoing

    Keep it current, because it decays quietly

    People leave, numbers change, systems are replaced and suppliers change. A plan decays without anybody noticing, and the decay is invisible until the plan is used. A short quarterly check of contacts and a documented review after any material change is what keeps it usable.

    • Quarterly contact verification
    • Review after any material change to people or systems
    • An exercise at least annually, ideally more often
    • Offline copies refreshed when the plan changes
Where this matters most

Six UAE situations where a plan gets written, and one where it should have been.

The triggers are usually external. An insurer, a customer, a regulator or a board asking the question. Occasionally it is an incident somewhere else in the sector, which is the cheapest possible prompt.

A regulated firm with a notification obligation

Where an obligation requires notification within a defined window, the clock starts at a point somebody has to recognise. That makes the declaration threshold and the escalation path a regulatory control rather than an operational preference, and it needs to be written, exercised and evidenced rather than understood.

An organisation renewing cyber insurance

Insurers increasingly ask whether a plan exists, when it was last exercised, and whether the notification route is documented. Those three questions are answerable in a sentence each if the work has been done and are uncomfortable if it has not. The notification route with the policy number belongs in the plan itself.

A group where the answer to who decides is unclear

Multi-entity groups have the hardest version of this problem, because the person who can authorise taking a subsidiary system offline may be in another company and another time zone. Working that out during an incident costs hours. Working it out in advance costs one meeting.

An operator where disconnecting means stopping production

Containment is straightforward when the cost of disconnecting is inconvenience. It is a genuine business decision when disconnecting halts a plant, a line or a berth. That decision cannot be made by IT and it cannot be made quickly unless the authority and the boundary were agreed beforehand.

A healthcare organisation where systems cannot simply be turned off

Clinical systems change the containment calculation entirely, and the plan has to reflect that with clinical input rather than assuming a standard playbook applies. What the plan must contain is who makes that trade-off, on what information, and what the fallback to manual process looks like.

An organisation that has just watched a peer be attacked

The cheapest possible prompt, and the best time to do this work. Attention is available, the board is asking, and nobody is under pressure. A plan written and exercised in that window costs a fraction of one written during the aftermath of your own incident, and it is considerably better.

Three positions

How UAE organisations are prepared for an incident.

The middle column is the majority. A plan exists, it was written properly, it has never been exercised, and the contact list is three years old.
A written plan exists
Exercised and currentYes
A plan that has never been usedYes
No planNo
Available when the network is not
Exercised and currentYes
A plan that has never been usedNo
No planNot applicable
Declaration threshold actionable
Exercised and currentYes
A plan that has never been usedVague
No planNot applicable
Containment pre-authorised
Exercised and currentYes
A plan that has never been usedNo
No planNo
Contacts verified
Exercised and currentYes
A plan that has never been usedStale
No planNone
Scenario playbooks
Exercised and currentYes
A plan that has never been usedOne general procedure
No planNo
Exercised in the last year
Exercised and currentYes
A plan that has never been usedNo
No planNo
External responders identified in advance
Exercised and currentYes
A plan that has never been usedNo
No planNo
Insurer notification route known
Exercised and currentYes
A plan that has never been usedRarely
No planNo
First hour of a real incident
Exercised and currentStructured
A plan that has never been usedImprovised
No planChaotic
Feature
Exercised and current
A plan that has never been used
No plan
A written plan exists
YesYesNo
Available when the network is not
YesNoNot applicable
Declaration threshold actionable
YesVagueNot applicable
Containment pre-authorised
YesNoNo
Contacts verified
YesStaleNone
Scenario playbooks
YesOne general procedureNo
Exercised in the last year
YesNoNo
External responders identified in advance
YesNoNo
Insurer notification route known
YesRarelyNo
First hour of a real incident
StructuredImprovisedChaotic
The scenario playbooks

Five scenarios, and how the first hour differs in each.

These are the playbooks we build for most UAE organisations. The point of separating them is that the first moves genuinely differ, and a general procedure blurs exactly the distinctions that matter under pressure.
ScenarioWhat the first hour is aboutThe decision that cannot wait
RansomwareDetermining spread and stopping it, before anything elseWhether to disconnect, and who is permitted to authorise it
Business email compromiseEstablishing what the account did, and whether money has movedContacting the bank, and who can instruct a recall
Data exfiltrationEstablishing what left, when, and whose it wasWhether a notification obligation has been triggered
Insider actionPreserving evidence before the person is awareWho is told, and in what order, including HR and legal
Critical supplier outage or compromiseEstablishing your exposure through their access and their dataWhether to sever the connection, and who owns that relationship
How an engagement runs

Five steps, ending with an exercise rather than a document.

Typically four to six weeks including the tabletop. The writing is fast. Getting the decision makers into a room to agree who decides what is what sets the pace.
  1. 1

    Establish the decisions and the obligations

    Who declares an incident and at what threshold, who authorises containment and within what boundary, who authorises emergency spend and up to what value, who speaks externally, and what notification obligations apply from regulation, contract or insurance. These are agreed before anything is written.

  2. 2

    Write a core plan somebody will read

    Short, with the three questions that matter answered on the first page: is this an incident, who decides, and what can be taken offline. Roles with named individuals and named deputies. Communication arrangements that do not assume the corporate network or corporate email are available or trusted.

  3. 3

    Build scenario playbooks for the realistic cases

    Ransomware, business email compromise, data exfiltration, insider action and critical supplier compromise, each around two pages, because the first hour genuinely differs between them. A single general procedure covers all of them badly and reads as though nobody had a specific incident in mind.

  4. 4

    Assemble and verify the contact pack

    Responders, insurer with the policy number and notification route, legal counsel, regulator where applicable, critical suppliers and vendor account teams. Then verification by contacting each one, because an untested list is a list of assumptions and typically two or three of them are wrong.

  5. 5

    Exercise, correct, and schedule the next one

    A tabletop with the real response team against a scenario relevant to your business, producing a correction list rather than a score. The plan is updated against what the exercise found, offline copies distributed, and the next exercise scheduled before we finish, because that is what stops the plan decaying.

Straight answers

What organisations ask about incident response plans.

NIST published revision 3 of its incident response guidance in April 2025, titled Incident Response Recommendations and Considerations for Cybersecurity Risk Management, a CSF 2.0 Community Profile. Its abstract describes helping organisations incorporate incident response throughout their cybersecurity risk management activities, and its stated aims are preparing for responses, reducing incident frequency and impact, and improving detection, response and recovery efficiency.

Shorter than most people write. A core plan somebody can read in ten minutes, with scenario playbooks of about two pages each. Length correlates negatively with use, because at two in the morning nobody reads forty pages. Everything that is reference material rather than action belongs in an appendix or in a separate document.

Three, and they recur almost universally. No actionable declaration threshold, so nobody knows when this becomes an incident. No pre-authorised containment, so hours are lost between recognising the need to disconnect and being permitted to. And a contact list nobody has verified, which typically contains at least two people who have left.

Not only where the incident might make it unavailable. A plan held solely on the corporate file share or in the collaboration platform is inaccessible in exactly the scenarios it exists for. Printed copies with the people who would need them, plus a copy held outside the environment, is unglamorous and it is the point.

For the realistic cases, yes, because the first hour genuinely differs. Ransomware is about stopping spread. Business email compromise is about whether money has moved. Data exfiltration is about what left and whose it was. Insider action is about preserving evidence before the person knows. One general procedure covers all four badly.

A named person and a named deputy, and the threshold should be expressed as observable conditions rather than as a severity judgement. The person likely to be holding the phone at three in the morning is rarely the most senior available, and a threshold they can apply without escalating first is what converts hesitation into action.

Because it is where the damage accumulates. The delay between recognising that a system should be disconnected and being permitted to disconnect it is measured in hours in most organisations, and in ransomware those hours are the difference between one site and the whole estate. Pre-authorising it, with a clear boundary, removes the delay entirely.

Yes, and specifically who speaks and to whom. Customers, staff, regulators, insurers, press and, where relevant, the market. Deciding that in advance avoids the situation where several people say different things in the first day, which is a reputational problem that outlives the technical one and is entirely self-inflicted.

At least annually, and more often where the team changes or the risk profile is high. The exercise is not a test to pass, it is the mechanism by which the plan gets corrected while corrections are cheap. Every exercise we run finds something, and the organisations that exercise most find the least, which is the point.

The people who would actually respond, which is more than IT. Whoever declares, whoever authorises containment, whoever authorises spend, whoever speaks externally, and representatives from the functions the incident would affect. An exercise attended only by IT tests the technical response and leaves the decisions untested, which is the half that fails.

They overlap and are not the same. Incident response is about handling the event: detecting, containing, eradicating and recovering. Business continuity is about how the organisation keeps operating while that happens. Both need to exist, they need to reference each other, and the handover point between them should be explicit rather than assumed.

It is worth deciding in advance rather than during. Engaging specialist responders at the point of an incident means negotiating a contract under pressure, which is slow and expensive. Whether a retainer, a pre-agreed rate card or simply an identified firm with an established relationship, the decision belongs in the plan rather than in the incident.

The notification route and the policy number belong in the plan itself, because insurance policies commonly require prompt notification and may direct which responders can be engaged. Discovering that requirement during an incident, after engaging a firm the policy does not cover, is a recoverable mistake that costs a great deal.

A short quarterly verification of contacts, a review after any material change to people, systems or suppliers, and an exercise at least annually. Plans decay silently. Nobody notices that three contacts have left, and nobody will notice until the plan is used, which is the worst possible moment for the discovery.

We scope per organisation, driven by how many entities and scenarios are in scope and whether a tabletop exercise is included, which it should be. Reviewing an existing plan is quicker than writing one and is usually the right starting point, since most organisations have something that needs correcting rather than nothing.
Test your existing plan

Fifteen questions to ask about the plan you already have.

Most organisations have a plan. These are the questions that establish whether it would work, and they can be answered in an hour without any external help.

Could you find it

  • Where is it stored?
    If the answer is only the file share, that is a finding.
  • Is there an offline copy?
    With the people who would need it.
  • When did anyone last open it?
    Access logs answer this honestly.
  • How long is it?
    Length is inversely related to use.
  • Would a new joiner understand it?
    They may be the one on call.

Could you act on it

  • What is the declaration threshold?
    Observable conditions, not a judgement.
  • Who declares, and who deputises?
    Both named, not roles.
  • Who can take a system offline?
    Pre-authorised, with a boundary.
  • Who can authorise emergency spend?
    And up to what value.
  • Who speaks to customers and press?
    Decided now, not then.

Is it current

  • Are all the contacts still employed?
    Check, do not assume.
  • Have the numbers been dialled?
    A contact pack is untested until called.
  • Does it reference systems you still run?
    Plans outlive platforms.
  • Is your insurer notification route in it?
    With the policy number.
  • When was it last exercised?
    If never, it is a draft.
Related reading

The pages around this one.

Incident response

The reactive service, for when something has already happened.

Learn more

Business continuity planning

How the organisation keeps operating while the incident is handled.

Learn more

CIS Controls assessment

Where incident response management sits as control 17 of eighteen.

Learn more
Next step

Ask three people where the incident response plan is stored. Then ask when they last opened it.

If the answer to the first is the file share and the answer to the second is never, you have the two most common findings already. Both are fixable in weeks, and neither is fixable during an incident.

Book an incident response planning sessionCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Tabletop Exercise

Test the decisions, not the documentation

Learn more

Incident Response

24/7 incident response and forensics in Dubai

Learn more

Business Continuity Planning

BCP, RPO/RTO design, and DR runbook authoring

Learn more

CIS Controls Assessment

Eighteen controls, assessed and re-assessed

Learn more

Disaster Recovery & BC

Business continuity and disaster recovery planning

Learn more

Ransomware Protection

Defender XDR and Sentinel-driven ransomware defense

Learn more

IT Risk Assessment

A short register with an owner against every risk

Learn more

SOC-as-a-Service

24/7 SOC on Microsoft Sentinel

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy