ADHICS v2.0 is the Abu Dhabi Healthcare Information and Cyber Security Standard issued by the Department of Health (DoH), and it applies to every healthcare facility, payer, and service provider that handles patient data in the Emirate of Abu Dhabi. Version 2.0 took effect in August 2024 and replaces the 2019 standard with a capability-based model, a three-tier control structure (Basic, Transitional, Advanced), eleven control domains, and a 24-hour breach notification window. This guide walks compliance leaders, hospital CISOs, and clinic operations managers through what the standard now requires, who must comply at which tier, and how to build an implementation roadmap that survives the DoH’s new capability-based audit.

## Who must comply with ADHICS v2.0

ADHICS applies to any entity in Abu Dhabi that creates, processes, stores, or transmits protected health information (PHI). In practice, the DoH defines this scope broadly:

– Hospitals (public and private) of all sizes
– Clinics, polyclinics, day-surgery centres, and specialty centres
– Diagnostic and imaging centres, laboratories, and pathology providers
– Pharmacies (retail and hospital)
– Rehabilitation, dialysis, fertility, and long-term care centres
– Home healthcare and mobile medical units
– Health insurers and Third-Party Administrators (TPAs) processing claims and PHI
– Healthcare IT vendors, EMR/EHR suppliers, telemedicine platforms, and managed-service providers who handle health data on behalf of a regulated entity

The standard explicitly reaches contractors and cloud vendors through ADHICS’s Third-Party Risk domain — if your supplier processes PHI in connection with a DoH-licensed entity, the licensed entity is accountable for the supplier’s compliance.

## The six pillars of ADHICS v2.0

One of the structural differences between v1.0 and v2.0 is that v2.0 reorganises the standard around six “capability pillars” rather than presenting controls as a flat catalogue. Auditors now evaluate each pillar’s operating capability, not just whether documents exist.

1. Governance — board-level accountability, security strategy, an appointed Information Security Manager (ISM), policy programme, and metrics reporting.
2. Resilience — incident response, business continuity, disaster recovery, backup, and crisis communications, with tested recovery time objectives (RTOs) for clinical systems.
3. Capabilities — the technical control set: access management, cryptography, vulnerability management, secure development, logging and monitoring, network segmentation.
4. Partnerships — third-party and supply-chain risk: due diligence, contract clauses, vendor compliance validation, cross-border data transfer controls, cloud sovereignty.
5. Maturity — the tiered maturity model (Basic → Transitional → Advanced) and continuous improvement evidence.
6. Innovation — controls specific to emerging technologies: AI governance, Internet of Medical Things (IoMT) device security, and cloud-native healthcare workloads.

The Innovation pillar is the most-changed part of the standard. v1.0 had no dedicated treatment of AI, IoMT, or cloud — v2.0 explicitly addresses all three.

## The 11 control domains

Underneath the six pillars sit eleven control domains. Each domain has its own catalogue of controls scored against the maturity tier you fall into.

| # | Domain | What it covers |
|—|—|—|
| 1 | Information Security Governance | ISM appointment, security committee, policy framework, risk acceptance authority |
| 2 | Risk Management | Risk register, treatment plans, residual-risk reporting (see our ADHICS risk assessment worked example) |
| 3 | Asset Management | Inventory, classification (4 categories), labelling, secure disposal |
| 4 | Human Resources Security | Background verification, security training, leaver controls |
| 5 | Physical & Environmental Security | Facility access, secure areas, equipment protection, off-site media handling |
| 6 | Communications & Operations | Network segmentation, malware protection, logging, backup, capacity management |
| 7 | Access Control | Unique IDs, RBAC, MFA for critical systems, privileged-access management |
| 8 | Information Systems Acquisition, Development & Maintenance | Secure SDLC, change management, vulnerability management, encryption |
| 9 | Third-Party Security | Supplier due diligence, contracts, compliance evidence, cloud and cross-border data transfers |
| 10 | Incident Management | Detection, response, 24-hour DoH notification, lessons-learned |
| 11 | Information Systems Continuity Management | BCP, DR, tested recovery, communications |

Two domain areas added to or significantly expanded in v2.0 are AI governance and IoMT security (embedded within domains 6 and 8) and cloud and cross-border data transfer controls (within domain 9). For a side-by-side of every change versus v1.0, see “what changed in ADHICS v2.0”.

## The three control tiers: Basic, Transitional, Advanced

v2.0 abandons the v1.0 “one-size-fits-all” approach and assigns each entity to one of three tiers based on size, complexity, and risk profile.

| Tier | Typical entity | Indicative control depth |
|—|—|—|
| Basic | Small clinics, single-site pharmacies, low-volume diagnostic centres | Foundational controls: documented policies, access control, backup, incident reporting, vendor list |
| Transitional | Mid-size polyclinics, multi-site clinics, medium-volume insurers, healthcare IT vendors | Basic + risk register, BC/DR plan, MFA on critical systems, vulnerability management programme, training programme |
| Advanced | Hospitals (typically 21+ beds), tertiary care, large insurers, large EMR vendors, telemedicine platforms with scaled PHI flows | Transitional + privileged-access management, SOC/SIEM monitoring, secure SDLC, encryption-at-rest and in-transit for PHI, third-party assurance programme, AI governance and IoMT controls |

Tier assignment is determined by the DoH during onboarding or licensing review. Hospitals with 21 or more beds default to Advanced. Healthcare IT vendors that process PHI at scale typically also fall into Advanced regardless of headcount.

## Capability-based auditing: why v2.0 audits feel different

v1.0 audits were predominantly documentation-driven: produce a policy, show it is approved, prove it is communicated. v2.0 audits assess capability — whether the control operates effectively in practice. Practically, this means:

– Evidence is operational, not documentary. Auditors ask for logs, ticket trails, training completion records, BCP test reports, vendor review minutes — not just signed policies.
– Interviews replace document walkthroughs. Expect auditors to test understanding with frontline clinicians and IT staff, not only the ISM.
– Maturity is scored. Each domain receives a maturity rating against the assigned tier; you must show measurable improvement year-on-year.
– Findings have remediation SLAs. Critical findings (e.g. unencrypted PHI in transit) carry short remediation windows enforced by re-audit.

## The new 24-hour breach notification rule

Among the most operationally significant v2.0 changes: the breach notification window to the DoH is now 24 hours (reduced from 72 hours in v1.0), with a 4-hour initial containment expectation for high-severity incidents. Your incident response plan, on-call rota, and DoH communications template must be ready to operate inside that window — including weekends and public holidays.

Practically, this means three things must be in place before you can credibly claim compliance:

1. A 24/7 detection capability (in-house SOC or managed SOC) that can identify a high-severity event within hours, not days.
2. A documented and rehearsed escalation path with named decision-makers and out-of-hours contact details.
3. A pre-approved DoH notification template (and a published escalation contact at the DoH side).

## Implementation phases: a 12-month roadmap

Most Abu Dhabi healthcare entities that missed the original Q4-2025 deadline are now in remediation mode. A realistic 12-month roadmap (compressed to 6 months for Basic-tier entities) looks like this:

### Months 1–2: Scoping & gap assessment

– Confirm tier assignment with the DoH
– Inventory PHI flows, systems, vendors, and physical sites
– Map current controls to the eleven ADHICS domains; rate each as Compliant / Partial / Gap
– Output: a tier-scoped gap register with a named owner per gap

### Months 3–4: Policy & governance build

– Appoint the ISM in writing; convene the security committee
– Refresh or write the 15+ mandatory policies (acceptable use, access control, incident response, change management, vendor management, data classification, cryptography, BCP/DR, secure development, mobile devices, removable media, physical security, supplier security, monitoring and logging, AI use)
– Approve a risk acceptance matrix at board level

### Months 5–8: Technical & operational controls

– Stand up identity controls (unique IDs, RBAC, MFA on Advanced-tier critical systems)
– Implement encryption-at-rest and in-transit for PHI
– Roll out vulnerability management cadence (monthly scanning, quarterly remediation review)
– Segment clinical networks from corporate and IoT/IoMT networks
– Deploy or contract SIEM/SOC monitoring

### Months 9–10: Third-party & resilience

– Vendor due-diligence programme: collect ADHICS or equivalent attestations from in-scope suppliers
– Update contract clauses for breach notification, audit rights, sub-processors, and cross-border transfers
– Test the BC and DR plan with a tabletop and (for Advanced) at least one technical failover exercise

### Months 11–12: Audit-readiness & submission

– Internal audit of all eleven domains against the tier baseline
– Close remaining gaps; produce the evidence packs auditors will sample
– Submit the Self-Assessment Statement to the DoH (Aamen portal) and engage the external auditor

## Five common pitfalls (and how to avoid them)

1. Treating v2.0 as a v1.0 refresh. The capability-based audit model is genuinely new — copy-pasting your v1.0 policy pack will fail.
2. Ignoring IoMT. Infusion pumps, patient monitors, and imaging modalities are in scope. They rarely have endpoint protection or patchable operating systems. Network segmentation is the practical control.
3. Cloud-sovereignty over-correction. v2.0 requires UAE data residency for PHI but does not ban use of AWS or Azure — both run regions in the UAE that are eligible. The risk is contractual (sub-processors and cross-border replication), not technological.
4. Under-resourcing the 24-hour breach process. If your incident response is a daytime function, you cannot meet the SLA. This usually requires SOC outsourcing for non-Advanced tiers.
5. No cross-mapping with existing frameworks. If you already operate ISO 27001, NIST CSF, or HITRUST, you should be reusing 60–80% of your control evidence.

## How Enactia helps with ADHICS v2.0

Enactia’s cross-mapping engine lets a single set of controls, risks, vendors, and policies satisfy ADHICS v2.0 alongside ISO 27001, HIPAA, NIST CSF, GDPR, and the EU AI Act. For Advanced-tier hospitals already running ISO 27001 or HITRUST, that typically removes 60–80% of duplicate evidence work. The platform ships with an ADHICS v2.0 control catalogue mapped to the eleven domains and the three tiers, a healthcare-specific risk register template, the 15+ mandatory policy templates, and an incident workflow that meets the 24-hour DoH notification window. Book a 30-minute walk-through to see your control inventory mapped to ADHICS in real time.

## Frequently asked questions

### What is ADHICS v2.0?
ADHICS v2.0 is the second version of the Abu Dhabi Healthcare Information and Cyber Security Standard, issued by the Department of Health and effective from August 2024. It applies to all entities handling patient data in Abu Dhabi and uses six capability pillars, eleven control domains, and a three-tier maturity model (Basic, Transitional, Advanced).

### Who has to comply with ADHICS?
Every DoH-licensed healthcare entity in Abu Dhabi, plus the healthcare IT vendors, cloud providers, and TPAs that process PHI on their behalf. Hospitals, clinics, pharmacies, diagnostic centres, insurers, and home-care providers are all in scope.

### What changed between ADHICS v1.0 and v2.0?
v2.0 introduces the three-tier control structure, the capability-based audit model, a 24-hour breach notification window (down from 72 hours), explicit AI governance and IoMT controls, cloud and cross-border data transfer requirements, and over 15 mandatory policies.

### What tier does my organisation fall into?
Small clinics, single-site pharmacies, and low-volume diagnostic centres typically fall under Basic. Mid-size polyclinics, multi-site clinics, medium insurers, and healthcare IT vendors typically fall under Transitional. Hospitals with 21 or more beds, tertiary care providers, large insurers, and EMR vendors processing PHI at scale default to Advanced. The DoH confirms tier assignment during licensing or onboarding review.

### Can I store ADHICS-regulated data in AWS or Azure?
Yes, provided the data resides in a UAE region of the cloud provider and your contract restricts cross-border replication, sub-processing, and access in line with the DoH’s data sovereignty requirements. The control risk is contractual rather than technological — UAE regions of AWS and Azure are both eligible for PHI workloads when configured correctly.

### How long does ADHICS v2.0 implementation take?
For an Advanced-tier hospital starting with no prior framework, plan on 12 months. Organisations already operating ISO 27001 or HITRUST can usually compress to 6–9 months by reusing cross-mapped evidence. Basic-tier clinics can typically reach audit readiness in 4–6 months.