Patroklos PatroklouDHICS v2.0 is not a refresh of v1.0 — it is a structural rewrite. The Abu Dhabi Department of Health published v2.0 in 2024 and made it effective from August 2024, replacing the 2019 standard. v2.0 introduces six capability pillars, three control tiers (Basic, Transitional, Advanced), a 24-hour breach notification window, explicit AI-governance and Internet-of-Medical-Things (IoMT) controls, and a capability-based audit model that judges operating effectiveness rather than documentary completeness. This guide gives every existing v1.0 implementer the side-by-side comparison and a transition checklist to close the gap before your next DoH audit.
For the full standard walkthrough, see our ADHICS v2.0 compliance guide. This post focuses specifically on the diff.
## ADHICS v1.0 vs v2.0 at a glance
| Area | ADHICS v1.0 (2019) | ADHICS v2.0 (2024) |
|—|—|—|
| Structure | Flat catalogue of controls, one baseline for all entities | Six capability pillars + 11 control domains + three control tiers |
| Audit model | Documentation-based: produce policies, show they’re approved | Capability-based: prove the control operates effectively in practice |
| Breach notification | 72-hour window | 24-hour window + 4-hour initial containment for high-severity events |
| Tiering | One-size-fits-all | Basic / Transitional / Advanced — assigned by DoH |
| AI controls | Not addressed | Explicit AI governance requirements (data, model, deployment) |
| IoMT | Treated as generic device security | Dedicated IoMT controls: inventory, segmentation, lifecycle, vulnerability handling |
| Cloud | Limited guidance; cloud generally discouraged | Formally permitted with UAE data residency, sub-processor controls, and cross-border transfer rules |
| Mandatory policies | ~8 documented policies | 15+ documented policies |
| Maturity scoring | Pass / fail per control | Maturity ratings per domain; year-on-year improvement evidence required |
| Vendor / third-party | Contract clauses + supplier list | Due-diligence programme + ongoing compliance validation + cross-border transfer controls |
| Evidence type | Policies, procedures, sign-offs | Logs, tickets, training records, BCP test reports, vendor review minutes — operational artefacts |
## What’s genuinely new in v2.0
### 1. Six capability pillars (Governance, Resilience, Capabilities, Partnerships, Maturity, Innovation)
v1.0 organised controls as a single catalogue. v2.0 wraps them in six pillars that auditors score independently. The Innovation pillar is the headline addition — it groups AI, IoMT, and cloud controls together as forward-looking capabilities, not afterthoughts.
### 2. The three-tier control structure
v2.0 right-sizes obligations: a single-doctor clinic and a 400-bed hospital no longer carry the same control burden. Tiers are assigned by the DoH and broadly track entity size and PHI volume.
| Tier | Indicative entities | Examples of tier-specific controls |
|—|—|—|
| Basic | Small clinics, single-site pharmacies, low-volume diagnostic centres | Documented core policies, basic access control, backup, incident reporting |
| Transitional | Mid-size polyclinics, multi-site clinics, medium insurers, healthcare IT vendors | Risk register, BC/DR plan, MFA on critical systems, vulnerability management cadence |
| Advanced | Hospitals (typically 21+ beds), tertiary care, large insurers, large EMR/EHR vendors | PAM, SOC/SIEM monitoring, secure SDLC, encryption-at-rest for PHI, third-party assurance, AI/IoMT controls |
### 3. The 24-hour breach notification window
The single most operationally significant change. v1.0 allowed 72 hours; v2.0 requires you to notify the DoH within 24 hours of becoming aware of a confirmed breach involving PHI, with a 4-hour initial containment expectation for high-severity events. Operationally:
– 24/7 detection capability is mandatory in practice (in-house or managed SOC)
– Out-of-hours escalation paths must be documented, rehearsed, and tested
– A pre-approved DoH notification template should sit alongside your incident workflow
### 4. Explicit AI governance
v2.0 acknowledges that clinical AI is here — diagnostic imaging, triage decision-support, voice transcription — and introduces governance controls around it: data provenance, model risk assessment, bias monitoring, human-in-the-loop review, and incident handling specific to AI failures.
### 5. IoMT (Internet of Medical Things) controls
Infusion pumps, patient monitors, imaging modalities, networked surgical robots, and home-monitoring devices are now explicitly in scope. Because most clinical devices cannot run endpoint protection or be patched at the cadence of corporate IT, the practical controls are inventory, network segmentation, vulnerability disclosure handling, and a lifecycle/decommissioning policy.
### 6. Cloud and cross-border data transfer
v1.0 was effectively silent on cloud; v2.0 formally permits it under conditions: UAE data residency, controlled sub-processing, restricted cross-border transfers, and contractual evidence of supplier compliance. UAE regions of AWS and Azure are eligible — but only with the right contract clauses.
### 7. Capability-based auditing
The biggest behavioural change. v2.0 auditors will not accept a binder of approved policies as evidence that a control operates. Expect them to ask:
– “Show me the ticket where this access change was approved last month.”
– “Show me the BCP test report from the past year.”
– “Walk me through what your on-call nurse does when a workstation locks.”
– “Show me the vendor review minutes for your EMR provider.”
## The v1-to-v2 transition checklist (use this if you’re already compliant with v1.0)
If you hold v1.0 evidence and are preparing for a v2.0 audit, work through this checklist in order. Treat any item you cannot evidence as a gap.
### Governance & policy
– [ ] Re-issue the security strategy aligned to the six pillars
– [ ] Update the ISM appointment letter and security committee terms of reference
– [ ] Author or refresh the additional v2.0-mandated policies (AI use, IoMT lifecycle, cloud, cross-border transfer)
– [ ] Refresh the risk acceptance matrix with board approval
### Risk & controls
– [ ] Reassess the risk register against the new domains (AI, IoMT, cloud); add new risks where missing
– [ ] Map your existing controls to the eleven v2.0 domains and the assigned tier
– [ ] Reclassify residual risks under the v2.0 maturity rating model
– [ ] Rebuild your risk assessment using a v2.0 template
### Incident response
– [ ] Rewrite the incident response plan to a 24-hour DoH notification window
– [ ] Define the 4-hour initial containment runbook for high-severity events
– [ ] Confirm 24/7 detection and on-call coverage (in-house or contracted SOC)
– [ ] Tabletop the new workflow with a realistic ransomware or PHI-exfiltration scenario
### Third-party & cloud
– [ ] Re-issue vendor questionnaires under the v2.0 expectations
– [ ] Update contract clauses for breach notification, sub-processors, audit rights, cross-border transfer
– [ ] Confirm UAE data residency for every cloud-hosted PHI workload
– [ ] Document the cloud provider’s UAE-region attestation
### Technical controls
– [ ] Verify unique IDs, RBAC, and MFA on critical systems (Advanced tier)
– [ ] Confirm encryption-at-rest and in-transit for PHI
– [ ] Document IoMT inventory and segmentation evidence
– [ ] If using clinical AI: produce model risk assessment, data provenance log, bias and drift monitoring evidence
### Evidence for capability-based audit
– [ ] Collect 12 months of operational artefacts (logs, tickets, training records, BCP tests, vendor minutes)
– [ ] Brief frontline IT and clinical staff to be interviewable on the new processes
– [ ] Stand up a maturity dashboard with year-on-year improvement metrics per domain
## If you already operate ISO 27001
Most of v2.0’s structural changes mirror ISO 27001:2022 themes — risk-based, capability-led, continuous improvement. If you hold an ISO 27001 certificate, you can reuse 60–80% of the evidence for ADHICS v2.0 by cross-mapping controls. See our ADHICS to ISO 27001 cross-mapping guide for the control-by-control overlap.
## How Enactia accelerates the v1-to-v2 transition
Enactia ships with both v1.0 and v2.0 ADHICS control catalogues and lets you carry forward v1.0 evidence to v2.0 controls where they overlap — then surfaces exactly what’s new and unmapped. For organisations also running ISO 27001, NIST CSF, HIPAA, or HITRUST, the same evidence satisfies multiple frameworks at once. Request a 30-minute v1-to-v2 transition review with our compliance team.
## Frequently asked questions
### Is ADHICS v1.0 still valid?
No. v1.0 has been superseded by v2.0 effective August 2024. New DoH audits are conducted against v2.0, and existing v1.0 certifications must transition to v2.0 at the next audit cycle.
### Do I need to throw away all my v1.0 documentation?
No. Approximately 60–70% of v1.0 control evidence still applies to v2.0. The work is to extend that base with the new AI, IoMT, cloud, and policy requirements, and to add operational evidence (logs, tickets, training records) to support the capability-based audit model.
### What is the biggest change between v1.0 and v2.0?
Functionally, the 24-hour breach notification window. Strategically, the move from documentation-based to capability-based auditing — auditors now expect to see the control operating in real life, not just signed policy.
### How are the three tiers assigned?
The DoH assigns tier during licensing review or onboarding. Size, PHI volume, and entity type drive the decision. Hospitals with 21+ beds and EMR vendors with scaled PHI flows default to Advanced; small clinics typically fall under Basic.
### Do I need an external auditor for v2.0?
Yes, for Transitional and Advanced tiers. The DoH publishes a list of authorised assessors. Basic-tier entities may be permitted a self-assessment route subject to DoH confirmation.
