The UAE rules that apply to AI and LLM systems: what security testing they ask for

AI systems sit inside existing security frameworks, not outside them

None of the four UAE regimes that name security testing contain provisions written specifically for artificial intelligence. What they contain are requirements that apply to applications, to information assets and to technology risk management. An AI or LLM system is all three at once, so the existing frameworks reach it without amendment.

The four regimes are CBUAE for banks, payment institutions and insurance companies; DESC for Dubai government entities and their direct suppliers; the NESA Information Assurance Standards federally; and ADHICS for Abu Dhabi healthcare organisations. Each has a different regulated population and a different instrument, but all arrive at the same practical requirement: classify the asset, identify the applicable controls, and produce evidence that testing was carried out. If you are planning an AI and LLM pentest, the first question is which of the four applies to your organisation and whether more than one applies simultaneously.

The table below maps each regime to the sectors it covers, the type of AI-relevant control it names and the testing evidence it is most likely to read.

CBUAE: what financial institutions deploying AI have to evidence

The Central Bank of the UAE applies to every licensed bank, exchange house, payment service provider and insurance company operating in the country. Under its technology risk management requirements, applications handling customer data or executing financial transactions are subject to periodic security testing. An LLM used to process loan applications, generate customer summaries or route service desk queries sits inside that definition. So does an AI model integrated with an open banking API.

The controls that follow from that classification include periodic application security assessments, documented vulnerability management and a remediation record. A financial institution that deploys an AI system in a customer-facing or back-office role needs testing that covers the model interface as well as the underlying application and infrastructure. That means the testing scope has to name prompt injection, insecure output handling and unauthorised data retrieval, which go beyond what a standard web application pentest methodology covers. The earlier article on how to buy an AI and LLM pentest sets out what that scope document needs to include.

Prompt injection in a financial AI is not a theoretical concern. A crafted prompt that bypasses a model's access controls and returns account data belonging to a different customer is a data breach. CBUAE expects evidence that this class of attack was tested and that the finding was either confirmed absent or remediated before the system went live.

DESC: AI in Dubai government entities and their suppliers

The Dubai Electronic Security Center publishes the information security regulation that binds Dubai government entities and any private-sector supplier that processes government data or connects systems to government infrastructure. All information systems handling government data must be classified and periodically tested under that regulation. A chatbot deployed on a government portal, an AI assistant used by a Dubai municipality or an LLM processing supplier invoices for a government-owned entity all qualify.

The supplier obligation is the one most organisations underestimate. A private company contracted to deliver a service to a Dubai government entity is bound by DESC's security requirements as a condition of that contract. If the supplier deploys an AI system that touches government data as part of service delivery, testing that system is part of what the supplier must evidence. The web application pentest is often the anchor engagement, because the AI interface is served over HTTP and the OWASP classes still apply. The AI-specific scope sits on top: prompt injection testing, model output validation and the system's behaviour under adversarial input.

DESC does not publish a checklist of AI-specific controls. It publishes a set of security objectives for information systems, and the entity or supplier determines which controls satisfy those objectives for its specific deployment. That flexibility means testing scope is determined case by case, but the expectation that testing happens is not in doubt.

NESA and the UAE Information Assurance Standards

The UAE Information Assurance Regulation published by the Telecommunications and Digital Government Regulatory Authority applies to federal government entities across both emirates. It requires entities to classify information assets, implement baseline controls aligned to criticality and carry out periodic vulnerability assessments. An AI or LLM system handling government data is an information asset, and the testing obligation follows from its classification rather than from any specific AI provision.

The IAS standard organises controls around confidentiality, integrity and availability. For an AI system, confidentiality means the model must not be induced to return data outside the requesting user's authorisation. Integrity means the model's outputs must not be manipulated by adversarial input. Availability means the system must be resilient against denial-of-service conditions, including prompt flooding. These are testable properties, and an API pentest extended to the model interface covers all three. Federal entities that operate AI systems as part of their service delivery are expected to document both the asset and the testing record in their information security management artefacts.

The IAS requires testing to be aligned to asset criticality. A Tier 1 asset, which covers systems that process sensitive personal data or support critical government functions, is expected to be tested more frequently than a Tier 3 system. An AI system assisting with document classification might sit at Tier 2; one processing citizen data or supporting national infrastructure would be Tier 1, with correspondingly more frequent and thorough testing required.

ADHICS: AI in Abu Dhabi healthcare must be formally assessed

The Abu Dhabi Health Information and Cyber Security standard, published through the Department of Health Abu Dhabi, applies to healthcare providers, insurers and health technology vendors operating in Abu Dhabi. It establishes requirements for information security in health information systems. Clinical AI systems, diagnostic imaging models, LLM-based triage assistants and any system that processes patient records fall within scope as health information systems.

ADHICS requires a formal security assessment before a health information system is deployed and at regular intervals thereafter. The assessment must cover access controls, data handling and the confidentiality of patient information. For an AI or LLM system, the access control requirement extends to the model layer: can a prompt cause the system to return another patient's records? Can a crafted input cause the model to produce clinical guidance it would not otherwise generate? These are the questions a targeted AI and LLM pentest is designed to answer, and the signed assessment report is the artefact ADHICS-regulated entities present to the Department of Health.

Vendor qualification in Abu Dhabi healthcare covers security posture, and a testing report is the standard form of evidence for AI systems. Vendors supplying clinical AI systems to hospitals or insurers in Abu Dhabi are expected to demonstrate that their systems have been assessed and that findings were remediated before the system entered clinical use. That expectation reaches the vendor's own AI infrastructure, not only the system the hospital operates.

What the testing looks like and what it produces for an auditor

All four regimes accept the same form of evidence: a scoped engagement with a stated methodology, a findings report signed by the testing party and a retest record confirming that critical and high findings have been remediated. The methodology statement is where the AI-specific work sits. OWASP's LLM Top 10, published at owasp.org, sets out the ten most critical risks for LLM applications: prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities and others. A methodology that names those classes, describes how each was tested and maps findings to the list is what an auditor reading a CBUAE, DESC, NESA or ADHICS submission wants to see.

The testing scope itself has two layers. The first layer is the AI interface and its application layer: the endpoints that accept prompts, the authentication and authorisation controls, the output validation and the logging. A web application pentest or API pentest covers this layer. The second layer is the AI-specific behaviour: how the model responds to adversarial prompts, whether it can be induced to exceed its authorised scope and whether it leaks training data or system prompt content. That second layer is what distinguishes an AI and LLM pentest from a standard application test. Both layers are needed, and both need to appear in the scope document the auditor reads.

The most common gap in AI security testing submissions is the absence of a methodology statement that names the specific attack classes tested. A report that says the application was tested and found to be secure tells an auditor nothing useful. A report that says prompt injection was tested using direct and indirect patterns, that the model was found to return outputs outside its authorised scope under a specific condition, and that the finding was remediated and retested is what satisfies the control across all four regimes.

AI security testing in Abu Dhabi, Dubai and across the UAE

Organisations deploying AI and LLM systems in the UAE face a layered regulatory picture. A bank headquartered in Abu Dhabi and operating branches in Dubai falls under CBUAE, which applies uniformly across both emirates. A technology supplier to a Dubai government entity falls under DESC, regardless of where the supplier is incorporated. A hospital in Abu Dhabi falls under ADHICS. Any federal government entity in either emirate falls under the NESA Information Assurance Standards. In practice, many organisations answer to two or more of these at once.

Free-zone entities licensed in Dubai Silicon Oasis, Dubai Internet City, DIFC or other free zones are not exempt from these obligations when they handle regulated data or serve regulated clients. The CBUAE obligation follows the banking licence, not the corporate structure. The DESC obligation follows the contract, not the supplier's address. A free-zone AI company supplying services to a bank or a government entity carries the same testing obligations as a mainland company in the same position.

Vendor qualification in both emirates now covers security posture as a standard due-diligence item, and a testing report is how that evidence is presented. Dubai Smart Government programmes and Abu Dhabi's digital health initiatives both require suppliers to demonstrate that their systems have been assessed before deployment. An AI and LLM pentest with a clear methodology statement and a signed findings report is what satisfies that requirement. Organisations that have not yet commissioned this testing before beginning a procurement process frequently find it is a condition of award rather than a post-award obligation.

Frequently asked questions