Lenouar
EducationSep 4, 202610 min read

ADHICS v2 and AI: what Abu Dhabi healthcare providers must control

ADHICS does not need an AI clause to govern your AI. Where deployments actually fail assessment, and why the 24-hour notification window is the real test.

ADHICS v2 and AI: what Abu Dhabi healthcare providers must control

Key takeaways

  • ADHICS v2 took effect in August 2024, replacing the 2019 standard, and applies to every Abu Dhabi entity that creates, processes, stores or transmits patient data, including IT vendors handling PHI on a provider's behalf.
  • It uses a three-tier control model (Basic, Transitional, Advanced) and shortens the incident notification window to 24 hours.
  • ADHICS does not need an AI clause to govern your AI. An AI system is an information asset processing health information, so the existing control families attach to it directly.
  • The controls AI deployments most often fail are asset inventory, third-party management, access control, logging and secure development, not anything model-specific.
  • Published summaries of ADHICS v2 disagree on the number and naming of control domains. Work from the DoH control catalogue, not from a blog post, including this one.

ADHICS v2 took effect in August 2024, replacing the 2019 standard with a capability-based model, three compliance tiers scaled to entity size, and a 24-hour incident notification window.

The Abu Dhabi Healthcare Information and Cyber Security Standard is issued by the Department of Health and binds every healthcare facility, payer and service provider in the Emirate that touches patient data. Version 2 is not a light refresh of version 1.

Two changes matter most operationally. The first is tiering: obligations now scale with entity type, so a single-site clinic and a tertiary hospital are held to different depths of control rather than the same flat list.

The second is the clock. Incident notification tightened to 24 hours. That single number reshapes what your detection and escalation capability has to look like, and it is where AI deployments tend to be weakest.

Compliance evidence and control mapping on screen in a hospital operations room
Controls scale with entity tier under ADHICS v2
Aug 2024
ADHICS v2.0 effective date, superseding the 2019 standard Department of Health, Abu Dhabi
24 hours
Incident notification window to the Department of Health under v2 Department of Health, Abu Dhabi

Does ADHICS actually cover AI?

Yes, but not through a single AI clause. ADHICS governs the security of health information, and an AI system that reads or produces health information is an information asset inside that scope, so the existing control families apply to it in full.

Teams often go looking for the AI section, and the search itself is the mistake. The relevant question is not whether the standard names your technology. It is whether your technology processes health information, and if it does, the controls attach.

Version 2 does extend further into cloud, connected medical devices and emerging technology than version 1 did. That expansion is real and worth reading closely.

One honest caution. Published third-party summaries of ADHICS v2, including several written by security vendors, disagree with each other on how many control domains exist and what they are called. We have seen counts of both eleven and twelve, with different naming in each.

So do not cite a control reference you took from a summary. Pull the current control catalogue from the Department of Health and map against that. This is the sort of detail an assessor will check, and getting it from a blog is how organisations end up confidently referencing a control that does not exist.

If a vendor quotes you exact ADHICS domain numbers without pointing at the DoH catalogue, ask where the numbering came from. It is a fast way to find out how carefully they actually read the standard.

Where AI deployments break ADHICS expectations

AI systems rarely fail ADHICS on anything model-specific. They fail on asset inventory, third-party management, access control, logging and secure development, because those controls assume a system boundary that a typical AI pilot never had.

The pattern repeats across the healthcare deployments we have worked on. The clinical logic gets scrutinised carefully. The infrastructure around it was stood up during a pilot and never re-entered the governance process.

Here is where the gaps actually appear.

  • Asset inventory: the model, vector store, prompt logs and review queue are never registered as information assets, so nothing else in the control framework can attach to them
  • Third-party and supplier management: an inference API is a processor handling PHI, but it was signed up with a corporate card and never went through vendor assessment
  • Access control: retrieval systems commonly flatten permissions, so a clinician can surface content from records they had no right to open
  • Logging and monitoring: prompt and response logs either capture everything with no retention limit, or capture nothing usable for an investigation
  • Secure development: prompt changes and model version upgrades ship without change control, so nobody can say which version produced a given output
  • Encryption: embeddings and cached responses sit outside the encryption-at-rest scope defined for the primary clinical systems
Permission sprawl that accumulated over years is now discoverable in seconds through plain-language prompts.
Amy Babinchak, Petri IT Knowledgebase, July 2026

Permission flattening in retrieval is the one to check first. It is the most common and the most serious, because it converts an access control failure into a silent one.

The 24-hour clock is the real test

A 24-hour notification window means you must be able to detect, scope and characterise an incident inside a day, and most AI deployments cannot answer basic questions about what a system disclosed in that timeframe.

Run the exercise. Suppose you learn that a retrieval system has been surfacing records outside a user's authorisation for three weeks. Within 24 hours you need to say who was affected, what was disclosed, and over what period.

Answering that requires per-query logging tied to an authenticated identity, retention long enough to cover the window, and retrieval scope recorded alongside each response. Most pilots have none of the three.

This is why logging is not a nice-to-have you add after go-live. It is the control that determines whether you can meet the notification obligation at all.

  • Log the authenticated user, not just a service account, for every query
  • Record which documents were retrieved and which were passed into context
  • Keep the model and prompt version alongside each response
  • Set retention deliberately, long enough to investigate and short enough to defend
  • Rehearse the reconstruction before you need it, because the first attempt is always slower than expected

Tiering, and why it does not let you off

The Basic, Transitional and Advanced tiers scale control depth to entity size, but the tier is set by the organisation, not by the system, so a small clinic deploying AI is still assessed at its own tier across all of its assets.

There is a hopeful reading of tiering where a modest deployment attracts modest obligations. That is not how it works. Your tier reflects what kind of entity you are, and every information asset you operate sits inside it.

For entities at the Advanced tier, expect privileged access management, monitored logging, secure development lifecycle and encryption of health information at rest and in transit to apply to the AI estate on the same terms as to clinical systems.

For smaller entities the depth is lower, but the direction of travel is the same, and the tier can move as the organisation grows. Building to the tier above your current one is usually cheaper than retrofitting later.

A working checklist before assessment

Before an ADHICS assessment, register the AI components as information assets, run the vendor through third-party assessment, prove permission-aware retrieval, and demonstrate that you can reconstruct an incident within 24 hours.

None of this is exotic. It is the ordinary control framework applied to a system that was allowed to skip it, which is why the remediation is usually faster than teams fear.

  • Register every AI component in the asset inventory with a named owner and classification
  • Put the inference provider and any hosting vendor through third-party security assessment
  • Demonstrate that retrieval respects source-system permissions, with a test case that proves it
  • Show per-query logs tied to authenticated identity, with a defined retention period
  • Bring prompt and model changes under change control, with version recorded on every output
  • Confirm encryption at rest covers vector stores, caches and log storage, not only the primary database
  • Run one incident reconstruction drill and time it against the 24-hour obligation

Map each item to the current DoH control catalogue rather than to a summary. The mapping is what an assessor reviews, and it needs to reference real control identifiers.

Frequently asked questions

Does ADHICS v2 apply to AI systems used in healthcare?
Yes. ADHICS governs the security of health information rather than specific technologies, so an AI system that creates, processes, stores or transmits patient data falls within scope as an information asset. The standard's control families for asset management, access control, third-party security, logging and secure development apply to it directly.
When did ADHICS v2 come into effect?
ADHICS v2.0 took effect in August 2024, replacing the 2019 version of the standard. It applies across the Emirate of Abu Dhabi to healthcare facilities, payers, and service providers handling patient data, including IT vendors processing PHI on a regulated entity's behalf.
What is the ADHICS breach notification timeframe?
Version 2 requires notification to the Department of Health within 24 hours, shortened from the longer window in the previous version. For AI deployments this is demanding, because scoping a disclosure inside a day requires per-query logging tied to authenticated identity and retained long enough to investigate.
How many control domains does ADHICS v2 have?
Published third-party summaries disagree, with some listing eleven domains and others twelve, using different names. Because control references are checked during assessment, take the domain structure and control identifiers from the current Department of Health control catalogue rather than from secondary summaries.
Does a small clinic deploying AI face lighter ADHICS obligations?
Control depth scales through the Basic, Transitional and Advanced tiers, but the tier is determined by the type and size of the entity, not by the individual system. A smaller entity has a lower required depth across all of its assets, including AI, and that depth increases if the organisation grows into a higher tier.

Sources

  1. 1.Abu Dhabi Healthcare Information and Cyber Security Standard (ADHICS) v2Department of Health, Abu Dhabi
  2. 2.Guidelines for the implementation of ADHICS v2Department of Health, Abu Dhabi
  3. 3.ADHICS v2.0 compliance guideEnactia
  4. 4.ADHICS compliance: beyond checklists to continuous protectionCrowe UAE
  5. 5.Federal Decree-Law No. 45 of 2021 on the Protection of Personal DataUAE Legislation
  6. 6.Copilot didn't overshare your data, your permissions did (7 July 2026)Amy Babinchak, Petri IT Knowledgebase

Read more

Bring AI inside your walls.

Talk to us about a private, compliance-ready deployment for your organization.

Book a consultationExplore the platform