Regulation and reference
Four UAE regulators name security testing. They do not ask for the same thing, and buying the wrong shape of engagement is how organisations end up paying for it twice. No forms, no gates.
Worth separating from the regulation. These are the frameworks the engagement is built on. The Gulf regulations further down are the reason a UAE organisation needs one, which is a different question.
| Framework | Published by | What we take from it |
|---|---|---|
| MITRE ATT&CK | MITRE | The technique taxonomy. Every step of an engagement is recorded against it, which is what lets you compare this test to your last one and to your own detection coverage. |
| TIBER-EU | European Central Bank | The shape of an intelligence-led engagement: threat intelligence first, scenario second, execution third, and a structured closure phase with the defenders in the room. |
| Advanced Red Teaming (ART) | De Nederlandsche Bank | Published 2024, built on TIBER-EU and the Bank of England's CBEST, and aligned to the threat-led penetration testing regime under DORA. Modular, so scope and depth can follow maturity instead of a fixed template. |
| OWASP testing guides | OWASP | Coverage baselines per surface: WSTG for web, MASVS and MASTG for mobile, and the API and LLM top tens. They set the floor, not the ceiling. |
We are not accredited under TIBER-EU or ART, and we do not sell an engagement as a formal test under either. Both are run by their central banks with the regulator in the loop. What we take is the method.
Four regimes, and most organisations answer to exactly one. Find your row before reading any further.
| Regime | Issued by | Who it binds | What it asks for |
|---|---|---|---|
| CBUAE | Central Bank of the UAE | Banks, finance companies, payment service providers and stored-value facilities it licenses. | Independent penetration testing of critical and internet-facing systems at least annually, vulnerability scanning more often than that, and evidence that findings were actually closed. Larger institutions are increasingly asked for intelligence-led adversary simulation on top. |
| ISR | Dubai Electronic Security Center (DESC) | Dubai government and semi-government entities, and the suppliers who hold their data or connect to their networks. | Assessment on a cycle set by how critical the system is. Note that since 2024, providers delivering penetration testing or incident response to Dubai government entities must themselves be accredited under DESC's Cyber Force programme. We are not Cyber Force accredited. If your engagement needs a provider who is, say so at the first conversation and we will tell you plainly that we are not the right firm for it. |
| ADHICS | Department of Health, Abu Dhabi | Healthcare providers, payers and health information exchanges in the Emirate of Abu Dhabi. | A control catalogue covering clinical systems and patient data. Testing evidences the technical control families, not a single named clause. |
| UAE IAS | Signals Intelligence Agency, formerly NESA | Federal entities and operators designated as critical national infrastructure. | A controls framework, not a testing mandate. Several of its families can only really be evidenced by testing: that segmentation holds, that privileged access is constrained in practice, and that monitoring produces something a person acts on. |
You will still see NESA named in tender documents. NESA is not a separate standard: it is the authority that wrote the UAE IAS, and it was renamed the Signals Intelligence Agency. If a tender says NESA, it means the IAS, and the practical move is to confirm with the issuing entity which version governs before scoping anything.
They overlap heavily and organisations routinely buy the same work twice because nobody mapped them first. Agree what evidence every regime in scope needs before the engagement is scoped, not after the report lands.
| Engagement | CBUAE | ISR | ADHICS | UAE IAS | What it actually gives you |
|---|---|---|---|---|---|
| Scoped penetration test | The baseline | Yes | Yes | Per control | Tells you what is wrong with a defined system, in an order your engineers can work through. |
| Assumed breach | Supports | Yes, for supplier reach | Often the best fit | Yes | Shows how far an intruder gets once inside, without spending the budget on the noisy way in. |
| Purple Team session | Supports | Supports | Supports | Evidences controls directly | Leaves detection content your own team wrote, which is the one output that keeps working after the invoice. |
| Full Red Team | Expected of larger institutions | Case by case | Rarely the first buy | Case by case | Answers whether anyone would notice. Wasted on an estate with nothing watching yet. |
The failures are specific to the regime, and they repeat. This is what we see land badly at examination.
An annual test on the same narrow scope every year, so the report looks clean while whole systems have never been touched. The examiner asks how the scope was chosen, not what was found, and there is nothing written down. Keep the scope rationale, not just the result.
Supplier scope. An entity tests its own estate thoroughly and never tests the connection its supplier holds into it, which is the path that actually gets used. If you connect to a Dubai government network, assume you are in scope and check whether your provider needs Cyber Force accreditation.
Testing the hospital information system and stopping there, while imaging, pharmacy and the integration layer between them go untested for years. Patient data moves through the joins, and the joins are usually where the authorisation is weakest.
Answering a controls framework with a vulnerability scan. The families that matter here are about whether segmentation and privileged access hold in practice, and a scan cannot evidence either. This is usually where a Purple Team session is the better buy than a Red Team one.
Examiners across all five want the same short chain. Keep these six and the framework question mostly answers itself.
Why these systems and not others. An examiner asks this first, and 'it is what we tested last year' is not an answer.
Signed at a level that could actually authorise it, naming the window and the people who approved it.
Each finding carrying a named owner and a date. A findings list with no owners is a document, not a control.
What changed, when, and who signed it off.
The single weakest link in most files. A finding marked resolved with nothing behind it converts to an open finding under examination.
Findings mapped to MITRE ATT&CK so this year is comparable to last year. Without a shared taxonomy, 'are we improving' has no answer.
Red Team vocabulary is used loosely across the industry. This is what each term means when we use it, so a scoping call starts from the same definitions.
| Assumed breach | An engagement that opens from a foothold granted in advance instead of one we have to earn. The budget goes on what an attacker does after getting in, which is where most estates actually fail. |
|---|---|
| Attack path | The ordered chain of steps that carried us from initial access to the objective. Delivered as a graph, not a list, because the order is the finding. |
| Authorization letter | The signed document that makes the engagement lawful, naming the scope, the window and the people who approved it. Carried by every operator. |
| C2 | Command and control. The channel a foothold uses to reach its operator. Whether your controls see it, and how long they take to, is one of the things an engagement measures. |
| Crown jewel | The system or data whose loss would genuinely hurt. Named by you at scoping, and the thing the engagement is pointed at. |
| Deconfliction | The agreed channel for answering one question quickly: is this us, or is this a real intrusion. Held by the white team for the duration of the engagement. |
| Initial access | The first foothold inside the estate. A pretext someone accepted, an exposed service, a supplier path. |
| Lateral movement | Moving between systems once inside, usually with credentials or trust relationships instead of exploits. It rarely looks like an attack to tooling. |
| Objective-based | Scoped around reaching a named outcome instead of enumerating a system. The difference between proving an estate can be traversed and listing what is wrong with it. |
| Persistence | Keeping access across reboots, credential changes and cleanup. Its detection is a separate question from the detection of initial access. |
| Pretext | The story that makes a social engineering approach plausible to the person receiving it. Agreed in advance and kept within the safety rules. |
| Privilege escalation | Gaining rights beyond those the foothold started with, either on one host or across the domain. |
| Purple Team | Red and blue working the same timeline together, with detection tooling open, so each technique ends as a detection your team keeps. |
| Retest | A scoped re-run after remediation, confirming the specific findings are closed instead of re-running the whole engagement. |
| Rules of engagement | The written limits: what is in scope, what is off limits, the hours, the techniques excluded, and what happens if something breaks. |
| TTPs | Tactics, techniques and procedures. The vocabulary MITRE ATT&CK uses, and the vocabulary the deliverable is written in. |
| White team | The small group on your side who know the engagement is running. They hold the authorization letter and the deconfliction channel, and they are deliberately not the people being tested. |
Tell us the objective you want tested. We reply with a scope, a timeline and a quote.
