- NESA was folded into the UAE Cyber Security Council's Information Assurance framework, but the original control catalogue still drives most healthcare assessments.
- Abu Dhabi facilities answer to ADHICS first, a healthcare-specific standard built on ISO 27001 and the NESA controls, mandated by the Department of Health.
- Saudi providers work primarily against the NCA's Essential Cybersecurity Controls, with sector guidance layered on top from the health regulator.
- Most programmes fail on evidence and asset inventory, not on policy writing.
What "NESA compliance" actually means now
NESA, the National Electronic Security Authority, no longer exists as a standalone body. Its regulatory function moved into the UAE Cyber Security Council, and the control set it published is now maintained as part of the UAE's Information Assurance (IA) regulation. Practitioners and RFPs still say "NESA compliance" because the control numbering and structure survived the reorganisation almost unchanged, so the name stuck. If a UAE healthcare tender asks for "NESA compliance," it is asking for alignment to that IA control catalogue, not a certificate from an agency that no longer issues one.
That distinction matters for a GRC lead because it changes who you talk to during an audit and which document version you cite. Citing a retired NESA circular by its old reference number in a 2026 audit response is a small thing that makes a reviewer trust the rest of your evidence less.
The frameworks a GCC healthcare provider actually has to reconcile
A single hospital group operating across the UAE and Saudi Arabia is rarely working to one standard. It is reconciling several, and the overlaps are not always clean.
UAE federal and Dubai-licensed facilities
Outside Abu Dhabi, UAE healthcare providers align to the IA/NESA control set for information security, plus Federal Law No. 2 of 2019 on the use of ICT in the health fields, which governs how patient data can be stored, processed and shared, including restrictions on cross-border transfer. Dubai-licensed facilities also carry Dubai Health Authority data protection obligations on top. None of this is optional for a facility handling electronic health records, and none of it substitutes for the others: a provider can be aligned to IA controls and still be in breach of the ICT health law if patient data leaves the country through a poorly vetted cloud service.
Abu Dhabi: ADHICS is the primary standard
Abu Dhabi facilities do not start from the general UAE IA controls. The Department of Health mandates ADHICS, the Abu Dhabi Healthcare Information and Cyber Security Standard, which is built on ISO 27001 with healthcare-specific additions covering medical device security, clinical system availability and patient data classification. ADHICS assessments are stricter about asset scope than a generic ISO audit: biomedical equipment, PACS systems and connected diagnostic devices are all in scope, not just the servers in the data centre.
Saudi Arabia: NCA controls plus sector guidance
Saudi healthcare providers work primarily against the National Cybersecurity Authority's Essential Cybersecurity Controls, with additional expectations from the health sector regulator layered on top for organisations classified as operating critical systems. The control language differs from the UAE frameworks in structure, but the underlying asks (access control, logging, incident response, third-party oversight) overlap enough that a provider running operations in both countries can build one control library and map it two ways, rather than running two separate compliance programmes from scratch.
The control areas assessors actually spend time on
Every framework above shares a small set of areas where audit findings cluster.
Data classification and where patient records actually live
Assessors ask for a data flow diagram before they ask for a policy. If nobody can show where an electronic health record is created, copied, backed up and eventually deleted, the classification policy on paper is worthless. This is the single most common gap in healthcare GRC programmes: shadow copies of patient data in shared drives, email attachments and vendor portals that were never brought into the classification scheme. A data classification and DLP platform built for regulated data that actually enforces the policy, rather than one that just labels documents, is what closes this gap in practice.
Identity, privileged access and clinical system accounts
Healthcare environments carry more shared and generic accounts than almost any other sector, because clinical staff rotate through shifts and systems are built around speed of access, not identity hygiene. Assessors will ask for evidence of periodic access review, not just an access control policy. A privileged access programme that has not been reviewed since go-live is a finding, regardless of what the original design intended.
Third-party and medical device risk
Radiology systems, lab information systems and biomedical devices are frequently supported by the vendor remotely, sometimes through connections the internal IT team does not fully control. Assessors increasingly ask for a vendor risk register that names these connections specifically, not a generic third-party policy. Legacy medical devices that cannot be patched are not a reason to skip this control; they are a reason to document the compensating control (network segmentation, monitoring, restricted access) and show it is actually in place.
Incident response and breach notification timelines
UAE and Saudi frameworks both expect a documented incident response plan with defined notification timelines to the relevant regulator, not just to management. For healthcare specifically, the plan has to account for clinical continuity: what happens to patient care if the electronic health record system is unavailable during a ransomware event. A plan that only covers IT recovery and skips clinical fallback procedures will not satisfy a healthcare-specific reviewer.
Why these programmes stall
The recurring reason a healthcare GRC programme fails an audit or drags on for years is not a missing policy. It is an asset inventory that never included biomedical devices, a risk register that lists generic risks instead of risks tied to named systems, and evidence that exists somewhere but cannot be produced on request. Compliance teams that write policies first and build the asset inventory later end up with a framework that looks complete on paper and falls apart the moment an assessor asks "show me."
Resourcing is the other constant problem. GRC in healthcare usually sits with one or two people who also own vulnerability management, vendor onboarding and awareness training. When budget gets cut, the audit-facing documentation is the last thing anyone touches, so it drifts out of sync with what the environment actually looks like within a year.
Building a programme that survives an audit, not just passes one
The sequence that holds up in practice starts with the asset inventory, not the policy set. Map every system that touches patient data, including biomedical devices and vendor-hosted platforms, before writing a single control document. From there, map each applicable framework (IA/NESA, ADHICS, NCA controls, whichever apply) against that asset inventory rather than against a generic control checklist, so gaps are visible per system rather than as an abstract percentage.
Risk assessments should reference the governance, risk and compliance fundamentals that tie policy to actual risk scoring, then feed directly into a prioritised remediation plan, not a spreadsheet that gets updated once a year before the audit. Vulnerability findings need to run on a cycle, not a one-off scan: a documented vulnerability management programme with defined remediation SLAs by asset criticality is what turns a scan report into evidence a reviewer accepts. And the control set needs to be tested by someone outside the team that built it. Independent penetration testing against the systems that actually hold patient data catches the gaps a self-assessment misses, and gives the audit file a piece of evidence that carries more weight than a completed checklist.
Readiness checklist before you call an auditor
- Asset inventory includes every system touching patient data, named individually, not as a category.
- Data flow diagram exists and matches what the classification policy claims.
- Access reviews for clinical and privileged accounts have run in the last two quarters, with evidence retained.
- Vendor risk register names every third party with remote access to clinical systems, including biomedical device support.
- Incident response plan covers clinical continuity, not just IT recovery, with notification timelines mapped to the regulator that actually applies.
- Vulnerability scan and remediation evidence is current, not from the last audit cycle.
- An independent test of the in-scope systems has run within the certification period, with findings tracked to closure.
