The UAE Information Assurance (IA) Regulation — originally issued by NESA, now under the Signals Intelligence Agency (SIA) and published via the TDRA — places security testing under control T7.7 Technical Vulnerability Management, specifically sub-control T7.7.1, a priority P1 (highest) requirement to implement a technical vulnerability management process. The control's guidance discusses vulnerability scanning and manual penetration testing, but — and this is where many guides overreach — it does not impose a rigid annual cadence in the control text; it frames testing as risk-based. The Regulation applies to UAE federal government entities and Critical Information Infrastructure operators, with controls graded P1–P4. It is the federal baseline that Abu Dhabi's ADHICS and Dubai's DESC ISR build upon.
// 01 What is the UAE IA Regulation, and is it still called NESA?
Effectively, "NESA" and the "UAE IA Regulation" refer to the same thing, and the naming confusion is worth clearing up first. The standard was originally issued by NESA, the National Electronic Security Authority. Around 2020, NESA was restructured into the Signals Intelligence Agency (SIA), and the document is now hosted and issued through the TDRA (Telecommunications and Digital Government Regulatory Authority), with the UAE Cyber Security Council setting national policy above it. The document's own title is the UAE Information Assurance Regulation, and its control catalogue is the UAE Information Assurance Standards.
In day-to-day use, security teams and consultancies still say "NESA compliance," and that is fine as shorthand — but on formal documentation, the current name is the IA Regulation. If a vendor insists the standard is "NESA" and nothing else, it is a small sign they are working from dated material.
// 02 Which control covers penetration testing?
The IA Regulation organises its controls into two families — Management (M1–M6) and Security Technical (T1–T9) — across fifteen control families and roughly 188 sub-controls. Security testing lives in the technical family, at control T7 Information Systems Acquisition, Development and Maintenance, specifically the subdomain T7.7 Technical Vulnerability Management.
Priority: P1 — the highest of the four priority levels, making it a mandatory baseline control.
Applicability: based on risk assessment.
Requirement: "The entity shall implement a technical vulnerability management process."
Guidance references: vulnerability scanning, and "manual application security penetration testing by testers who have extensive programming knowledge and application penetration testing expertise" — while cautioning that such testing must be done carefully, as it could affect system security.
So penetration testing is not a standalone named control in the IA Regulation; it is the recognised method of satisfying the P1 technical vulnerability management requirement. That distinction matters for how you document compliance: you evidence T7.7.1 with a vulnerability management programme, of which penetration testing is a key part.
// 03 How often must you test under the IA Regulation?
Here is where accuracy matters. Many consultancy guides state that NESA "requires annual penetration testing." The control text does not say that. T7.7.1 mandates a technical vulnerability management process at priority P1, and its guidance frames testing as risk-based — noting that scanning frequency "should increase as the diversity of an entity's systems increases." There is no fixed annual interval written into the control.
In practice, annual penetration testing is the sensible and widely adopted baseline, and most CII operators test at least yearly plus after significant change. But when you document compliance, cite the control accurately: T7.7.1 requires a risk-based vulnerability management process, and you have set an annual (or more frequent) testing cadence as your implementation of it. Overstating the rule as a literal mandate is the kind of imprecision an assessor notices. The priority-level system is the real driver of what applies:
| Priority | Meaning | Implication |
|---|---|---|
| P1 | Highest | Baseline mandatory controls — T7.7.1 sits here |
| P2 | High | Applied per risk and entity criticality |
| P3 | Medium | Applied per risk assessment |
| P4 | Lower | Applied where relevant |
// 04 Who must comply?
The IA Regulation applies to UAE federal government entities and to operators of Critical Information Infrastructure (CII) — the organisations whose systems, if compromised, would have national impact, across sectors such as energy, finance, telecommunications and transport. For these entities, the applicable controls across all four priority levels are mandatory, with the P1 set forming the non-negotiable baseline that includes technical vulnerability management.
Private-sector organisations outside CII are not directly bound by the federal Regulation, but many adopt it as good practice, and many more are pulled into it through contracts with government entities that flow the requirements down the supply chain — the same pattern seen across the Gulf.
// 05 How the IA Regulation relates to ADHICS and DESC
The UAE runs a layered model: the federal IA Regulation is the national baseline, and the emirates and sectors add their own standards on top. Understanding the stack prevents duplicated effort.
UAE IA Regulation (SIA/NESA)
The national baseline. T7.7.1 technical vulnerability management. Federal government and CII.
ADHICS
Abu Dhabi healthcare. Maps its OM 7.1 testing control directly to IA T7.7.1 — and adds an explicit yearly testing schedule.
CBUAE & others
The UAE Central Bank and other sector regulators layer their own testing expectations for banks and regulated firms.
The efficient approach for an organisation subject to more than one is to scope a single penetration test against the union of them and map findings to each control reference — T7.7.1 for the federal baseline, OM 7.1 for Abu Dhabi healthcare, and the DESC compliance domain for Dubai. (Note: there is no UAE law called "NIS 2" — that is an EU directive; the UAE equivalents are the instruments above.)
// 06 Frequently asked questions
Is the UAE IA Regulation the same as NESA?
Effectively yes. NESA issued the original standard and was restructured into the SIA around 2020; the document is now published via the TDRA. Current name: UAE Information Assurance Regulation.
Which control covers penetration testing?
T7.7 Technical Vulnerability Management, sub-control T7.7.1 — a priority P1 requirement to implement a technical vulnerability management process, with guidance covering scanning and manual penetration testing.
Does it require annual penetration testing?
Not as a literal fixed mandate. T7.7.1 requires a risk-based vulnerability management process; annual testing is the accepted baseline in practice, not a rigid interval in the control text.
Who must comply?
UAE federal government entities and Critical Information Infrastructure operators, with controls graded P1 to P4 and P1 as the mandatory baseline.
// 07 Sources
- UAE Information Assurance Regulation (v1.1), control T7.7 Technical Vulnerability Management, sub-control T7.7.1 (priority P1) — published via the TDRA. Control text verified against the official document.
- Governance lineage (NESA → Signals Intelligence Agency; UAE Cyber Security Council) — per official and reputable secondary sources.
- ADHICS (Department of Health Abu Dhabi) and DESC ISR (Dubai Electronic Security Center) — see our companion UAE guides.
Control references reflect the UAE IA Regulation as published. Applicability and priority-level obligations depend on your entity classification — confirm against the current standard before relying on this for a compliance submission.