ADHICS v2 Control Mapping: A Practical Guide for UAE Healthcare Entities

ADHICS v2 expanded scope to include a broader set of healthcare entities (hospitals, clinics, day surgery centres, telehealth providers, payers, and certain service providers), introduced clearer compliance tiers based on entity classification, strengthened governance and accountability requirements at the board level, deepened third-party and supply chain control expectations, and added explicit requirements around cloud, telehealth, and connected medical devices.

The Department of Health Abu Dhabi assesses compliance against ADHICS, and findings are tied to licensing implications a strong incentive for substantive rather than cosmetic compliance.

ADHICS v2 is organised across governance and risk management, asset management, human resources security, physical and environmental security, access control, operations security, communications security, system acquisition and development, third-party security, incident management, business continuity, and compliance.

Within each domain, controls are grouped by basic, transitional, and advanced tiers, mapped to entity classification. Higher-tier entities must implement more controls and demonstrate higher maturity.

Most UAE healthcare entities already maintain some combination of ISO 27001 (ISMS certification), NIST CSF (risk-based framework), and HIPAA (for entities handling US patient data or partnering with US providers).

Treating ADHICS as a standalone framework duplicates effort. Crosswalking it onto existing controls means one implementation, one set of evidence, multiple frameworks satisfied.

ADHICS governance requirements (information security policy, roles and responsibilities, risk management process, management review) map directly to ISO 27001 clauses 5 (leadership), 6 (planning), 9 (performance evaluation), and Annex A.5 controls.

On the NIST CSF side, they align with the Govern (GV) and Identify (ID) functions specifically GV.OC (organisational context), GV.RM (risk management strategy), and ID.RA (risk assessment).

Practical implication: a single risk register, a single policy framework, and a single management review cycle can serve all three frameworks if structured intentionally.

ADHICS access control requirements (user registration, privileged access, password management, segregation of duties, secure log-on) map to ISO 27001 Annex A.5.15 through A.5.18, A.8.2, and A.8.5.

NIST CSF equivalents sit in Protect (PR.AC, PR.AA in v2) covering identity management, authentication, and access control.

For HIPAA, the equivalent is the Technical Safeguards Access Control standard (45 CFR 164.312(a)) plus the Administrative Safeguards Information Access Management standard.

Implementing MFA on EHR systems, enforcing least privilege, and conducting quarterly access reviews satisfies all four simultaneously when evidence is centralised.

ADHICS operations controls (change management, capacity management, malware protection, backup, logging, vulnerability management) map to ISO 27001 Annex A.8.7 through A.8.16 and A.8.32, NIST CSF Protect (PR.PS, PR.IR) and Detect (DE.CM), and HIPAA's Audit Controls and Integrity standards.

Healthcare-specific nuance: ADHICS emphasises medical device patching and segmentation, which goes beyond standard IT vulnerability management. Build a separate medical device inventory and patch programme do not assume your IT VMP covers it.

ADHICS third-party controls require due diligence, contractual security clauses, monitoring, and offboarding procedures for any vendor or partner accessing health data.

These align with ISO 27001 Annex A.5.19-A.5.23 (supplier relationships), NIST CSF Govern (GV.SC supply chain risk management), and HIPAA's Business Associate Agreements requirement.

Operational tip: a single vendor register tagged with the frameworks each vendor must satisfy avoids running parallel vendor programmes.

ADHICS requires documented incident response procedures, classification, escalation, and timely notification to the Department of Health for defined incident types.

ISO 27001 covers this in Annex A.5.24-A.5.28; NIST CSF in Respond (RS) and Recover (RC); HIPAA in the Security Incident Procedures standard and the Breach Notification Rule.

Run one incident response process with multiple notification destinations rather than separate playbooks.

ADHICS requires BIA, BCP, DR planning, and regular testing aligned to ISO 27001 Annex A.5.29-A.5.30, ISO 22301 for those who pursue it, NIST CSF Recover function, and HIPAA's Contingency Plan standard.

Healthcare-specific expectation: clinical service continuity plans (not just IT DR) for critical patient-facing services.

Sector-specific requirements that don't have direct ISO equivalents include explicit medical device security expectations, telehealth platform controls, patient data classification aligned to UAE healthcare data categories, mandatory regulatory reporting for defined incidents, and prescribed minimum log retention periods for clinical systems.

These need to be implemented additionally even on top of a mature ISO 27001 ISMS.

Step 1: take your existing control library (ISO 27001 Annex A is a good base). Step 2: tag each control with the ADHICS, NIST CSF, and HIPAA requirements it satisfies. Step 3: identify ADHICS-specific controls with no existing coverage and add them. Step 4: define a single evidence specification per control so one piece of evidence satisfies all mappings. Step 5: assign owners and review cycles aligned to the strictest framework requirement.

Waaqi (واقي) ships with a pre-built ADHICS v2 control library, automated crosswalks to ISO 27001, NIST CSF, and HIPAA, gap assessment workflows tailored to ADHICS entity tiers, evidence collection mapped to multiple frameworks simultaneously, incident response with regulator notification timers, third-party risk management aligned to ADHICS requirements, and executive dashboards showing ADHICS posture against the Department of Health expectations.

Hosted in the UAE to satisfy data residency expectations for healthcare data.

Phase 1 (weeks 1-4): scope definition, entity classification, gap assessment against ADHICS v2 controls. Phase 2 (weeks 5-12): remediate critical gaps, implement medical-device-specific controls, finalise vendor contracts. Phase 3 (weeks 13-20): build evidence repository with multi-framework tagging, run tabletop incident exercise, complete first internal audit. Phase 4 (ongoing): continuous monitoring, quarterly management review, annual reassessment.

ADHICS v2 is more demanding than its predecessor, but the work overlaps heavily with frameworks you already operate. The organisations that succeed will treat ADHICS as part of an integrated compliance programme, not a standalone burden.

Want a ready-made ADHICS v2 to ISO 27001 / NIST CSF / HIPAA crosswalk and gap assessment? Book a demo of Waaqi at www.waaqi.ai.