Security Testing for UAE Healthcare

A UAE hospital or clinic is expected to run independent security testing aligned with the Abu Dhabi Healthcare Information and Cyber Security Standard (ADHICS) and the expectations of its healthcare regulator, with findings mapped to the UAE Information Assurance Standards (IAS). We map every engagement to those references. We do not claim a certificate on your behalf.

ADHICS

The Abu Dhabi Healthcare Information and Cyber Security Standard sets controls for the systems that hold patient data and run clinical care. An engagement gives you the scope rationale, the findings with owners and the retest evidence that a reviewer reads against those controls.

Department of Health Abu Dhabi (DoH)

Providers licensed in the emirate answer to the Department of Health Abu Dhabi. We scope the systems a reviewer cares about, patient records and the clinical estate first, and report in the chain a review expects.

Dubai Health Authority (DHA)

Providers licensed in Dubai answer to the Dubai Health Authority. The testing is the same. The mapping and the reporting are tuned to the authority your licence sits under.

A test of an EMR or EHR system covers authorisation at the object and function level, how a session is held, and the limits that stop one clinician or one patient reaching another patient's record. In this region that is where the serious findings sit.

The most common high-severity finding we report on healthcare systems is broken object level authorisation: change an identifier in a request and you receive a record, a result or an image that belongs to another patient. No scanner finds this, so we test it by hand, per role and per resource.

We scope the record system, the identity provider and the integration layer behind them separately. A control enforced at one tier is not the same as one enforced at another, and an attacker goes for the weaker one.

Yes. We agree production testing in writing first, exclude denial-of-service techniques by default, and fix the testing window, the excluded techniques and a deconfliction contact in the rules of engagement before any work starts. Nothing arrives as a surprise on a ward.

Where a test case would create real clinical records or touch a device in active use, it runs against a production-equivalent environment instead. If that environment differs from production in a way that matters, the report says so. A test of a different configuration is a test of a different system.

A named contact on both sides handles the case where a tester finds an active compromise rather than a weakness. We settle that path before day one, not during the incident.

We test connected medical devices and PACS imaging systems where they meet the hospital network: the services they expose, the credentials they ship with, and the trust between a device, the imaging archive and the clinical systems that read from it.

We do not run disruptive techniques against a device in active clinical use. We test devices on a segment that mirrors the live network, or in an agreed maintenance window, and the rules of engagement name every device in scope before work begins.

An imaging test answers one question: can an attacker on the network reach a study, alter it, or pivot from the archive into the systems that trust it. We prove each finding rather than assert it.

A UAE healthcare provider should test at least once a year for anything internet-facing, before a significant release reaches production, and after any material change to how patient data is stored, accessed or shared. Where a standard names an interval, treat it as a floor, not a schedule.

A new patient portal, a new integration between clinical systems, or a rewritten login are the changes most likely to introduce the flaws that matter. Each is a reason to test the affected area rather than wait for the annual cycle.

We run the same phases on every engagement, so two reports a year apart are comparable and you can see what changed rather than reading two unrelated documents.

Most providers start with a web and API pentest of their patient and clinician channels, add a mobile app pentest for the apps patients and staff use, and run an internal infrastructure pentest across the hospital network. An IoT pentest of connected medical devices and an objective-based Red Team follow once the basics are covered.

The right mix depends on what you are protecting and what a reviewer has asked for. We scope it with you rather than selling a fixed bundle, and we say where something is not worth buying yet.

Yes. Alongside the full report we can issue an attestation of testing: a short signed statement of what was in scope, when it was tested and that it was tested, which you can hand to a procurement team or include in a regulator submission without passing on the detailed findings.

The attestation points back to the same engagement: the scope, the findings with owners, the remediation order and the retest. A DoH or DHA reviewer, or a client running vendor due diligence on you, gets a summary they can rely on, while the sensitive detail stays in the report that only you hold.