Managed SOC in Abu Dhabi · NESA, ADGM & Energy CII

A managed SOC in Abu Dhabi has to satisfy two things at once: the federal monitoring expectations under NESA / UAE Information Assurance Standards, and the operational reality of the capital’s estate — energy and utilities with significant OT, sovereign-investment and government entities with strict data-residency, ADGM fintechs under FSRA, and DoH healthcare under ADHICS. Macksofy designs and runs the SOC to map onto those control sets rather than bolting a generic MDR feed onto a regulated environment.

Data residency is the first design decision, not an afterthought. For Abu Dhabi government, energy and sovereign-investment clients, log and telemetry storage is kept in-country — Azure UAE Central (Abu Dhabi), AWS me-central-1, or the client’s own tenant / sovereign-cloud (Core42) — with a documented residency posture for the regulator. We architect the SIEM (Microsoft Sentinel, Splunk or the client’s incumbent) so that raw logs and detections never leave the UAE where the entity’s classification or NESA expectations require it, and we make that residency provable in an audit.

Detection engineering is built to NESA and the threat picture, not a vendor’s default rule pack. We stand up use-cases mapped to MITRE ATT&CK and to the NESA / UAE IAS monitoring controls, tuned to the client’s crown jewels — settlement and customer-data flows for ADGM fintechs, patient-record and medical-device traffic for healthcare, and the IT/OT boundary for energy operators. Every detection ships with a documented logic, a tuned threshold and a runbook, so the SOC produces investigable alerts rather than noise.

IT and OT are monitored as one picture where the client’s estate demands it. For the ADNOC ecosystem and utilities we ingest OT-network telemetry (passive taps, historian and engineering-workstation logs) alongside IT, watch the north-south boundary and remote-access paths into the process network, and alert on the lateral-movement and protocol-anomaly patterns that precede an OT incident — with safety-and-uptime constraints respected and no active probing of production controllers.

Incident response is part of the service, not a separate purchase. The SOC runs tiered triage (L1 monitoring, L2 enrichment and correlation, L3 hunt and response) with defined escalation, and a Macksofy DFIR responder is on call for confirmed incidents — containment guidance, forensic preservation and the regulator-notification support that NESA, the relevant CERT (aeCERT/CSC) and sector rules require. We pre-agree the notification thresholds and timelines so a real incident does not become a compliance scramble.

Reporting is regulator- and board-ready. Monthly and quarterly packs map detection coverage and incidents to the NESA / UAE IAS monitoring controls (and ADHICS or FSRA where relevant), with a KRI dashboard, a coverage-gap view against ATT&CK, and a one-page summary the entity’s secretariat can take into the governance review. When the regulator or an internal audit asks ‘show me your monitoring works,’ the evidence is already assembled.

Delivery blends remote operations with Abu Dhabi presence. The 24×7 monitoring runs from Macksofy’s SOC against in-country log storage; senior leads fly Mumbai BKC → AUH (~3.5 hours) for onboarding, quarterly reviews and post-incident readouts, reaching Al Maryah Island, Masdar City or KIZAD in 30-45 minutes from the airport. For sustained government and energy programmes we maintain an embedded UAE lead and brief the data-handling and access model up front.

Onboarding is structured and fast. A typical Abu Dhabi SOC stand-up runs log-source discovery and residency design in the first weeks, use-case and runbook build through the first month, and a tuning-and-hand-holding phase before steady-state — with the option of a co-managed model where the client’s own analysts work alongside Macksofy’s on shared detections and a shared SIEM.