Definition

UAE cyber incident reporting obligations are distributed across multiple sectoral regulators — the Central Bank of UAE (CBUAE), the Securities and Commodities Authority (SCA), the Telecommunications and Digital Government Regulatory Authority (TDRA), the Information Security Regulation (ISR) administered by NESA, and the Dubai Electronic Security Center (DESC) — each with distinct notification thresholds, timelines and content requirements. Organisations subject to multiple regulators must maintain a cross-regulator notification matrix and automated escalation workflow to meet the tightest applicable deadline.

Why it matters

The pressure on Regulatory (UAE/GCC) programmes is shifting in specific, observable ways:

• CBUAE requires notification of critical cyber incidents within 2 hours of classification; SCA requires notification within 24 hours; missing the tighter CBUAE window while meeting the SCA window constitutes a CBUAE violation even if the SCA obligation is satisfied.
• TDRA's Cybersecurity Regulation (Resolution No. 60 of 2020) applies to licensed telecom and cloud providers; non-notification of significant incidents triggers fines and potential licence suspension under TDRA enforcement powers.
• ISR/NESA-regulated entities (critical national infrastructure) must notify NESA within 4 hours; failure to report compounds incident severity classification and may trigger mandatory public disclosure.
• Dual-jurisdiction incidents — affecting both UAE mainland and DIFC or ADGM entities — require simultaneous notification to the sector regulator and the applicable free-zone authority; a single notification template fails both.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• Cross-regulator notification matrix — regulator name, applicable entity type, notification threshold (incident category), timeline, notification channel, content requirements, responsible role.
• Incident classification procedure — severity levels (Critical/High/Medium/Low), decision tree for regulatory notification trigger, approver.
• Incident notification records — incident ID, classification timestamp, notification sent timestamp, regulator reference number, content filed.
• SIEM alert log (e.g. Microsoft Sentinel, Splunk) — event source, severity, alert timestamp, analyst acknowledgement time, escalation to CISO timestamp.
• Regulator communication archive — email/portal submission records, regulator acknowledgement, follow-up correspondence.
• Post-incident review report — timeline reconstruction, notification compliance assessment, lessons learned, process improvement actions.

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: Compliance Officer and CISO jointly build the cross-regulator notification matrix covering CBUAE, SCA, TDRA, NESA/ISR and DESC; validate against each regulator's most recent published guidance.
• Day 31–60: IT Security Manager configures SIEM (Sentinel/Splunk) playbook to auto-escalate Critical and High severity alerts to on-call CISO within 30 minutes; links escalation to notification matrix.
• Day 61–90: Incident Response Lead drafts pre-approved notification templates for each regulator (content fields pre-populated per requirement); conducts tabletop exercise simulating simultaneous CBUAE + DESC notification.
• Day 90+: Compliance Officer integrates notification tracking into GRC platform; establishes post-notification review workflow; trains legal and communications teams on regulator engagement protocol.
• Ongoing: Review notification matrix quarterly for regulatory updates; conduct bi-annual incident response drill with regulator notification scenario; report notification compliance rate to board Risk Committee.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• CBUAE notification compliance: 100% of critical incidents notified within 2 hours of classification; zero late notifications.
• Cross-regulator coverage: notification matrix reviewed and validated against current regulator guidance at least quarterly.
• Incident classification time: ≥90% of SIEM Critical alerts classified (Critical/High/Medium) within 30 minutes of detection.
• Notification template readiness: pre-approved templates for all 5 regulators (CBUAE, SCA, TDRA, NESA, DESC) reviewed and updated within 30 days of any regulator guidance change.
• Tabletop exercise cadence: ≥2 exercises per year including cross-regulator notification scenario; post-exercise findings remediated within 45 days.

The working checklist

Use this list during your next Regulatory (UAE/GCC) review cycle. The phrasing is intentionally observable — every item is something a reviewer can sample for, not an aspiration.

• Verify: supervisory return / self-assessment.
• Verify: thematic review responses.
• Verify: regulator on-site evidence pack.
• Verify: controls listed against the regulator but not operating consistently.
• Verify: thematic-review responses prepared in the week of the visit.
• Verify: no single source of truth across multiple supervisors.

Pitfalls we keep seeing

Across MAST Consulting Group's Regulatory (UAE/GCC) portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: controls listed against the regulator but not operating consistently. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: thematic-review responses prepared in the week of the visit. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: no single source of truth across multiple supervisors. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: evidence packs that are unique to each regulator instead of harmonised. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on Regulatory (UAE/GCC) engagements because the integrations are cheap and the evidence is defensible:

• data extracts from core systems on a fixed cadence — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• a unified control framework (UCF) in a GRC tool or curated spreadsheet — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• evidence repository with regulator tagging — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs Regulatory (UAE/GCC) programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this checklist is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for Regulatory (UAE/GCC) programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.