ADHICS Penetration Testing for Abu Dhabi Healthcare
Healthcare is the sector where a security assessment has to be designed around the constraint that you cannot take the system down. ADHICS sets the control expectations for Abu Dhabi providers and their suppliers; testing against it is as much about how you test as what you find.
What ADHICS covers
The Abu Dhabi Healthcare Information and Cyber Security standard sets the control expectations for healthcare entities operating under the emirate's Department of Health, and for the technology suppliers who serve them. It spans governance, access control, asset management, incident response and the protection of clinical and patient data, with security assessment and evidence requirements running through it.
The scope reaches further than hospitals. Electronic medical record vendors, telehealth platforms, laboratory and imaging systems, claims and insurance processors, and the integrators wiring them together all end up in scope - usually through a provider's contractual requirement rather than a direct relationship with the regulator. If your software touches Abu Dhabi patient data, the obligation finds you through procurement.
Testing healthcare without disrupting care
Every other compliance page can treat scoping as a commercial question. Here it is a clinical safety question, and it is settled before anything else.
The operating assumption is that nothing in a clinical environment is safe to break:
- No denial-of-service testing, and no automated exploitation against clinical systems. Ever.
- No aggressive scanning of medical devices, patient monitoring, or anything connected to them - connected devices fail unpredictably under scanning in ways that general IT equipment does not.
- Testing windows agreed around clinical load, with a named clinical contact reachable throughout and an immediate abort path that does not require a meeting to invoke.
- Staging replicas where live testing is inappropriate, with the gap between staging and production documented honestly rather than papered over.
All of this goes into written, signed rules of engagement before testing begins. Where a system genuinely cannot be tested safely in any form, the right answer is a configuration and architecture review plus a documented justification - not an aggressive test performed carefully and hoped for the best.
Where the real risk sits
Clinical environments share a set of characteristics that shape what a useful test looks for:
- Flat networks. Clinical estates grow by addition, and the segmentation between administrative, clinical and device networks is frequently thinner than the architecture diagram suggests. Establishing what is actually reachable from a general workstation is usually the single highest-value finding in a healthcare engagement.
- Unpatchable devices. Connected medical equipment running unsupported operating systems that cannot be updated without revalidation. These are not going to be fixed, so the finding that matters is not the missing patch - it is whether the device is isolated from everything that could reach it.
- Integrations. Healthcare runs on interfaces between systems - HL7 and FHIR feeds, lab and imaging connections, insurance and claims links. The authentication and authorisation on those interfaces is routinely weaker than on the user-facing applications, because they were built between trusted parties on a trusted network, and that assumption stopped being true some time ago.
- Identity sprawl. Shared clinical logins, long-lived accounts for departed staff, vendor remote-access accounts with standing privilege. In Active Directory terms this is fertile ground, and it is how a single compromised workstation becomes an estate-wide problem.
- Remote vendor access. Suppliers with permanent access into clinical systems for support purposes. A compromise of any one of them is a compromise of you, which is exactly why providers now push testing requirements down their supply chain.
Scope of the engagement
Typically: external network testing across the internet-facing estate including patient portals and remote-access infrastructure; web application and API testing against portals, booking systems, telehealth platforms and the integration interfaces behind them; internal network testing focused on segmentation and reachability rather than exploitation; Active Directory review covering privilege, stale accounts and vendor access; and cloud assessment where clinical or patient data sits in a cloud tenancy.
For suppliers rather than providers, the scope usually narrows to the platform itself plus its integration surface - which is what the provider's procurement team is actually asking about.
Stacking with NESA and PDPL
ADHICS rarely applies alone. Healthcare is designated critical information infrastructure, so NESA's Information Assurance Standards commonly apply alongside it - including the 90-day retest expectation for critical and high findings and the review of the tester's credentials. The federal PDPL adds data protection obligations wherever personal data is processed, which in a healthcare context is everywhere.
Scoped against all three at the start, one engagement produces one body of testing and three mapped sets of evidence. Scoped against one and retrofitted afterwards, it usually means testing again - so tell me every regime you're subject to in the first conversation.
The deliverable
An executive summary written for a clinical governance audience as well as a technical one, a technical body with reproduction steps and CVSS ratings, and mapping to the ADHICS controls each finding bears on - plus NESA and PDPL where they apply. Findings are prioritised by clinical impact rather than CVSS alone, because a medium-severity issue on a system that affects patient care outranks a high-severity one on a marketing site, and a report that doesn't make that distinction isn't useful to a hospital.
Then remediation support, a retest, and an attestation letter - which for suppliers is frequently the document that unblocks procurement. A sample report shows the format.
Practicalities
Remote from Amman, one hour behind Abu Dhabi, same working week, Arabic or English. Internal testing runs over a VPN or a jump host inside your environment, within the agreed windows. Credentials - asked for by both NESA assessors and hospital procurement - are OSCP+, eCPPT, eWPT, eCIR, AZ-500, SC-200 and SC-300, all verifiable through the OffSec credential wallet.
Next steps
Tell me whether you're a provider or a supplier, what the environment includes, and whether any of it is clinically live. The first conversation is about what can be tested safely and what needs a different approach - that is settled before any quote, because it determines the scope. Get in touch - Arabic welcome.
Related: penetration testing in the UAE, NESA requirements, and the compliance overview.
ADHICS questions
Healthcare providers operating in Abu Dhabi under the Department of Health, and the technology suppliers serving them - which pulls in a wide range of companies that aren't themselves clinical: electronic medical record vendors, telehealth platforms, laboratory and imaging systems, insurance and claims processors, and the integrators connecting them. If you handle Abu Dhabi patient data or plug into a provider's environment, you are usually in scope through your customer's obligation even when you have no direct relationship with the regulator.
Yes, and it is the first thing to agree. The approach is to assume nothing is safe to break: no denial-of-service testing, no automated exploitation against clinical systems, no aggressive scanning of medical devices or anything connected to patient monitoring, and testing windows agreed around clinical load. Where a system is too sensitive to test live, the alternatives are a staging replica, a configuration and architecture review, or carefully bounded manual testing with a named clinical contact and an immediate abort path. The rules of engagement are written and signed before anything starts.
They need to be identified and treated as fragile by default. Connected medical devices frequently run unsupported operating systems that cannot be patched, fail unpredictably under scanning, and sit on networks flatter than anyone expects. The valuable work there is usually reachability rather than exploitation: establishing which devices are reachable from where, whether they are segmented from the general network, and what an attacker who reached that segment could do. That answers the real risk question without ever touching a device that is attached to a patient.
They stack. ADHICS is the sector standard for Abu Dhabi healthcare; healthcare is designated critical information infrastructure, so NESA's Information Assurance Standards commonly apply alongside it; and the federal PDPL brings data protection obligations wherever personal data is processed, which in healthcare means all of it. A single engagement scoped against all three at the outset produces one set of testing and three sets of mapped evidence.
Increasingly yes, and the demand usually arrives through procurement rather than from the regulator. Providers under ADHICS are responsible for the security of their supply chain, so they push the requirement outward - which means an independent penetration test report is becoming a condition of winning or keeping the contract. For a supplier, having a current report and attestation ready shortens procurement considerably, and not having one has started to lose deals.
Healthcare provider or supplier in Abu Dhabi?
Testing scoped around clinical safety, with the evidence ADHICS and your customers ask for.