ADHICS V2: what the Abu Dhabi healthcare standard actually requires.
ADHICS V2 took effect in August 2024 and applies to any entity in Abu Dhabi that handles health information, including payers and technology providers, not only hospitals. Eleven control domains, four control categories, and a Statement of Applicability you have to justify. We assess, remediate and evidence it.
- V2, Aug 2024Current effective version
- 11 domainsControl areas in the standard
- 4 categoriesIncluding Service Provider
- Vendors tooNot only healthcare facilities
Eight things ADHICS V2 asks of you, in the order they bite.
Know whether it applies to you, because the scope is wider than most assume
The standard applies to any entity that generates, accesses, stores, uses, processes or transmits health information in the Emirate of Abu Dhabi, and it names healthcare facilities, payers, and healthcare technology and service providers explicitly. That last group is the one that gets caught out. A software vendor, a hosting provider or an analytics firm serving an Abu Dhabi hospital is in scope on its own account, not merely through its client contract.
Four control categories, not three, and the fourth is the trap
Controls are grouped into four categories. Basic, Transitional and Advanced are cumulative: to reach Transitional you must satisfy all Basic and Transitional demands, and Advanced requires all three. The fourth category is Service Provider, and the standard states that all healthcare technology and services providers implement controls to that category. Guides that describe ADHICS V2 as a three-tier model have simply missed it.
A Statement of Applicability you can defend
The standard requires a Statement of Applicability naming the controls identified as necessary, the reasons for identifying them, the current status of implementation, and a justification for excluding any risk-based applicable control. That last item is where assessments fail. Excluding a control is allowed. Excluding it without a written, risk-based justification is the finding.
Asset classification against a defined scheme
Information assets are classified as Public, Restricted, Confidential or Secret, and you may use your own scheme provided it aligns with the standard criteria and you maintain the mapping. Most healthcare entities we assess have a classification policy and no classified assets, which is a policy rather than a control. The work is applying it to real systems and real data sets.
Access control, including the 24-hour revocation demand
Access to systems, applications, information, secure areas and identified critical areas must be revoked within 24 hours of exit or termination, and where a service provider is involved, the entity being served must be told to revoke access too. This is a specific, testable, dated requirement, and it is the one that most reliably produces a finding, because leaver processes in healthcare are usually built around clinical handover rather than around access.
Cloud and third party as their own control domains
ADHICS V2 gives Cloud Security and Third Party Security their own domains with their own policy requirements, rather than treating them as a subsection of something else. For an entity that has moved records, imaging or analytics to a cloud platform, or that shares data with partners across the Abu Dhabi healthcare ecosystem, these two domains typically carry the largest gap and the longest remediation.
Incident management and continuity, evidenced rather than documented
Information Security Incident Management and Information Systems Continuity Management are separate domains, each requiring a policy and demonstrable practice. The standard requires prompt notification to the Department of Health within defined timelines where an incident involves a third party. What an assessor looks for is evidence that the process has actually been exercised, not a plan that has never been tested.
Mapping to the wider UAE assurance framework
Controls throughout the standard carry UAE Information Assurance references, so ADHICS work does not sit in isolation from your other obligations. If you are already aligned to the national standard, or to ISO 27001, a substantial part of the evidence is reusable. We map what you have before proposing anything new, because duplicated control sets are the most common source of wasted compliance spend in UAE healthcare.
We read the standard. A lot of published guidance did not.
ADHICS V2 is a 137-page document and most of what circulates about it is secondhand. Two claims in particular are repeated confidently and are not what the Department of Health published.
- The "three-tier" claim. Several guides describe a three-tier control structure of Basic, Transitional and Advanced. The standard states that control requirements are grouped into four categories, and the fourth is Service Provider, which all healthcare technology and services providers are required to implement against. If you are a vendor and you planned your programme around three tiers, you planned against the wrong category.
- The "24-hour breach notification" claim. This one matters because it drives incident response design. The 24-hour figure that appears in the standard concerns access revocation, requiring access to be revoked within 24 hours of exit or termination. On security incidents the standard requires prompt notification to the Department of Health within defined timelines. Building an incident plan around an invented 24-hour breach clock is not compliance, it is guessing.
- What did genuinely change. ADHICS V2 supersedes the earlier ADHICS V0.9 of 2019 together with the separate Internet of Medical Things security standard and the patient healthcare data privacy standard, folding three documents into one. If your compliance file still references those three separately, it is describing a regime that no longer exists.
- Where to check. The standard is published by the Department of Health and carries reference DOH/SD/ICSO/ADHICS/V2/2024, publication May 2024, effective August 2024, with a stated revision date of May 2027. Any advice you receive, including ours, should be traceable to a clause in that document. Ask for the clause.
Four commitments on a standard that attracts a lot of loose advice.
Every recommendation cites a clause
If we tell you the standard requires something, we will point you at where it says so, by domain and control reference. That is how we found that the widely repeated three-tier and 24-hour breach notification claims do not match the published text. Ask any adviser, including us, to show you the clause. It is a fast way to tell who has read the document.
We size the control category before designing anything
Because Basic, Transitional and Advanced are cumulative and Service Provider is separate, the first question is which category you are actually working to and why. Getting this wrong in either direction is expensive: aim too high and you build controls the standard does not ask of you, aim too low and the assessment finds it.
We reuse the evidence you already have
The standard carries UAE Information Assurance references throughout, and healthcare entities frequently hold ISO 27001 certification or national standard alignment already. We map existing controls and evidence against ADHICS first, so the remediation plan covers the genuine gap rather than rebuilding a control set you have already paid for once.
We support the estate, not just the paperwork
A compliance report that hands you fifty findings and leaves is not much use to a clinic with two IT staff. We remediate as well as assess, and where you want it we run the ongoing controls: access reviews, logging, backup verification, third-party oversight. Priority response applies, P1 within 5 minutes, P2 within 10, P3 within 30.
Six entity types the standard reaches, including three that assume it does not.
A hospital or multi-site healthcare group
The full standard, usually at a higher control category, across a large estate with clinical systems, imaging, medical devices, research data and multiple third-party integrations. The hard parts here are rarely the policies. They are asset inventory including medical devices, access control across shift-based clinical staff, and evidencing that continuity plans work against clinical recovery objectives rather than IT ones.
A clinic, day surgery or dental practice
Smaller scope, the same standard, and usually one or two people carrying IT alongside another job. The realistic path here is the Basic category done properly rather than an aspirational programme that stalls. The findings we see most are shared clinical logins, a leaver process that never touches system access, and a practice management system nobody has patched.
A payer or insurance company
Named explicitly in the scope. Payers hold claims data that is health information by any reading, frequently at large volume, and often across systems that were built for finance rather than for clinical confidentiality. Classification and third-party security are usually the weakest domains, because claims data moves between more organisations than most people realise.
A healthtech vendor or software provider
This is the group most likely to be surprised. The standard applies to healthcare technology and service providers directly, and it assigns them their own Service Provider control category. If you sell software to an Abu Dhabi hospital, your obligation is not simply whatever your client contract says. Increasingly your clients will also ask you to evidence it before they will sign.
A hosting, cloud or analytics provider serving healthcare
If health information passes through your infrastructure you are in scope, and the Cloud Security domain applies on both sides of the relationship. We see this most with regional providers who host clinical systems and have never been asked the question, and who then face it during a client audit with no evidence prepared and a live contract at stake.
A diagnostic lab, imaging centre or telehealth service
High volumes of clinical data, significant medical device estates, and heavy integration with other providers and the wider Abu Dhabi ecosystem. Because ADHICS V2 absorbed the separate Internet of Medical Things standard, connected devices are squarely in scope here, and they are almost always missing from the asset inventory when we first look.
Where Abu Dhabi healthcare entities actually stand on ADHICS V2.
| Feature | Implemented and evidenced | Documented only | Not started or on V0.9 |
|---|---|---|---|
Scope and control category formally decided | Assumed | ||
Statement of Applicability with justified exclusions | Partial | ||
Policies covering all eleven domains | |||
Leaver access revoked inside 24 hours, evidenced | |||
Medical devices in the asset inventory | Sometimes | ||
Cloud and third party treated as their own domains | Merged into IT policy | ||
Incident process exercised, not just written | |||
Restore tested against a clinical recovery objective | |||
Evidence producible on request | In days | In weeks | No |
Compliance file references the current V2 standard | Usually |
What each domain covers, and where we usually find the gap.
| Domain | Where the gap usually is | |
|---|---|---|
| HR, Human Resources Security | Background verification and joiner, mover, leaver | Leaver access not revoked inside 24 hours |
| AM, Asset Management | Inventory, ownership, classification, portable devices | Medical devices absent from the asset register |
| PE, Physical and Environmental Security | Secure areas, clear desk, equipment siting | Server rooms in clinics with shared access |
| AC, Access Control | Identity, privilege, review, remote access | Shared clinical logins that destroy attribution |
| CO, Communication and Operation Management | The largest domain: operations, logging, backup, malware | Logging enabled but never reviewed |
| DP, Privacy and Protection Practices | Health information privacy and data protection | Consent and retention undefined for research data |
| CS, Cloud Security | Its own domain and its own policy | Cloud adopted before the policy existed |
| TP, Third Party Security | Agreements, oversight, incident notification | No security schedule in vendor contracts |
| SA, Systems Acquisition, Development and Maintenance | Secure development, change, testing | Clinical applications changed without change control |
| IM, Information Security Incident Management | Detection, response, DoH notification | A plan that has never been exercised |
| SC, Information Systems Continuity Management | Continuity, recovery, backup assurance | Restores never tested against clinical RTO |
Five stages, from scope to evidence.
- 1
Confirm scope and control category
Whether the standard applies to you, on what basis, and which of the four control categories governs your obligations. For a healthcare technology or service provider this stage frequently changes the shape of the whole programme, because the Service Provider category is not what most vendors have been planning against.
- 2
Assess against the eleven domains
A control-by-control review producing findings mapped to domain and control reference, with severity and the evidence we did or did not find. We also map what you already hold from ISO 27001 or national standard work, so the gap list is genuinely the gap rather than a restatement of the whole standard.
- 3
Build the Statement of Applicability properly
Controls identified as necessary, the reasoning, current implementation status, and a defensible justification for every risk-based applicable control you exclude. This document is named in the standard and it is the first thing an assessor reads, so it is worth writing rather than generating.
- 4
Remediate in priority order
We start with the specific, testable, dated demands, access revocation inside 24 hours being the clearest, then the domains carrying the largest gap, which for most entities are Cloud Security, Third Party Security and asset inventory including medical devices. You get a plan with owners and dates, not a list of findings.
- 5
Produce evidence and keep it current
An evidence pack an assessor can work through: policies, records, review logs, test results, exercise reports. Then the ongoing work that keeps it true, because compliance decays. Access reviews, logging review, restore testing, third-party oversight and a fixed annual re-assessment before the standard next revises in May 2027.
“Our previous adviser had built the whole programme around three control tiers and we are a software provider, so the category that actually applied to us was the one nobody had mentioned. Finding that out during a client audit would have cost us the contract. Finding it out in a gap assessment cost us a few weeks.”
What Abu Dhabi healthcare entities ask about ADHICS.
Fifteen checks before an assessment.
Establish what applies
- Do you generate, access, store, use, process or transmit health information in Abu Dhabi?That phrasing is the scope test, and it is deliberately broad.
- Are you a healthcare technology or service provider rather than a facility?Then the Service Provider control category applies to you.
- Which control category are you working to, and who decided?Basic, Transitional and Advanced are cumulative, not alternatives.
- Does your compliance file still reference the 2019 standard or the separate IoMT and privacy standards?V2 superseded all three.
- Do you connect to Shafafiya, a health information exchange, or a partner EMR?The standard names these ecosystem connections in scope.
The documents the standard names
- Do you have a Statement of Applicability?Explicitly required, not optional.
- Does it justify every excluded risk-based applicable control?The most common documentation finding we see.
- Is there a documented information security risk management process?It underpins the whole Statement of Applicability.
- Do you have a policy for each of the eleven domains?Including Cloud Security and Third Party Security as their own.
- Is your asset classification scheme mapped to Public, Restricted, Confidential, Secret?Your own scheme is allowed if the mapping is maintained.
The evidence that decides it
- Can you show access revoked within 24 hours for your last ten leavers?Specific, dated and testable. Start here.
- Are medical devices in the asset inventory?V2 absorbed the separate IoMT standard, so they are in scope.
- Has the incident response process actually been exercised?An untested plan evidences intent, not capability.
- Have you tested a restore against a clinical recovery objective?Backup success reports are not restore evidence.
- Do your third-party agreements carry security and notification obligations?Required by the TP domain, and usually absent.
The pages around this one.
IT audit services in Dubai
The wider audit practice: what an IT audit actually examines, how findings are evidenced, and how a regulator-facing assessment differs from an internal review.
UAE PDPL compliance
The federal personal data protection obligations that sit alongside sector standards, and how the two interact for entities holding health information.
NESA compliance in Dubai
The national information assurance standard, which ADHICS references throughout, and how alignment to one reduces the work required for the other.
Two questions decide the shape of your ADHICS programme.
Are you a facility or a service provider, and which control category are you working to. We will answer both in a first conversation at no cost, and tell you honestly whether what you already hold from ISO 27001 or national standard work covers most of it.
Related Services
Explore more solutions that work great with this service
NIST CSF 2.0 Assessment
Know where you stand, without committing to certification
Virtual CISO Dubai
Security governance and accountability, not more tools
ISO 27001 Certification UAE
The 2022 edition, and whether you should certify at all
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
UAE PDPL Compliance
Federal Decree-Law 45 of 2021 readiness and operations
NESA / IA Compliance
UAE Information Assurance Standards compliance
Cybersecurity Audit
Security assessment and compliance audit
Healthcare IT
DHA-aware IT for Dubai clinics, hospitals, and DHCC providers