Security testing rules in the UAE.

A regulation issued under the Central Bank Law. Breaches can lead to supervisory action, fines and removal of managers.

“Violation of any provision of this regulation and any accompanying Standards may be subject to supervisory action and administrative & financial sanctions as deemed appropriate by the Central Bank.”

Introduction; Art. 17.1

Every Licensed Financial Institution with legal personality, not only banks. Art. 1.1 defines Bank as one type of LFI.

“This regulation applies to all Licensed Financial Institutions that are juridical persons.”

Scope

Control-challenging tests, including penetration tests, must be ‘periodic’ but no interval is set. By contrast, business continuity and disaster recovery plans for Critical Operations must be tested at least annually.

“An LFI must periodically conduct stress-tests related to Operational Risk, including through exercises that challenge the LFI’s control environment, for example through penetration testing.”

Art. 7.13; Art. 11.10

Nothing ties threat intelligence to test design or scenarios. Art. 8.7.3 does require ICT and cyber risk management to use actionable intelligence in general.

For Critical Functions, the periodic testing must include a penetration test by an independent third party. No accreditation or certification (for example CREST) is named.

“At least for Critical Functions, the periodic testing referred to in Article 7.13 above must include penetration testing by an independent third party. The results must be presented to the Board.”

Art. 7.14

Art. 7.13 sets no rule on who tests, so internal teams can run the periodic control tests. For Critical Functions, Art. 7.14 adds a penetration test by an independent third party.

“At least for Critical Functions, the periodic testing referred to in Article 7.13 above must include penetration testing by an independent third party.”

Art. 7.13; Art. 7.14

The control-challenging tests must cover ‘controls relying on people’ as well as ICT and physical controls. The text does not use the words social engineering or phishing.

“This includes but is not limited to ICT systems, physical controls, controls relying on people, and any other risk vectors.”

Art. 7.13

Physical controls are named in the scope of the required control-challenging tests. The method, for example physical intrusion testing, is not specified.

“This includes but is not limited to ICT systems, physical controls, controls relying on people, and any other risk vectors.”

Art. 7.13

The penetration testing articles do not mention third parties. Continuity testing should include key Third-Party Service Providers where relevant, and the internal control system must cover activities that rely on them (Art. 7.3).

“Where relevant, testing should include key Third-Party Service Providers. The results must be reported to the Board and Senior Management.”

Art. 11.10; Art. 7.3

No mention of operational technology or industrial control systems.

Payment systems and payment services are a minimum Critical Operation (Art. 3.5.1), but the tests tied to Critical Operations are continuity and recovery tests (Art. 11.10). The third-party penetration test in Art. 7.14 is keyed to Critical Functions, a separate term the text does not link to payment systems, and the Art. 7.13 tests name no payment system. Continuity tests do not count under R8. Coded as CBO BM 1225 and CBB CRA-5.1.4.

Corrected October 30, 2026 from Required. Payment systems enter C 1/2026 only as Critical Operations whose continuity plans are tested (Art. 11.10); continuity tests do not count, as for CBO BM 1225 and CBB CRA-5.1.4.

The regulation does not mention cloud or SaaS. Art. 8.8 covers ICT systems ‘operated or made available by Third-Party Service Providers’ without naming cloud.

Nothing on testing across borders or of foreign group entities. Art. 8.9 requires the Master System of Record to be kept in the UAE, a data residency rule that does not mention testing.

No purple teaming, replay or joint attacker and defender review.

ICT and cyber risk management must be tested to find gaps and then reviewed and improved. Test results go to the Board (Art. 7.14) and weaknesses found in testing must be reported to Board and senior management (Art. 8.4). No remediation deadline or retest rule.

“Be regularly tested to identify gaps against its Risk Tolerance and to review and improve ICT and cybersecurity risk identification, protection, detection and event management”

Art. 8.7.2; Art. 8.4; Art. 7.14

The CBUAE does not run or approve tests and results are not filed with it by default. It can demand any operational risk information and sanction breaches (Art. 17).

“An LFI must provide, upon request, any specific information with respect to Operational Risk that the Central Bank may require.”

Art. 15.4; Art. 17.1

No mention of automated, continuous or AI-driven testing, or of testing AI systems. Art. 7.7 requires periodic assessment of the accuracy of automated controls, which is control automation, not automated testing.

Article 13 of a CBUAE regulation uses ‘shall’. Annex II is non-binding best-practice guidance.

“Payment Service Providers shall comply with this Article (13) and are encouraged to consult Annex II for the Guidance on the best practices for technology risk and information security.”

Art. 13(1)

The testing paragraph applies to licensed Payment Service Providers whose monthly average value of Payment Transactions is ten million dirhams or more.

“Payment Service Providers whose monthly average value of Payment Transactions amounts to ten (10) million Dirhams or above shall regularly assess the necessity to perform penetration and cyber-attack simulation testing.”

Art. 13(17)

The provider must ‘regularly assess the necessity’ of testing. No test interval is set.

“shall regularly assess the necessity to perform penetration and cyber-attack simulation testing.”

Art. 13(17)

Test coverage and scope must be based on the cyber risk profile and the cyber intelligence available. Annex II adds guidance on subscribing to threat intelligence services.

“Coverage and scope of testing shall be based on the cyber security risk profile, cyber intelligence information available”

Art. 13(17); Annex II (Cyber Security Risk)

No rule on who performs the tests. Art. 13(7) requires an independent technology audit function, which is not tied to testing.

Silent on internal versus external testers.

Where testing is done, its scope must cover social engineering as well as internal and external networks and applications. The duty to test at all is a duty to assess the need.

“covering not only networks (both external and internal) and application systems but also social engineering and emerging cyber threats.”

Art. 13(17)

Physical access controls appear only for alternate recovery sites. No physical testing.

Vendors appear only in business continuity paragraphs. No testing of third parties.

No mention of operational technology.

The whole regime governs retail payment services. The tested networks and application systems are those of the payment service provider.

“Payment Service Providers whose monthly average value of Payment Transactions amounts to ten (10) million Dirhams or above shall regularly assess the necessity to perform penetration and cyber-attack simulation testing.”

Art. 13(17)

Cloud appears once, as a disaster recovery dependency whose risk must be managed. Not linked to testing.

Nothing on multi-jurisdiction testing or data location for tests.

No purple teaming or replay.

Findings must be mitigated ‘in a timely manner’ based on impact and risk. No deadline and no retest rule.

“A Payment Service Provider shall also take appropriate actions to mitigate the issues, threats and vulnerabilities identified in penetration and cyber-attack simulation testing in a timely manner, based on the impact and risk exposure analysis.”

Art. 13(17)

Art. 13 gives the CBUAE no role in tests. The only reporting duty in Art. 13 concerns severe service disruptions.

No mention of automated or AI-driven testing.

Guidance that uses ‘should’. It sits alongside binding rules of the four authorities.

“The purpose of the Guidelines is to provide a set of principles when using Enabling Technologies in financial services and accompanying guidance.”

Introduction; Scope of Application

All institutions licensed by the CBUAE, SCA, DFSA or FSRA that use or plan to use APIs, cloud computing, biometrics, big data analytics and AI, or distributed ledgers.

“The Guidelines are applicable to all Institutions licensed and supervised by the Supervisory Authorities that are using, or intend to use, Enabling Technologies.”

Scope of Application

Penetration tests of API systems and of cloud arrangements are expected at least annually.

“These should include conducting vulnerability assessments and penetration tests specific to the Cloud Computing arrangement on at least an annual basis.”

3.18; 3.61(b)

Threat intelligence appears only in cloud monitoring (3.59(b)), not in test design.

API penetration tests should be done by an independent function or an external expert with adequate skills. No accreditation scheme named.

“An independent function or external expert with adequate skills and knowledge should conduct vulnerability assessments and penetration tests on the Institution’s and the API Provider’s systems and infrastructure”

3.18

An internal function may test APIs if it is independent.

“An independent function or external expert with adequate skills and knowledge should conduct vulnerability assessments and penetration tests”

3.18

No social engineering testing.

Physical controls appear for biometrics and DLT (3.81, 3.144), not as a test target.

API penetration tests should cover the API Provider’s systems and infrastructure as well as the institution’s own.

“should conduct vulnerability assessments and penetration tests on the Institution’s and the API Provider’s systems and infrastructure to identify weaknesses or flaws in the security processes at least on an annual basis.”

3.18

No mention of operational technology.

Payment services appear only as an example of innovative activity.

Institutions should run vulnerability assessments and penetration tests specific to each cloud arrangement, at least annually after implementation. Guidance language, not a rule.

“Institutions should conduct vulnerability assessments and penetration tests specific to the Cloud Computing arrangement to identify weaknesses or flaws in the security processes.”

3.53; 3.61(b)

Outsourcing is defined to include providers outside the UAE and data center location must be assessed (3.40), but nothing addresses testing across borders.

No purple teaming or replay.

Tests are to ‘identify weaknesses’; nothing on fixing test findings or retesting. Remediation language covers incidents and configuration changes only (3.57, 3.59).

No regulator role in testing. Firms should address supervisor concerns before material cloud arrangements (2.11).

Material AI models should get rigorous, independent validation and testing before deployment. Separately, 3.55 covers conditions for automated testing and releases in cloud change management.

“Institutions should, where relevant, conduct rigorous, independent validation and testing of material trained Big Data Analytics and AI models to ensure the accuracy, appropriateness, and reliability of the models prior to deployment.”

3.102; 3.55

GEN 5.5.15 is a Rule. The list of methods, including penetration tests and red team exercises, is Guidance.

“An Authorised Person must ensure that: (a) it has in place a comprehensive programme to test the resilience of its IT Systems and Networks and its processes and controls implemented to comply with GEN Rules 5.5.6 to 5.5.14”

GEN 5.5.15

Authorised Firms and Authorised Market Institutions for Financial Services in or from the DIFC; section 5.5 also covers a DIFC branch’s activities wherever carried on. Not Authorised ISPVs or Representative Offices. DFSA says its cyber supervision also covers Registered Auditors and Credit Rating Agencies.

“Subject to (5), this chapter applies to every Authorised Person with respect to the Financial Services carried on in or from the DIFC.”

GEN 5.1.1(1), (3), (5), (6)

Testing must be regular and at least annual for internet-facing systems. Guidance expects more frequent testing for some firms and extra tests after system changes.

“testing under the programme is carried out regularly, and in the case of internet facing systems, at least annually”

GEN 5.5.15(b); GEN 5.5.15 Guidance 2

Test methods follow the firm’s cyber risk assessment (GEN 5.5.5(2)), not threat intelligence. Threat intelligence appears only for incident response plan reviews. The DFSA runs a voluntary Threat Intelligence Platform; its 2024 review found 66% of firms subscribed to cyber threat intelligence platforms.

No independence, qualification or accreditation rule for testers.

Silent on internal versus external testers.

The mandatory test programme must cover the controls a firm puts in place under GEN 5.5.6 to 5.5.14, which include the GEN 5.5.14 training and awareness rule (GEN 5.5.15(a)). GEN 5.5 names no social engineering method, and Guidance 1 lists red team exercises without saying they target people. The DFSA’s 2024 thematic review mentions phishing simulation campaigns among the awareness activities many firms lack; it describes practice and does not set the code.

“it has in place a comprehensive programme to test the resilience of its IT Systems and Networks and its processes and controls implemented to comply with GEN Rules 5.5.6 to 5.5.14”

GEN 5.5.15(a); GEN 5.5.14; DFSA Cyber Thematic Review 2024, p. 12 considered

Corrected October 30, 2026 from Permitted. GEN 5.5.15(a) makes the test programme cover the GEN 5.5.14 training controls and GEN 5.5 names no social engineering method; the 2024 thematic review describes practice and does not set the code. Coded as CMA VASP Art. 51(16)(a).

The mandatory test program must cover controls implemented under GEN 5.5.6 to 5.5.14, which include GEN 5.5.13 on physical access to data centers and server rooms. The method is not specified.

“An Authorised Person must limit physical access to its data centres and server rooms, if any, to individuals who have a legitimate business need.”

GEN 5.5.15(a); GEN 5.5.13

Contracts with ICT providers must let the firm verify the provider’s cyber security. Guidance says self-verification by the provider is not enough. Testing is not named as the method.

“allow the Authorised Person to verify that the third party continues to meet the Authorised Person’s cyber security requirements”

GEN 5.5.3(1)(b)(iv); GEN 5.5.3 Guidance 2

No mention of operational technology.

No mention of payment systems in the cyber section.

Cloud appears only as a reference standard (CSA Cloud Controls Matrix) in GEN 5.5.2 Guidance 1. Nothing on testing cloud services.

GEN chapter 5, which holds section 5.5 and its testing rule (GEN 5.5.15), applies in a Prudential Context to a Domestic Firm’s activities wherever they are carried on (GEN 5.1.1(2)). Sections 5.3 and 5.5 also apply to an Authorised Firm’s entire DIFC branch’s activities wherever they are carried on (GEN 5.1.1(3)). A firm may rely on group-wide cyber policies (GEN 5.5.2 Guidance 2). Nothing on multi-jurisdiction tests, recognition of tests run abroad or where testers sit.

“Sections 5.3 and 5.5 also apply to an Authorised Firm in a Prudential Context with respect to its entire DIFC branch’s activities wherever they are carried on.”

GEN 5.1.1(2) and (3); GEN 5.5.2 Guidance 2

Corrected October 30, 2026 from Not addressed. GEN 5.1.1(2) and (3) apply chapter 5, which holds the GEN 5.5 testing rule, to activities wherever they are carried on, the same kind of application rule counted for QFCRA CTRL 1.1.4(2), CBB and APRA.

No purple teaming or replay.

Firms must have a process to prioritize and remedy adverse test outcomes. Guidance expects extra tests when systems change to fix vulnerabilities found in testing, which is a retest expectation.

“it has in place a process to prioritise and remedy adverse testing outcomes.”

GEN 5.5.15(c); GEN 5.5.15 Guidance 2

The DFSA reviews testing programs in firm-specific cyber risk assessments. It does not lead or approve individual tests.

“The DFSA will continue conducting Firm specific cyber risk assessments.”

DFSA Cyber Thematic Review 2024, p. 14 (Next Steps)

The DFSA found firms relying only on automated vulnerability scans and said they should also use scenario-based tests, penetration tests or red team exercises.

“a number of Firms only conduct automated vulnerability scans and do not use other methods to test their critical IT infrastructure and information systems, including scenario-based testing, penetration tests and/or red team exercises.”

DFSA Cyber Thematic Review 2024, p. 11

GEN 3.5.14 is a binding rule requiring a test program. The testing methods list is Guidance, and the IT Risk Management Guidance says it is not binding.

“An Authorised Person must ensure that: (a) it has in place a comprehensive programme to test the resilience of its IT Systems and Networks and its processes and controls implemented to comply with Rules 3.5.5 to 3.5.13”

GEN 3.5.14(2); ITRMG Introduction iii and ix

The July 2025 amendments cover Authorised Persons and Recognised Bodies in ADGM, including through matching changes to MIR, PRU, PIN, COBS and CIB.

“The Financial Services Regulatory Authority (FSRA) of ADGM today announced the implementation of amendments to its regulatory framework for Authorised Persons and Recognised Bodies in relation to cyber risk management.”

GEN 3.5.1; FSRA announcement July 29, 2025

Regular testing, at least annually for internet-facing systems, plus tests after system changes (Guidance 2).

“testing under the programme is carried out regularly, and in the case of internet-facing systems, at least annually”

GEN 3.5.14(2)(b)

The guidance describes red teaming as simulating threat intelligence-driven targeted attacks and says scenarios of compromise should follow the channels a threat actor could use. The rule itself ties testing to the firm’s cyber risk assessment.

“red teaming exercises where a team of cyber security experts are permitted to simulate sophisticated threat intelligence-driven targeted attacks against the financial institution.”

ITRMG 10.3.3; ITRMG 10.3.4.b

No independence, qualification or accreditation rule for testers.

Silent on internal versus external testers.

The guidance lists social engineering exercises such as phishing campaigns on staff as one form of adversarial testing.

“Such testing can take the form of traditional penetration tests of online platforms, social engineering exercises such as phishing email campaigns on staff, threat hunting exercises, bug bounty programmes”

ITRMG 10.3.3

The mandatory test program must cover controls under GEN 3.5.5 to 3.5.13, which include GEN 3.5.12 on physical access to data centers and server rooms. The method is not specified.

“An Authorised Person must limit physical access to its data centres and server rooms, if any, to individuals who have a legitimate business need.”

GEN 3.5.14(2)(a); GEN 3.5.12

Guidance says tests should involve third-party service providers where appropriate. GEN 3.5.2(1)(c)(iii) requires ICT providers to let the firm verify their security.

“a financial institution should involve relevant stakeholders, such as the governing body, senior management, business functions, third party service provides and customers.”

ITRMG 10.3.5; GEN 3.5.2(1)(c)(iii)

No mention of operational technology.

No testing provision for payment systems.

Cloud services count as ICT Services under the third-party rule, and the asset inventory should include SaaS and cloud-hosted applications, so they fall inside the tested estate. The FSRA co-issued guidance recommends annual cloud-specific penetration tests.

“It should also include ICT Assets belonging to third parties upon which Authorised Person depends, including software as a service and cloud-hosted applications.”

GEN 3.5.4 Guidance 4; GEN 3.5.2 Guidance 1; Enabling Technologies Guidelines 3.61(b)

GEN chapter 3, which holds Rule 3.5 and its testing rule (GEN 3.5.14), applies in a Prudential Context to a Domestic Firm’s activities wherever they are carried on (GEN 3.1(2)). A firm may rely on group-wide cyber policies (GEN 3.5.1 Guidance 4). Nothing on multi-jurisdiction tests, recognition of tests run abroad or where testers sit.

“It also applies in a Prudential Context to a Domestic Firm with respect to all its activities wherever they are carried on.”

GEN 3.1(2); GEN 3.5.1 Guidance 4

Corrected October 30, 2026 from Not addressed. GEN 3.1(2) applies chapter 3, which holds the GEN 3.5 testing rule, to a Domestic Firm’s activities wherever they are carried on, the same kind of application rule counted for QFCRA, CBB and APRA.

No purple teaming or replay workshops.

The rule requires a process to prioritize and remedy adverse test outcomes. Guidance says to fix all findings and retest them before closing.

“it has in place a process to prioritise and remedy adverse testing outcomes.”

GEN 3.5.14(2)(c); ITRMG 10.3.4.f

The FSRA assesses IT practices in supervision. Test results must be reported regularly to senior management (GEN 3.5.14(3)), not filed with the FSRA.

“The FSRA incorporates the assessment of IT practices as part of its supervisory activities over Authorised Persons, Recognised Bodies, and applicants for a Financial Services Permission.”

ADGM IT Risk Management page; GEN 3.5.14(3)

Guidance suggests automated vulnerability scanning systems. The IT Risk Management Guidance also covers AI systems in chapter 14.

“An Authorised Person may wish to consider using automated vulnerability scanning systems to assist in effectively identifying and assessing vulnerabilities resulting from new and evolving threats.”

GEN 3.5.10 Guidance 2

In-scope entities must show compliance. ‘Always Applicable’ controls and their sub-controls are mandatory; other controls apply based on risk assessment. Implementation guidance, where penetration testing appears, is for information only.

“The information on possible automation and the implementation guidance for security controls are provided for information purposes only and can be implemented as the entity prefers, without any further explanation or justification.”

Section 1.1; Section 2.1 (Controls; Implementation Guidance)

Ministries and federal authorities and non-government Critical Information Infrastructure entities. Emirate government entities are covered where no Emirate CIIP program exists; otherwise the Emirate lead enforces it.

“The UAE Information Assurance Standard applies to Ministries & Federal Authorities and Non-Government Critical Information Infrastructure (CII) Entities.”

Section 1.2

The mandatory vulnerability control sets no test interval. Guidance recommends annual internal audits, not tests.

T3.3.1 (new in v2.1, applicable based on risk assessment) requires collecting and acting on threat intelligence, but nothing links it to test scenarios.

Under the National Cyber Security Accreditation Program (NCAP) v2.0, firms providing penetration testing to Government must comply with NCAP and show staff competence through industry-recognized certifications. The IA Standard guidance adds that tests be done by ‘competent and authorized persons’.

“an entity seeking to provide penetration testing services to Government must be able to demonstrate compliance with NCAP requirements, and that personnel have an appropriate level of competence through maintaining industry recognized certifications”

NCAP v2.0 (September 2025) section 2.1.1.1; IA Standard T3.3.2 Implementation Guidance (e)

No bar on in-house testers. Guidance says testing must be by competent and authorized persons, and in-house development tests should be followed by independent acceptance testing.

“conducting planned, documented, and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities”

T3.3.2 Implementation Guidance (e); T7.4.3 Implementation Guidance (f)

Phishing and social engineering appear only as threats, not as test types.

Physical security controls exist (T2) but no physical testing.

For high-risk suppliers, guidance lists periodic vulnerability assessments and penetration testing, and involving the supplier in red teaming or tabletop exercises. T6.2.1 itself (always applicable) requires classifying suppliers by risk and mitigating supplier risk.

“Involving high risk suppliers in resilience assessments and simulations such as red teaming or cyber tabletop exercises.”

T6.2.1 Implementation Guidance (c) and (g)

No testing provision for operational technology.

No testing provision for payment systems.

Third-party risk procedures, including the high-risk supplier measures that list penetration testing, also apply to the entity’s use of cloud service providers.

“This should also apply to the entity’s use of resources of cloud service providers as well.”

T6.2.1 Implementation Guidance

Cross-border data and legal issues are addressed for information transfer and compliance, not for testing.

No purple teaming or replay.

The always-applicable vulnerability control requires a remediation plan before production and measures to address vulnerabilities. Guidance adds testing to confirm the fix works. No deadlines.

“identify vulnerabilities in both new and existing systems and applications and define a remediation plan before placing them in a production environment. 2) test, review, check, and verify the presence of vulnerabilities in production systems.”

T3.3.2 Sub-Controls 1 to 3; T3.3.2 Implementation Guidance (g)

The CSC reviews self-assessments and may perform or commission compliance audits and tests of entities. Entities must facilitate testing when the CSC requests it.

“Where appropriate, perform or commission tests on relevant entities to ensure that IA measures are in place, as well as their effectiveness.”

Section 3.6, Table 3

Guidance allows automated tools such as code analysis and vulnerability scanners in security testing. The Chapter 4 appendix maps the National Cyber Security Policy for AI, which requires vulnerability management for AI/ML systems, onto IA controls.

“Implementing a systematic vulnerability management process to detect, assess, and remediate weaknesses in AI/ML systems.”

T7.4.3 Implementation Guidance (e); Chapter 4 Appendix, National Cyber Security Policy for Artificial Intelligence 2.2

Code unchanged; legal basis updated. Law No. (15) of 2024 supersedes Law No. (11) of 2014 and repeals Executive Council Resolution No. (13) of 2012, the two texts the DESC page cites for the ISR (Art. 23(a) and (b)). Art. 23(c) keeps legislation issued under them in force until replaced. Art. 14(1) makes compliance with DESC regulations a legal duty.

“A Government Entity or a Critical Non-government Entity must: 1. comply with the Electronic Security regulations, standards, and rules issued by DESC”

Dubai Law No. (15) of 2024, Art. 14(1); Art. 23

Correction from a source the September coding missed. Dubai Law No. (15) of 2024 (issued September 4, 2024, in force on publication) tasks DESC with overseeing ISR compliance by Government Entities and by Non-government Entities that DESC classifies as critical. Non-government Entities include firms licensed in free zones such as the DIFC. The DESC ISR page still describes the ISR as applicable to Dubai Government Entities, and the classification framework is not public.

“develop the Information Security Regulation and oversee compliance by the Government Entities and Critical Non-government Entities with this regulation”

Dubai Law No. (15) of 2024, Art. 6(5); Art. 2 (definitions of Non-government Entity and Critical Non-government Entity)

Corrected October 30, 2026 from Dubai Government Entities. Correction from a source the September coding missed. Dubai Law No. (15) of 2024 (issued September 4, 2024, in force on publication) tasks DESC with overseeing ISR compliance by Government Entities and by Non-government Entities that DESC classifies as critical. Non-government Entities include firms licensed in free zones such as the DIFC. The DESC ISR page still describes the ISR as applicable to Dubai Government Entities, and the classification framework is not public.

ISR text not public. DESC provides it to Dubai government entities by email request only.

ISR text not public.

Code unchanged; source and count updated. The rule now rests on primary law, not only on the 2023 launch release and the CREST partner page: covered entities may not engage a security company that DESC has not certified. The DESC Cyber Force register on October 30, 2026 listed 33 penetration testing companies (82 individuals) and 13 incident response companies, against 32 (77 individuals) and 13 on September 28, 2026. Two penetration testing companies were added and one dropped. Three penetration testing listings showed expiry dates before October 30, 2026 (October 21, 22 and 29, 2026).

“not engage any private company or establishment specialised in Electronic Security or host the Data of such a company or establishment, unless this company or establishment is certified by DESC in accordance with the relevant standards and rules prescribed by DESC”

Dubai Law No. (15) of 2024, Art. 14(8); DESC Certified Providers page, retrieved October 30, 2026

ISR text not public. Cyber Force governs outside providers; whether in-house teams may test is not stated publicly.

ISR text not public. DESC ran a phishing awareness activity at its January 2026 ISR officers forum, which is not a testing rule.

ISR text not public.

ISR text not public.

ISR text not public. DESC has a separate ICS (OT) standard for Dubai government and semi-government entities that operate critical infrastructure or industrial control systems, also available only on request.

ISR text not public.

ISR text not public. DESC’s separate CSP Security Standard is mandatory for cloud providers serving Dubai government entities and uses ISO/IEC 27001-style certification with yearly surveillance audits; its testing content was not reviewed.

ISR text not public.

ISR text not public.

ISR text not public.

Correction from the same missed law. DESC must audit and assess compliance by Government Entities and Critical Non-government Entities with security legislation and standards (Art. 6(8)) and oversee ISR compliance (Art. 6(5)). Whether DESC leads, approves or receives individual tests is still not public.

“develop, in coordination with the concerned entities in the Emirate, the measures required for auditing and assessing compliance with the Electronic Security legislation, policies, regulations, standards, and manuals; and assess compliance by Government Entities and Critical Non-government Entities therewith”

Dubai Law No. (15) of 2024, Art. 6(8); Art. 6(5)

Corrected October 30, 2026 from Text not public. Correction from the same missed law. DESC must audit and assess compliance by Government Entities and Critical Non-government Entities with security legislation and standards (Art. 6(8)) and oversee ISR compliance (Art. 6(5)). Whether DESC leads, approves or receives individual tests is still not public.

ISR text not public. DESC’s January 2026 release describes ASAAS 2.0 as an ‘AI-powered auditing engine’ for real-time assessments and automated gap analysis. That is compliance auditing, not security testing.

A Chairman’s resolution of the Capital Market Authority, in force since February 28, 2026, using “shall”. The CMA notes that the Arabic text prevails.

“The licensed entity shall ensure: a. The existence of a comprehensive resilience testing program for its IT systems and networks, as well as testing of processes and controls implemented to comply with the provisions of this Article.”

General Module Art. 51(16)(a); Resolution No. (04/Chairman)/2026, issued 13/2/2026, effective 28/2/2026

The General Module covers anyone conducting VASP activities in or from the UAE. The ATS Module applies the same cyber chapter to operators of alternative trading systems (ATS Module Art. 26(7)). The head office must be within the State’s boundaries under the CMA’s jurisdiction (General Module Art. 65(1)). The text does not mention the DIFC or ADGM.

“The provisions of this module apply to any person who conducts or wishes to conduct any Virtual Asset Service Provider (VASP) activities in accordance with Article (12) of this module in or from within the State.”

General Module Art. 2(1); ATS Module Art. 2(1), Art. 26(7)

The resilience test program must run regularly, and at least once a year for internet-connected systems. The wording follows DFSA GEN 5.5.15 and FSRA GEN 3.5.14.

“Conducting regular tests for the comprehensive program, at least once annually for internet-connected systems.”

General Module Art. 51(16)(b)

The risk assessment must identify threats (Art. 50(3)(a)), but nothing ties threat intelligence to test design.

No rule on who tests. Operators of an ATS for tokenized securities and tokenized commodity contracts (ATS Module Art. 59) and of a multilateral trading facility for virtual assets (Art. 73) must appoint an independent, qualified external auditor for an annual technology audit. That is an audit, not a security test.

Silent on internal versus external testers.

The test program must cover the controls in Art. 51, which include staff cybersecurity training and awareness (51(15)). No social engineering or phishing method is named.

“The licensed entity shall provide training programs for all relevant employees in cybersecurity, along with sufficient awareness measures”

General Module Art. 51(15); Art. 51(16)(a)

The test program must cover the Art. 51 controls, which include restricting physical access to data centers and server rooms (51(13) and (14)). The method is not specified.

“The licensed entity shall restrict physical access to data centers and server rooms, if any, to persons with a legitimate business need”

General Module Art. 51(13); Art. 51(14); Art. 51(16)(a)

Contracts with third parties must require compliance with the firm’s cyber requirements, incident notification and cooperation, and must let the firm verify continued compliance. Testing is not named as the method.

“Allowing the licensed entity to verify that the third party continues to comply with its cybersecurity requirements.”

General Module Art. 48(1)(b) and (c)

No mention of operational technology.

ATS operators run market infrastructure. Art. 26(7) applies the cyber chapter to them, so their trading systems fall inside the annual resilience test program of General Module Art. 51(16). Trading systems must also be tested before going live and after updates, and members’ systems must pass conformance tests (Art. 26(4); Annex (1) Art. 2 and 3). Those are functional and stress tests.

“The licensed entity shall meet the applicable requirements regarding cyber risk management, in accordance with Chapter Three of Part Three of the General Framework Module.”

ATS Module Art. 26(7); General Module Art. 51(16); ATS Module Art. 26(4), Annex (1) Art. 2 and 3; https://legislation.uaecma.gov.ae/en/article-26-technological-resources-and-cyber-risk-management

No mention of cloud or SaaS.

References to outside the State concern fitness and propriety and AML equivalence, not testing.

No purple teaming or replay.

Firms must have procedures to prioritize and address adverse test results. No deadline and no retest rule.

“Having procedures to prioritize and address negative test results.”

General Module Art. 51(16)(c)

The CMA supervises and inspects licensed entities and receives material cyber incident reports within 72 hours (Art. 53). It also receives the annual technology audit report from operators of a tokenized securities ATS or a virtual asset MTF (ATS Module Art. 59(2) and Art. 73(2)). Test results are not filed with it.

“The Authority shall supervise and inspect the licensed entity to verify compliance with the Authority’s legislation and any other applicable related laws”

General Module Art. 67(1); Art. 53(1); ATS Module Art. 59(2); Art. 73(2)

No mention of AI, automated or continuous security testing. ATS members must test trading algorithms in a simulated environment (ATS Module Annex (1) Art. 3), which is algorithm testing, not security testing.

A CBUAE regulation. Breach of the ongoing requirements exposes the operator to sanctions under the Central Bank Law. The security review uses “must”; the network testing sentence uses “should”.

“Upon designation, a designated RPS is required to comply with the ongoing requirements imposed under this Regulation and the relevant provisions of PFMI (see Article (9) for detail).”

Art. 8 (Detailed requirements, Principal requirements)

System operators and settlement institutions of retail payment systems the CBUAE designates as systemically important. The regulation does not apply in Financial Free Zones unless it says so.

“The scope of this Regulation will cover the systematically important RPS which meet one of the following conditions: (a) the concerned system is operated in the State;”

Introduction, Objective and Scope of Application

Security reviews must be periodic and networks tested regularly; no interval is set. A separate compliance self-assessment against the regulation and the PFMI is due at least every 24 months.

“The SO and/or SI of the designated RPS must conduct periodic security reviews of its system.”

Art. 8 (Safety)

Operators must keep pace with the trends of cyber attacks, but nothing ties threat intelligence to tests.

No qualification or accreditation rule for reviewers. An independent party is an option at the operator’s or the CBUAE’s discretion (see internal_testers).

The operator may run its own security reviews; the operator or the CBUAE may decide that an independent party does them.

“Such reviews could be performed either by the SO and/or SI of the designated RPS or, at its (or the Central Bank’s) discretion, by an independent party appointed by it.”

Art. 8 (Safety)

Fraud awareness education for participants is required, not testing.

No physical testing.

Outsourcing needs due diligence and oversight and must be notified to the CBUAE. Nothing on testing or auditing providers.

No mention of operational technology.

The regime governs payment market infrastructure. The payment system itself must get periodic security reviews. Its operation networks should also be regularly monitored and tested.

“The SO and/or SI of the designated RPS must conduct periodic security reviews of its system.”

Art. 8 (Safety)

No mention of cloud.

Cross-border appears only for transactions.

No purple teaming or replay.

Post-incident assessments look for weaknesses after incidents; nothing on fixing review or test findings.

The CBUAE may examine books and records, demand auditor reports and direct corrective action (Art. 8, 4.4 to 4.7). It may also decide that an independent party performs the security review.

“The Central Bank may require the SO and/or SI of, or the Participant Person in, a designated RPS to submit to the Central Bank a report prepared by one or more auditors on matters that the Central Bank requires”

Art. 8, 4.5; Art. 8 (Safety)

No mention of automated or AI testing.

A board resolution of the former Insurance Authority, now in the CBUAE Rulebook as in force. Violations can lead to warnings, suspension of the electronic system for up to six months, or cancellation of approval (Art. 24).

“If it was substantiated by evidence to the Authority and any other competent authorities, that the Company, Insurance Agent or Insurance Broker committed a violation, then the Authority may take one of the following actions and penalties:”

Art. 24; Art. 7

All electronic and smart insurance operations of licensed insurers, insurance-related professions, and banks marketing insurance, as applicable.

“These regulations shall apply to all electronic and smart insurance operations practiced by licensed Insurance Companies, Insurance-related Professions and marketing insurance policies through banks to the extent applicable to their nature.”

Art. 2

Tests for illegal access and vulnerability assessments of the website or app must be regular; no interval is set.

“Companies and related professions shall regularly conduct tests for Illegal Access and assessing vulnerabilities for the website or smart application to guarantee the soundness of such and to fill any potential gaps (if any).”

Art. 7

Cyber risk must be analyzed in the action plan (Art. 3), but nothing ties threat intelligence to tests.

No rule on who tests.

Silent on internal versus external testers.

No social engineering testing.

No physical testing.

With the Authority’s prior approval, a company may assign the management of its website to another party, and it must regularly test the website or smart application for illegal access and vulnerabilities (Art. 7). The test duty therefore covers a website a provider runs. The outsourcing contract must bind the provider to the Regulation (Art. 13). The text does not say whether the company or the provider runs the test; R6 codes required either way.

“Companies and related professions shall regularly conduct tests for Illegal Access and assessing vulnerabilities for the website or smart application to guarantee the soundness of such and to fill any potential gaps (if any).”

Art. 7; Art. 13

No mention of operational technology.

Premium collection is an electronic insurance operation, but no payment system testing is set.

Art. 9(2) refers to storing data inside the State and in the cloud under competent-authority criteria. No cloud testing. The Art. 1 definition of Website lists social networks, blogs and collaboration tools, so the Art. 7 test duty may reach company channels hosted on them; the text does not say so directly.

Data must be stored inside the State (Art. 9(2)), a residency rule that does not mention testing.

No purple teaming or replay.

The test duty includes filling any gaps found. No deadline and no retest rule.

“Companies and related professions shall regularly conduct tests for Illegal Access and assessing vulnerabilities for the website or smart application to guarantee the soundness of such and to fill any potential gaps (if any).”

Art. 7

The Insurance Authority, whose functions the CBUAE now holds, runs periodic or challenge inspections and may request any information.

“The Insurance Authority shall supervise and conduct periodical or challenge inspections in order to ensure compliance with the legislation issued by the Authority”

Art. 23(1) and (2)

The Art. 1 definition of Website includes AI and machine-learning systems and chatbots, so the Art. 7 duty to test the website for illegal access and vulnerabilities covers them.

“Systems based on artificial intelligence and machine learning. Autoreply, chatbot and smart personal assistant.”

Art. 1 (definition of Website); Art. 7