Security Testing for UAE Government Entities

A UAE government or public sector entity is expected to run independent security testing that lines up with the DESC Information Security Regulation (ISR) for Dubai government bodies, the UAE Information Assurance Standards (IAS, historically published by NESA), and the critical information infrastructure protection (CIIP) guidance for the systems a sector relies on.

DESC ISR

Dubai government entities and their service providers test periodically and after any significant change, and track findings to closure. The engagement gives an assessor the scope rationale, the findings with their owners and the retest evidence, not a one-line pass.

UAE IAS

The national Information Assurance Standards set the controls an entity has to implement and evidence. We scope testing so it maps to the control families that independent assessment is meant to demonstrate, and we tell you where a control is a process matter that no test can prove.

CIIP guidance

Where an entity runs critical information infrastructure, the protection guidance for that sector asks more of segmentation, access and monitoring. We scope those systems on their own rather than fold them into the wider estate.

A citizen e-services pentest covers authorisation at the object and function level, how sessions and identity are handled, and the limits that stop one citizen reaching another's records, applications or documents. In the public sector that is where the serious findings sit.

The most common high-severity finding we report on government portals is broken object level authorisation: change an identifier in a request and the response returns an application, a document or a record that belongs to someone else. No scanner finds it, so we test it by hand, per role and per resource.

We scope the portal, the national identity integration and the services behind them separately. A control enforced at the front end is not the same as one enforced at the service, and an attacker goes straight for the service.

Yes. We agree testing against live services in writing first, exclude denial-of-service techniques by default, and set the testing window, the excluded techniques and a deconfliction contact in the rules of engagement before any work starts. Nothing lands as a surprise on the people who keep the service running.

Where a test case would create real records or touch a real citizen transaction, we run it against a production-equivalent environment instead. If that environment differs from production in any way that matters, the report says so, because a test of a different configuration is a test of a different system.

A named contact on each side handles the case where a tester finds an active compromise rather than a weakness. We settle that path before day one, not in the middle of the incident.

A UAE government entity should test anything internet-facing at least once a year, before a significant release reaches production, and after any material change to authentication, authorisation or the way citizen data is handled. Where a regulator names an interval, treat it as a floor, not the whole schedule.

A new citizen service, a new inter-entity integration or a rewritten login are the changes most likely to introduce the flaws that matter. Each one is a reason to test the affected area rather than wait for the annual cycle.

We run the same phases on every engagement, so two reports a year apart line up and you can see what changed instead of reading two unrelated documents.

We treat national identity and citizen data as the most sensitive assets in scope. The testing proves an exposure exists without pulling the records behind it, and the rules of engagement state what a tester may read, what must never leave the environment, and how any evidence captured is kept and destroyed.

Where a single record or a redacted sample proves the point, that is what the report carries. We do not pull a dataset to make a point, and the retention and destruction terms are written into the engagement rather than left to assumption.

Most government entities start with a web and API pentest of their citizen portals and inter-entity integrations, add a mobile app pentest for the citizen apps, and run an internal infrastructure pentest across the network and its segmentation. An objective-based Red Team and a social engineering test come once the basics are covered.

The right mix depends on what you are protecting and what a regulator has asked for. We scope it with you rather than sell a fixed bundle, and we tell you where something is not worth buying yet.

You get the full evidence chain: the scope, the written authorisation, every finding with its severity and a named owner, the order to fix them in, and a retest with evidence that each one is closed. The retest is priced at scoping, not sold separately after the report lands.

Findings are mapped to MITRE ATT&CK, so each one reads as a technique an attacker would use rather than a line of scanner output. Where a procurement process needs it, we provide an attestation of the testing that states what was tested and when.