IoT testing evidence UAE regulators read: ADHICS, CBUAE and DESC

Why regulators ask for more than a network scan report

IoT spans three distinct attack surfaces: the device itself, including firmware, hardware debug interfaces and local radio; the network path and segmentation between device and backend; and the cloud or on-premises system the device reports to. A standard network pentest produces evidence for one of those three. A regulator reading an IoT audit trail needs to see that all three were tested, that the test matched the device's actual function, and that findings at each layer reached remediation.

The gap between what a network scan delivers and what a regulator needs is where most IoT compliance submissions fall short. Discovering open ports on a device segment is not the same as testing the firmware running on each device or the radio protocol it uses to communicate. Regulators in all four UAE regimes read the scope section of the evidence pack first, because an untested layer is an unreviewed risk regardless of what the tested layers showed. The article How an IoT pentest is run: firmware, radio, hardware and the cloud side describes how the test itself is structured; this article covers what the resulting documentation must show.

ADHICS and connected devices in Abu Dhabi healthcare

ADHICS, the Abu Dhabi Healthcare Information and Cyber Security Standard, is maintained by the Department of Health Abu Dhabi. Version 2 of the standard requires healthcare entities to maintain an inventory of connected medical devices and to subject those devices to periodic security assessments. The testing scope must cover network-connected medical devices as a named category, separately from general IT infrastructure.

ADHICS requires that the evidence pack demonstrates four things for connected devices: that the device inventory was the basis for the test scope, that network segmentation between clinical and administrative networks was verified during the test, that authentication configurations on devices and their backends were reviewed, and that any unencrypted channels carrying patient data were identified and treated. A submission that shows only that ports were scanned does not satisfy these four requirements.

The remediation record is part of what ADHICS requires, not a separate document. Findings that were open at the time of submission need a risk acceptance document signed by an accountable owner. ADHICS does not require zero open findings at audit, but it requires that every open finding has a documented owner, a treatment decision and a review date. A finding left in the report without any of those three will cause the submission to be queried.

For entities running connected devices that handle patient data across multiple Abu Dhabi facilities, the inventory requirement means the test scope must be derived from a central register, not assembled per-site. A test that covered one site's device estate but not another's does not satisfy the requirement even if both sites use identical hardware, because the evidence must show that actual coverage was verified, not assumed.

What CBUAE reads for connected financial systems

CBUAE's cyber risk management framework, issued by the Central Bank of the UAE, applies to all network-connected devices within a licensed institution's perimeter. This includes POS terminals, ATMs, payment kiosks, and smart banking hardware. The regulator does not treat these as peripheral equipment outside the cyber risk scope; it reads them as part of the institution's overall risk posture.

An IoT pentest in a financial institution typically covers both the device estate and the backend payment processing API, because CBUAE reads the two as a single risk. A terminal that has been tested but whose backend is unreviewed does not satisfy the framework. The evidence pack must show that the connection between device and backend was tested end to end, including authentication at both ends, data in transit protection and what happens when a device presents unexpected input to the backend.

CBUAE does not mandate a specific IoT testing methodology. What it reads is evidence of a systematic approach to cyber risk management. That means the evidence pack needs to show how findings were prioritised, what was fixed, what was accepted as residual risk, and who made the acceptance decision. An open finding on a POS terminal without a remediation date or a risk owner reads as a gap in the institution's risk management process, not just an unresolved technical issue.

The testing programme must include a prioritisation step, not just a list of findings. A financial institution producing an evidence pack for CBUAE review should be able to show that high-risk findings were resolved before the submission date and that the residual open items all carry risk ratings, owners and scheduled review dates.

DESC requirements for Dubai government and smart infrastructure

The Dubai Electronic Security Center issues the Dubai Information Security Regulation, which applies to Dubai government entities and their technology suppliers. Connected systems operated by Dubai government agencies, including public services infrastructure, smart city hardware and utilities, fall within DESC's scope. Technology suppliers providing IoT devices to Dubai government entities may also be required to demonstrate pentest evidence as part of their procurement qualification.

The article The UAE rules that apply to IoT security testing covers the CBUAE, NESA and DESC frameworks at a high level. For suppliers bidding on Dubai smart city contracts, DESC's supplier security requirements mean pentest evidence may need to be submitted with the tender, not only produced at an annual review cycle. A supplier that has never run an IoT pentest before engaging with a DESC-regulated client will not have the evidence pack ready when the procurement process asks for it.

DESC reads evidence at two distinct points: before a system goes live as a pre-deployment test, and during the annual review cycle as an ongoing assurance measure. A connected system that produced pentest evidence for procurement but has not been retested since deployment will not satisfy a DESC audit. The retest record is part of the evidence pack, not a separate optional document. Each retest must show which findings from the previous cycle were closed, what verification was performed, and what remains open.

For suppliers operating across both the Abu Dhabi and Dubai markets, the two sets of requirements are compatible in structure. An evidence pack that satisfies DESC's finding register and retest record requirements will also cover the structural requirements ADHICS places on connected device testing. The difference is in what each regime classifies as mandatory scope: DESC focuses on the connected system as a whole, while ADHICS names clinical network segmentation and patient data handling as specific required test cases.

The federal IAS baseline for operators outside sector regulators

The UAE Information Assurance Standard (IAS), published by TDRA, establishes minimum security requirements for UAE federal entities and can be adopted by private sector operators as a baseline. IoT operators that do not fall under CBUAE, DESC or ADHICS, such as free zone technology companies, manufacturers or logistics operators, commonly use the IAS framework to structure their testing programme.

The IAS requires entities to maintain an asset inventory covering all network-connected devices, to conduct periodic security assessments, and to manage findings through a documented risk treatment process. For IoT specifically, the inventory requirement means the test scope must be derived from a managed register, not assembled by the tester at the time of the engagement. A test that covered devices the tester could find but not devices the entity forgot to declare does not satisfy the requirement.

The IoT pentest report structure covers what goes into each finding. For IAS compliance, the report also needs to carry the asset register mapping so the regulator can verify that test coverage matched the declared inventory. A report without that mapping leaves the question of scope coverage unanswered. The IAS does not mandate a specific test depth or methodology, but the risk treatment process must be documented and show who made each treatment decision.

What a compliant evidence pack contains across all four regimes

An evidence pack that satisfies one UAE regime will usually satisfy the others, because the core requirements overlap: a tested scope derived from an asset register, findings with severity and evidence at each tested layer, a remediation log showing which findings were closed before the submission date, and a retest record confirming those closures. The regime differences lie in what each classifies as mandatory scope, not in the basic structure of the documentation.

The practical differences come down to scope. ADHICS requires device-specific clinical network segmentation evidence and patient data handling review as named test cases. CBUAE reads the device estate as part of a broader cyber risk assessment and requires findings with risk ratings and named owners. DESC may request the evidence pack at procurement, so the documentation timeline starts earlier than for annual audit cycles. The federal IAS requires asset register mapping but does not mandate a specific test depth or methodology.

For operators regulated by more than one regime, such as a healthcare provider with a licensed payment function, one evidence pack satisfies both if it covers device inventory, all tested layers, remediation status per finding and a retest schedule. The only additional step is ensuring that ADHICS-specific test cases, clinical segmentation and patient data handling, are included in the scope alongside the financial system controls CBUAE reads.

The article How to buy an IoT pentest: scope, handover and what the proposal must say covers how to specify the scope so the evidence produced at the end of the engagement is the evidence the regulator needs. Specifying the scope correctly at the start is cheaper than producing supplementary testing evidence after a regulator queries a submission.

IoT evidence requirements across Abu Dhabi, Dubai and the UAE

The UAE's regulated sectors are split across two emirate-level authorities and one federal standard. Abu Dhabi healthcare entities answer to ADHICS, enforced by the Department of Health Abu Dhabi, which requires connected medical device testing as a named category with specific test cases covering clinical network segmentation and patient data handling. Dubai government entities and their technology suppliers answer to DESC, whose supplier security requirements can extend pentest evidence obligations upstream to device vendors bidding on government contracts before those contracts are signed.

Financial institutions operating across both Abu Dhabi and Dubai answer to CBUAE, whose cyber risk framework treats connected devices as in-scope irrespective of the emirate in which they are deployed. An IoT device serving customers in both Abu Dhabi and Dubai does not require two separate evidence submissions; a single CBUAE-aligned evidence pack covers both, provided it covers the device estate in its entirety rather than by location.

Federal operators not subject to CBUAE, DESC or ADHICS use the TDRA-published IAS as their baseline. The IAS requires an asset inventory, periodic testing and a risk treatment record. Many UAE government contracts and free zone licensing frameworks require suppliers to demonstrate IAS alignment as a procurement condition, so the evidence pack requirement reaches private sector operators through commercial relationships as well as direct regulatory obligation. Identifying which regime applies, and at which point in the business relationship evidence is needed, determines how the testing programme should be timed.

Frequently asked questions