UAE Critical Infrastructure Incident Reporting: 72-Hour Reality

In the United Arab Emirates, the seventy-two hour window is not a deadline. It is a sorting mechanism that decides which operators retain their licence to run critical infrastructure and which do not.

The phrase "incident reporting" suggests a single act, a notification dispatched once and acknowledged. The UAE reality is plural. An operator of a substation in Abu Dhabi, a refinery in Ruwais, a data centre in Dubai South, or a logistics hub in Jebel Ali does not file one report. It files several, to different authorities, on overlapping clocks, with different evidentiary thresholds. The architecture is fragmented by design, because the Emirates have chosen to combine federal cybercrime law, sectoral regulation by the relevant utility authority, and emirate-level competent bodies in cybersecurity. An operator that has not mapped this terrain before the incident will improvise during the incident, and improvisation under regulatory pressure is the most expensive form of crisis response known to industry.

The legal backbone: Federal Decree Law 5 of 2012 and what came after

Federal Decree Law 5 of 2012 on combating cybercrime, amended by Federal Decree Law 34 of 2021, defines the criminal layer. It is not, in itself, an incident reporting statute in the European sense. It criminalises unauthorised access, data theft, infrastructure interference, and a long list of related acts. It establishes that certain conduct against information systems of governmental authorities, critical installations, and financial institutions carries aggravated penalties. What it does for the operator is define the legal character of the event. An intrusion into a SCADA gateway is not a technical anomaly. It is, under UAE law, a criminal act with named victims, and the operator is one of them.

This criminal framing matters because it determines who in the chain is contacted, in what order, and with what content. A purely technical report to a sector regulator is incomplete if the same event also triggers a criminal complaint obligation, and a criminal complaint that does not preserve technical evidence is useless. The two streams have to be run in parallel from the first hour, by people who understand both registers.

Above the criminal layer sits a second layer of obligations, more recent, more operationally relevant. The UAE Cybersecurity Council, established in 2020, the Telecommunications and Digital Government Regulatory Authority (TDRA), and the emirate level cybersecurity centres, principally the Dubai Electronic Security Center and the Abu Dhabi Signals Intelligence Agency through its cybersecurity directorate, set the operational expectations. These expectations are codified in policy documents, in the UAE Information Assurance Standards issued by TDRA, and in sector specific frameworks for energy, water, telecommunications, finance, and aviation. The international anchors are visible in the architecture: NIST CSF 2.0 in the structure of identify, protect, detect, respond, recover; IEC 62443 in the OT segmentation expectations; ISO 27001 in the management system layer. The UAE has not copied any single framework. It has assembled its own from the parts that fit its administrative geography.

For the operator, this means that the regulatory map is not a single document. It is a set of overlapping obligations whose intersection has to be drawn before an incident, not during one. The operator who waits for the breach to discover which authority expects what will lose the seventy-two hours to confusion, not to investigation.

What seventy-two hours means in practice

The seventy-two hour window is not uniform across all UAE sectors, and treating it as a single number is the first mistake. In the financial sector, the Central Bank of the UAE has imposed reporting timelines that are tighter for material incidents, with initial notification expected within hours, not days, for events that affect customer data or financial stability. In the telecommunications sector, TDRA expects licensees to report significant incidents within defined windows, with the seventy-two hour benchmark applying to certain categories and shorter windows to others. In the energy and water sector, the relevant regulators, including ADNOC for the upstream and midstream operators that fall within its perimeter and the federal and emirate level utility regulators for distribution, set their own timelines, often referencing the broader cybersecurity council guidance.

What is consistent across these regimes is the structure of the obligation. The operator owes an initial notification, often within twenty-four hours, that contains the minimum facts: the nature of the event, the systems affected, the preliminary scope, the immediate containment measures, and a named point of contact. Within seventy-two hours, the operator owes a substantive update that adds technical detail, root cause hypothesis, impact assessment, and a forward plan. Within a longer window, typically thirty to ninety days depending on sector, the operator owes a final report that closes the loop with confirmed root cause, lessons learned, and remediation evidence.

The trap inside this structure is that the initial notification is often filed by personnel who do not yet know what they are looking at. They know there is an alarm, they know a system is degraded, they may know that an exfiltration alert has fired. They do not yet know whether the event is a ransomware deployment that has been resident for weeks, a misconfiguration, an insider action, or a coordinated intrusion. Filing the initial notification accurately under this uncertainty requires a template that has been pre-drafted, pre-approved, and pre-tested in tabletop exercises. Operators who try to write the notification from scratch at three in the morning produce documents that the regulator later uses against them, because the initial framing tends to anchor the entire investigative narrative.

Who reports to whom, and the geometry of the call list

An industrial operator in Abu Dhabi that suffers a cyber incident affecting operational technology does not have the luxury of a single point of contact. The geometry of the notification is roughly as follows, and the operator who has not rehearsed this geometry will discover it under duress.

The criminal channel runs to the Public Prosecution and, in the investigative phase, to the cybercrime units of the relevant police force, principally Abu Dhabi Police or Dubai Police depending on jurisdiction. The sector regulatory channel runs to the competent authority for the affected infrastructure, which may be the relevant utility regulator, the financial regulator, the telecommunications regulator, or the aviation authority. The cybersecurity channel runs to the UAE Cybersecurity Council at the federal level and to the emirate level centre, Dubai Electronic Security Center for Dubai operators or the relevant Abu Dhabi body for Abu Dhabi operators. The data protection channel, where personal data is involved, runs to the UAE Data Office under Federal Decree Law 45 of 2021, with shorter timelines for events affecting individuals' rights. Where the operator is located within a free zone with its own regulatory perimeter, such as the DIFC or ADGM, there are additional reporting lines to the financial services regulators of those zones, the DFSA and the FSRA respectively, both of which have published their own incident notification expectations.

This list is not exhaustive. It is the minimum geometry an operator should have mapped on a single page, with names, telephone numbers, secure communication channels, and pre-agreed escalation routes. CISA and NIST 800-53 both stress that incident response procedures must include defined external communications. In the UAE context, this means a one page document, reviewed quarterly, that names the human being at each authority who picks up the phone at three in the morning. Operators who rely on general email addresses for first contact in a critical incident are operators who have not understood the speed at which these regulators expect to be informed.

What the report actually contains

The content of an incident report is where most operators underperform, not because they lack information, but because they do not know what to omit. A good initial notification is short, factual, and free of speculation. It states what is known, what is suspected, and what is unknown, in three clearly separated sections. It avoids legal conclusions, it avoids attribution, and it commits to a follow-up timeline that the operator can actually meet.

A substantive seventy-two hour report contains, at minimum, a description of the affected systems with reference to their function in the critical infrastructure landscape, a timeline of the event as currently understood with sources for each entry, a description of containment and eradication measures with status, an impact assessment that addresses service continuity, data confidentiality, and safety, an indication of any third party involvement including suppliers and managed service providers, and a forward plan with named owners and deadlines. The report should also state explicitly which other authorities have been notified, because the regulators talk to each other and inconsistencies between parallel reports are the fastest way to lose credibility.

What the report should not contain is also worth naming. It should not contain unverified attribution to threat actors or nation states. It should not contain speculative impact figures. It should not contain commercial damage estimates that have not been reviewed by legal counsel. It should not contain promises about remediation that the operator cannot keep within the stated timeframe. The regulator will read the report twice: once when it arrives, and once again at the end of the investigation when it is compared against what actually happened. Every overstatement in the first reading becomes a credibility deficit in the second.

The book BOSWAU + KNAUER. From Building to Security Technology argues, in its chapters on industry and logistics, that a security system which documents everything without deciding anything is an archive, and one that decides without documenting is a risk. The principle applies directly to incident reporting. The seventy-two hour report is the moment where the operator demonstrates that it has both: a documented record of the event and a defensible set of decisions taken in response.

The failure modes the regulators see most often

Operators fail at incident reporting in patterns that are visible to anyone who has read more than a handful of post-incident reviews. The first pattern is silence, the operator who does not report because it believes the event is contained or commercially sensitive. This pattern carries the highest penalties, because the regulator discovers the event later through other channels and the non-reporting itself becomes the primary violation. The second pattern is the underspecified initial notification, the report that says "we are investigating an anomaly" without naming systems, scope, or timeline. This pattern triggers immediate regulatory attention because it signals an operator who does not have command of its own environment.

The third pattern is the overspecified initial notification, the report that commits to root cause and attribution in the first hours and then has to walk back its conclusions across the next several weeks. This pattern damages the operator's standing because it suggests either incompetence in forensic analysis or willingness to mislead. The fourth pattern, the most common, is the inconsistent set of parallel notifications, where the report to the sector regulator says one thing and the report to the data office says another. This pattern is almost always the result of multiple departments reporting without central coordination, and it is fixed not by better templates but by a single incident commander who signs all external communications.

The fifth pattern, which deserves separate mention, is the operator who reports correctly but cannot evidence what it reported. The notification states that containment was achieved at a specific hour, but the logs do not support the claim. The notification states that no personal data was exfiltrated, but the DLP system was not configured to detect the relevant flows. This is where IEC 62443 and ISO 27001 come back into the conversation, because the management system that should have produced the evidence is the same management system the operator declared compliant in its last audit. ASIS International, in its guidance on enterprise security risk management, and the GDV, in its loss prevention work, both make the point that a control which cannot be evidenced is a control that does not exist for regulatory purposes.

What holds

The seventy-two hour window in the UAE is a test of preparation, not of speed. Operators who have mapped the regulatory geometry, drafted their notification templates, identified their incident commander, and rehearsed the chain of communications can meet the window without difficulty. Operators who have not done this work will not meet it, regardless of how good their technical response team is, because the bottleneck is not technical analysis but organisational coordination across legal, technical, and external communications functions under time pressure.

The harder truth, visible to anyone who has worked inside a regulated critical infrastructure operator in the Emirates, is that the seventy-two hour reporting obligation is the visible portion of a much larger obligation, which is to operate the infrastructure in a way that makes the report defensible when it has to be filed. The report is the artefact. The defensibility is the substance. An operator who treats the report as the obligation will produce documents that read well on the day they are filed and read badly six months later when the regulator returns with follow-up questions. An operator who treats the underlying security posture as the obligation will produce reports that hold under scrutiny because they describe a system that was already there.

For operators who want to test where they stand against this geometry before the next event forces the test on them, the three-to-five day audit described as Path II in this house's working method delivers the relevant deliverables: a mapped notification geometry, a tested template set, a gap analysis against the sector specific obligations, and a documented assignment of roles across legal, technical, and communications functions. The audit does not replace the operator's own preparation. It compresses six months of internal coordination into a structured external review whose output the operator owns and can use with or without further engagement.

Frequently asked questions

Who must report?

Operators of critical infrastructure in the UAE that fall within the perimeter of federal or emirate level critical infrastructure designations, licensees of regulated sectors including financial services, telecommunications, energy, water, aviation, and healthcare, and entities processing personal data under Federal Decree Law 45 of 2021. The obligation attaches to the legal entity that operates the affected system, not to the parent group, although group level reporting may be required separately. Free zone entities in DIFC and ADGM have additional obligations to their respective financial services regulators. Managed service providers may also have direct reporting obligations independent of their clients.

In what window?

The headline number is seventy-two hours for substantive reporting, but the operational reality is layered. Initial notification is typically expected within twenty-four hours, and for certain categories of incident, particularly in financial services and personal data breaches affecting individuals' rights, the window can be as short as a few hours. The seventy-two hour mark applies to the substantive update with technical detail and impact assessment. Final reporting follows in a longer window of thirty to ninety days depending on sector. Operators should treat the twenty-four hour mark, not the seventy-two hour mark, as the binding clock.

To which authority?

The answer depends on the nature of the incident and the sector of the operator. The minimum set typically includes the sector regulator, the emirate level cybersecurity centre, the UAE Cybersecurity Council at federal level, the UAE Data Office where personal data is involved, and the relevant criminal authority where criminal conduct is suspected. Free zone operators add their zone regulator. Cross-border operators may have additional obligations under foreign regimes. The geometry should be mapped before the incident on a single document with named contacts, secure channels, and escalation routes. Generic email addresses are not sufficient for first contact.

What if reporting is missed?

The consequences range from administrative fines to licence revocation, with the severity depending on sector, the nature of the underlying incident, and whether the non-reporting is judged negligent or deliberate. Beyond the direct regulatory consequences, missed reporting damages the operator's standing in subsequent regulatory interactions, complicates insurance recovery, and creates personal liability exposure for named officers under Federal Decree Law 5 of 2012 and sector specific statutes. The reputational consequences within the regulatory community are often more lasting than the financial penalties. Operators who miss reporting once tend to be examined more closely thereafter, which is a cost that compounds across every subsequent audit cycle.