Key takeaways
- CBUAE, DESC, NESA and ADHICS each expect different things from a web application pentest report, but all require findings mapped to specific controls.
- A test report that only lists vulnerabilities without control references or remediation tracking is unlikely to satisfy a regulatory review.
- Retest evidence is as important as the initial test findings: a closed finding with no verification record does not satisfy most UAE regulatory requirements.
- CVSS scores alone do not map to regulatory risk ratings: the report must translate technical severity into business impact for the audience that acts on it.
- Structuring your report before the test begins, not after, is the only way to ensure the evidence chain is complete when a regulator asks for it.
What evidence of testing means to a UAE regulator
When a UAE regulator asks to see evidence of web application security testing, they are not asking for a summary. They are asking for a document that lets them verify three things: that the right scope was tested, that the findings were genuine, and that something was done about them. A one-page summary and a list of tool outputs answer none of those questions.
The OWASP Web Security Testing Guide gives the technical catalogue, and its test identifiers are the standard reference a report uses to show which test cases were run. The form the report takes, the depth of evidence, and the remediation record it must contain are shaped by which regulator is reading it.
Knowing what each regime expects is where to start. The article The UAE rules that ask for a web application pentest covers which rules require testing. This article covers what a compliant report looks like once the test is complete.
Prepare
Scope agreement
Systems, exclusions, test window named in writing
Authorisation letter
Written permission, naming tester and scope
Test
WSTG execution
Mapped test cases per OWASP category
Evidence capture
Requests, responses, screenshots per finding
Report and verify
Findings and CVSS
Severity rated, reproduction steps included
Control mapping
WSTG reference and framework control per finding
Retest and closure
Independent confirmation the fix was applied
The four UAE regulatory regimes and what each asks of a web app test
Four regulatory regimes in the UAE name security testing explicitly: CBUAE for licensed financial institutions, DESC for Dubai government entities and their technology suppliers, the UAE Information Assurance Regulation for federal entities, and ADHICS for health information systems in Abu Dhabi. Each regime has a different scope, a different testing frequency, and different report requirements.
They are not interchangeable. A bank regulated by CBUAE and a healthcare portal governed by ADHICS may both run a web application pentest each year. The scope of that test, the report structure, and the evidence chain each regulator will examine differ across the two. The table below sets out the main points of difference.
No single report format covers all four at once, but a well-structured report built against the OWASP WSTG, with CVSS scores, control references and a remediation tracking section, comes close. The gap is usually in the control mapping layer, which must align to the framework each regulator publishes. The UAE Information Assurance Regulation is the federal instrument, and a report for a NESA-bound entity must map findings to its control identifiers.
| Regulator | Sector | Testing frequency | Key report requirements |
|---|---|---|---|
| CBUAE | Banking and financial services | Risk-based, annual cycle for internet-facing systems | CVSS scores, board-level executive summary, remediation plan with dates and owners |
| DESC | Dubai government entities and suppliers | Before go-live and on material change | Scope aligned to system classification, findings closed before deployment |
| NESA / UAE IAR | Federal entities and critical infrastructure | Risk-based, defined in the entity security plan | Control reference per finding, risk acceptance for open findings in the risk register |
| ADHICS | Abu Dhabi healthcare | Periodic and pre-deployment for systems handling patient data | PHI boundary coverage, severity-to-risk translation, audit trail per finding |
What CBUAE expects from a financial institution's web test report
The Central Bank of the UAE publishes technology risk guidance that covers internet-facing web applications as a primary attack surface. Testing is expected on a regular cycle and after any material change to scope or architecture, and the report must be retained and available for supervisory review.
CBUAE reviewers look for a clear scope statement that names the application, its environment and its test boundaries. They look for CVSS-scored findings with reproduction steps, not a list of tool names. And they look for a remediation section that includes planned fix dates and, where a finding has been closed, evidence of the closure. An open critical finding with no remediation plan is a supervisory concern in its own right.
The executive summary section carries particular weight because CBUAE supervisors review materials at board and senior management level. The summary must translate technical severity into business risk in plain language. A finding rated CVSS 9.1 with no business context does not communicate risk to the audience that is asked to act on it. The access control findings that most often surface in financial-sector applications are covered in how to test authorisation in a web application, role by role.
How DESC governs web security testing in Dubai government systems
DESC sets the security baseline for Dubai government entities and their technology suppliers. Its control framework classifies systems by sensitivity and ties testing requirements to that classification: a system handling confidential government data has a higher bar than a public-facing information portal.
For web applications, DESC expects testing to be conducted before any internet-facing system goes live and again after a material change. The report must map findings to DESC control references where they apply, and high-severity findings must be closed before go-live. A finding left open at deployment without a documented risk acceptance fails the control.
Suppliers contracting with Dubai government entities often find the procurement contract requires a pentest report as part of delivery. That means testing must be planned within the development timeline, not commissioned after a system is already live. What a web application pentest covers, and what it does not sets out the scope boundaries that need to be agreed at that stage.
Report sections that survive a regulatory review
A web application pentest report written for a remediation team will not survive a regulatory review. The audience differs, the questions differ, and the evidence chain a regulator follows is not the one a developer follows.
The scope section must name the application, the URLs and endpoints tested, the test window, the tester's name and the authorisation document reference. A report that says 'tested the production environment' without naming which endpoints were included cannot be verified against a system boundary. The web application pentest engagement produces a scope statement at kick-off; it belongs verbatim in the final report.
Each finding must carry: a unique identifier, the WSTG test category and test ID, a CVSS base score with the vector string, reproduction steps that another tester could follow, and a remediation recommendation. The reproduction step section is what distinguishes a credible finding from a scan output, and a regulator checking finding quality looks at this section first.
The remediation tracking section is the most commonly missing piece. It must list each finding, its remediation status, the target or actual closure date, the person responsible, and, for closed findings, a reference to the retest that confirmed the closure. What your monitoring should catch during a web app pentest explains the detection side of a live test; the evidence chain runs through the report structure as well.
Executive summary
Risk posture, business impact at board level
Scope and boundaries
Systems, exclusions, test dates, authorisation reference
Technical findings
WSTG reference, CVSS score, reproduction steps
Control mapping
Framework control per finding, risk acceptance where applicable
Remediation and retest
Closure dates, owner, retest confirmation evidence
Remediation records and the follow-up test
A finding marked closed in the report but with no retest evidence does not satisfy a regulatory requirement. The question a regulator asks is not whether the developer says the fix is in place. It is whether an independent test confirmed it. That distinction is why a retest is a deliverable, not an extra step.
CBUAE and ADHICS both treat the testing cycle as including verification of remediation. For DESC, the control is that high-severity findings are closed before go-live; the evidence of closure is a retest result. The OWASP Application Security Verification Standard provides verification requirements that a retest should check, and citing these gives the report a defensible methodology reference.
Risk acceptances for findings that will not be remediated within the testing cycle need the same documentation rigour as closed findings. The acceptance must name the finding, state the residual risk in business terms, identify the person who accepted it at the right authority level, and carry a review date. An undocumented open finding is not a risk acceptance; it is an unmanaged exposure.
For business logic flaws, remediation is often a design change rather than a patch. The retest must demonstrate the specific flow that the original finding exploited, not just that the application loads without errors.
Web application testing as regulatory evidence in the UAE
In the UAE, web application security testing is not a discretionary practice for regulated entities. CBUAE binds every licensed bank, exchange house and payment service provider, and its technology risk guidance treats internet-facing applications as a primary attack surface that must be tested on a defined cycle. Banks operating in Dubai and Abu Dhabi are both subject to this requirement, and a supervisory review can ask for the report at any time.
DESC operates across Dubai government entities and their technology suppliers, which extends the testing requirement to any company selling web-based services into the Dubai public sector. For Abu Dhabi, ADHICS sets the standard for health information systems, and any web portal handling patient data is in scope for testing and reporting. The NESA Information Assurance Regulation covers federal entities across both emirates and requires security testing to be integrated into the entity's security management programme.
For a business operating in Dubai Silicon Oasis, DIFC, or any other free zone, the regulator governing the data the application handles sets the testing standard, not the licence type. A free-zone company processing payment data is in CBUAE scope; one operating under a Dubai government health contract is in DESC and potentially ADHICS scope. Knowing which regime applies before commissioning a web application pentest is part of scoping the engagement correctly.
Frequently asked questions
What does a UAE regulator mean by evidence of web application security testing?
A regulator expects a formal pentest report that names the scope tested, records findings with CVSS scores and reproduction steps, maps findings to framework controls, and includes a remediation tracking section with closure dates and retest confirmation. A scan output or a one-page summary does not meet this standard.
How often do UAE regulations require a web application pentest?
CBUAE guidance covers internet-facing applications on a regular cycle, with annual testing as the typical interval and testing required after material changes. DESC requires testing before go-live and on significant change. ADHICS and NESA both use a risk-based frequency aligned to the system's data sensitivity, defined in the entity's security plan.
Does a DESC supplier have to provide a web application pentest report?
Yes, in most cases. DESC requirements extend to technology suppliers contracting with Dubai government entities. If the web application handles government data or provides a service to a Dubai government entity, the procurement contract will typically require a pentest report as a delivery condition. The scope covers the application the government entity uses, not the supplier's internal estate.
What CVSS threshold do UAE regulators treat as requiring immediate remediation?
CBUAE guidance treats critical findings as requiring a named remediation plan or formal risk acceptance at board level before supervisory review. DESC applies a similar standard for high-severity findings before a system goes live. The CVSS score alone is not enough; the report must translate the score into a business impact statement for the executive audience that acts on it.
How does a web application pentest report differ from a vulnerability scan?
A vulnerability scan enumerates known weaknesses automatically and reports tool output. A web application pentest applies manual testing to business-specific attack paths, including authorisation flaws, business logic failures and session handling weaknesses that no scanner detects. UAE regulators accept a pentest report as evidence of testing; a scan report alone is not a substitute.
What should a risk acceptance for an open finding contain?
A valid risk acceptance must name the finding by its report identifier, state the residual risk in business terms, identify the person accepting it and confirm they hold the appropriate authority, set a review date, and be countersigned where the regulator requires board-level approval. An undocumented open finding is not a risk acceptance.
Does ADHICS require web application testing for healthcare portals in Abu Dhabi?
Yes. ADHICS applies to health information systems and their operators, which includes patient-facing web portals and internal clinical applications. Testing must demonstrate coverage of the PHI data boundary, and the report must include finding severity translated into risk to patient data confidentiality. The ADHICS framework is published through the Department of Health Abu Dhabi.
How does a web application pentest report support UAE NESA compliance?
The UAE Information Assurance Regulation requires federal entities to conduct security testing as part of their security management programme. The pentest report must reference the control identifiers in the IAR that the tested application falls under, and open findings must be tracked in the entity's risk register with a remediation or acceptance status. A report without control mapping does not satisfy the evidence requirement.
What is the difference between a UAE regulatory review and an independent audit?
A regulatory review is a supervisory check by CBUAE, DESC or another authority on whether the entity's security controls meet the prescribed standard. An independent audit is a third-party assessment against a framework such as ISO 27001 or the IAR. Both may ask for the pentest report, but a regulatory review carries enforcement consequences that an audit result alone does not.
