NESA Penetration Testing in UAE - A Practical Compliance Guide

NESA penetration testing is not a single control or a one-line requirement. It is a cluster of obligations spread across the UAE Information Assurance Standards (IAS) - and getting audit-ready means understanding which controls apply to your entity, what evidence the auditor expects, and where most UAE organizations get it wrong.

This guide walks through the practical reality of scoping, running, and reporting a NESA-compliant penetration test in the UAE.

What NESA Is (and Isn’t)

The National Electronic Security Authority (NESA) - now administratively consolidated with the National Cybersecurity Authority (NCA) - is the UAE federal body that publishes the Information Assurance Standards and enforces them against designated Critical Information Infrastructure (CII) entities.

The IAS are the UAE federal cybersecurity baseline. They are not optional for CII entities, and they are heavily referenced by private-sector regulators and customer security questionnaires even where not legally binding.

NESA is what a CISO in a UAE bank, utility, telecom, or healthcare network answers to. It is what a DIFC or ADGM supervisor expects to see referenced in the cybersecurity attestation of a DFSA- or FSRA-licensed firm. It is what shows up in every RFP for government IT services.

Who Must Comply

NESA IAS is binding for Critical Information Infrastructure entities, which includes:

• Banking and financial services (also subject to CBUAE Information Security standards, DFSA Rulebook, VARA Technology and Information Risk)
• Telecommunications (also subject to TDRA Information Security Regulation v2)
• Energy, water, and utilities
• Healthcare networks and hospitals (overlap with DHA/DOH requirements)
• Government entities (additional ADSIC requirements in Abu Dhabi)
• Transportation and aviation
• Oil and gas

If you are not in a CII category, NESA is still the de-facto baseline you will be measured against - most UAE enterprises are asked to reference NESA alignment in customer security questionnaires even when not legally obligated.

The Control Families That Mandate Penetration Testing

NESA IAS is structured as a set of control families. Penetration testing is explicitly required under the following (numbering aligns to public IAS documentation - check your current revision with the authority):

• Vulnerability and Patch Management - periodic vulnerability assessments and penetration testing of internet-facing infrastructure and critical internal systems.
• Application Security - application-layer penetration testing for business-critical applications.
• Network Security - network and perimeter testing including segmentation verification.
• Supplier and Third-Party Management - documented security assessment of material third-party applications and integrations.
• Incident Response and Continuous Monitoring - red-team exercises and adversary simulation as part of response readiness validation.

The testing must be independent (an external firm, not the internal IT team) and must be re-performed at defined intervals (typically annually for the full baseline, with more frequent targeted testing of internet-facing assets and after significant changes).

Testing Frequency Expectations

Auditors typically expect:

• Annually - full-scope penetration test covering all internet-facing assets, business-critical internal applications, and the identity and access infrastructure.
• Quarterly or more often - targeted testing of public-facing web applications and APIs.
• After every significant change - new application launch, major architecture change, cloud migration, merger or acquisition integration.
• Red team exercise annually - adversary simulation going beyond pre-announced pentesting, including social engineering and physical intrusion where relevant to the entity.

A single annual pentest is rarely sufficient for CII entities. A programmatic approach - continuous assessment with a defined cadence per asset category - aligns better with what NESA auditors expect to see.

What Auditors Actually Look At

In UAE NESA audits, these are the evidence artifacts most commonly requested:

1. Engagement statement of work - showing defined scope, rules of engagement, and out-of-scope boundaries. The auditor checks the scope is sufficient to exercise the control, not that the engagement is performed at all.
2. Tester independence attestation - the testing firm must be demonstrably independent of the tested entity. A shared parent, shared ownership, or conflict of interest will be flagged.
3. Findings report with severity classification - every finding severity-scored (CVSS v3.1 is the de-facto expectation).
4. Remediation tracking and closure evidence - for each high or critical finding, evidence of remediation or risk acceptance with executive sign-off.
5. Retest evidence - documentation that remediated findings were independently validated by the testing firm.
6. Supplier attestation letter - many auditors expect a short letter from the testing firm confirming engagement dates, scope, and summary outcome.

The most common audit findings are not missing penetration tests - they are missing retest evidence (findings marked “remediated” without independent verification) and stale scope (engagement scope predates the current production estate).

Common Gaps We See in UAE Environments

In NESA audit preparation engagements, these patterns repeat:

• Internal pentests run by the internal team, then externally “reviewed”. Does not satisfy independence requirement.
• Web-only testing for entities with substantial API and cloud attack surface. NESA control coverage should reflect the actual architecture.
• Critical findings marked “accepted risk” without documented executive authority. Risk acceptance is allowed but must be evidenced.
• Supplier penetration testing assumed to cover the integrating entity. It does not - you still need testing of the integration and the composite attack surface.
• Cloud migrations without pre-migration and post-migration testing. A new cloud estate is a significant change that triggers testing.

How pentest.ae Handles NESA Engagements

We are not a NESA audit firm. We are the penetration testing firm NESA-regulated entities engage to produce the evidence their audit firm will accept. Our reports include:

• Explicit mapping of every finding to the NESA IAS control family it touches
• Tester independence attestation and engagement summary letter suitable for the auditor’s evidence file
• CVSS v3.1 scoring with executive risk tiering
• Defined retest cycle for all critical and high findings, producing retest attestations that can be filed alongside the original report
• Coordination with the client’s audit firm on request - we have worked with all four major UAE audit and assurance practices on NESA evidence review

If you have a NESA audit on the calendar and need documented penetration testing evidence - or if you are building the program and need to establish the baseline - start with a scoping call. We scope for the control coverage you need, not for the hours we want to sell.

Related Resources

• Penetration Testing UAE - full service overview
• API Security Testing - relevant to NESA application security controls
• Cloud Penetration Testing - relevant to NESA cloud and third-party controls
• DFSA Penetration Testing Guide - adjacent guide for DIFC-regulated firms