The UAE rules that ask for a web application pentest

Four regimes name security testing, and more than one can apply

No UAE instrument uses the phrase web application penetration test. What the instruments say is that entities in scope test their systems for vulnerabilities on a schedule, remediate what is found, and keep the record. Four regimes carry that requirement. Which one binds you follows from your sector and your emirate rather than from the technology you happen to run, and more than one can apply to the same application at once.

CBUAE supervises licensed financial institutions. DESC publishes the standard that Dubai government entities, and the suppliers who serve them, are held to. ADHICS covers healthcare entities in Abu Dhabi and is published through the Department of Health. The UAE Information Assurance Standards apply federally to the critical sectors. Read the one that applies to your licence rather than a summary of it. Cadence, reporting line and the definition of a significant change are not identical across the four.

That last point is worth holding to. Proposals quote article numbers at buyers, and the wording of a clause changes between versions of an instrument, so a vendor's paraphrase is not evidence of anything. Take any control reference going into your own policy from the published text. If you are still deciding what the test itself involves, what a web application pentest covers is the shorter answer to that question.

What the rule leaves for you to decide

The obligation is written at the level of the outcome. Test, fix, record. The instruments do not tell you which requests to send, which roles to hold, or how deep to go, which means the method is yours to choose and yours to defend. An assessor cannot evaluate the sentence we ran a penetration test. They can evaluate a named standard, a stated level, and a list of the roles that were held while the testing ran.

So name the standard in the engagement letter and again in the report. The OWASP Web Security Testing Guide is the usual reference for how an application is tested. The Application Security Verification Standard gives you a level to claim, which is the part a reviewer can hold you to. NIST SP 800-115 covers the shape of the exercise around it. A web application pentest that cites all three is easier to defend than one that cites none.

Choosing a level has a second effect that buyers tend to discover late. Verification at level 2 asks for authenticated coverage of access control and business logic, so claiming it commits you to giving the tester working credentials for every role in the application. That is a scoping decision with a real cost attached, and it is the decision that determines whether the report says anything about authorisation at all.

The evidence pack an assessor actually reads

What an assessor reads is not the test. It is the pack the test produced. Five things, in order, and the order matters because each one is only meaningful if the one above it is present. A finding with no scope statement above it cannot be placed against a system. A remediation record with no retest under it is a claim that something was fixed.

Two lines carry more weight than the rest of the front matter. Written generically, as an example, they look like this. Scope: portal.example.ae, release 4.2.1, roles held during testing: anonymous, customer, branch officer, administrator. Method: OWASP WSTG v4.2, authenticated, source code not provided. An assessor who reads those two lines knows what was covered and what was not before reaching a single finding, and everything in what a penetration test report has to contain sits underneath them.

Keep the pack together and keep it dated. A report from a provider, a remediation spreadsheet in another team's drive and a retest confirmation in somebody's inbox are three artefacts an assessor has to assemble on your behalf. Assembling them is where the gaps become visible.

How often, and what should trigger an unscheduled test

Annual is the floor most internal policies settle on, and on its own it is a weak answer. An application that ships every fortnight has changed beyond recognition by month four, so the useful question is not how often but what counts as a significant change. Write the trigger list down before you need it: a new authentication provider, a new role or permission boundary, a new payment or data export path, a rewritten API behind an unchanged interface.

That last trigger is the one that slips through. The screens look identical, the endpoints underneath are new, and the authorisation logic has been reimplemented from scratch; if the backend is now a separate service, an API pentest is the test that reaches it. Set the cadence from exposure and rate of change together rather than from the calendar alone.

Where an application is both regulated and fast-moving, tying the test to the release train keeps the report describing something that still exists. A second test in the same year also costs less to run than the first, because scope, roles and access have already been agreed and the retest of the earlier findings folds into it.

The cycle that survives an audit

The cycle is short and every stage of it produces a document. Agree scope and name the method before anything starts. Test, and record evidence a second tester could reproduce. Fix, with an owner and a date against each finding, including the ones you decide to accept. Retest, and file the verification. What closes a finding is the retest, not the ticket saying the fix was deployed.

One stage of that cycle is usually wasted. While the test runs, your own alerting is being exercised by a known adversary on a known schedule, which is the cheapest detection rehearsal available to you; what your monitoring should catch during a web app pentest sets out what should have reached a human. Record what you saw and what you missed. That record is evidence for a different control family in the same audit.

Then start the next cycle from the last retest rather than from a blank scope. The roles, the environments and the fixed findings are already written down, and the delta since the previous test is the part worth spending the argument on.

What this looks like in Dubai and Abu Dhabi

The regime that binds you is often decided by who buys from you rather than by where you are registered. A software supplier in a Dubai free zone with no direct regulator of its own inherits DESC's expectations through contract the moment it serves a Dubai government entity, and that clause generally asks for a current test report covering the service being delivered. A bank supervised by CBUAE carries the same obligation in both emirates, because the licence follows the institution rather than the office it sits in.

In Abu Dhabi, healthcare entities and the vendors working inside their environments are held to ADHICS, and a patient portal sits squarely within that. Mainland or free-zone status changes your licensing and your contracting, not the security expectation attached to the data you hold. For UAE buyers the practical difference between the two emirates shows up in procurement: what a tender asks you to attach, how recent the report has to be, and whether a retest record is required alongside it. Plan the year's penetration testing around those dates rather than around the anniversary of the last engagement.

Frequently asked questions