Learn
The UAE Information Assurance Regulation asks a designated entity for three things: implement every control it marks Always Applicable, run a documented risk assessment that decides which of the remaining controls apply to you, and justify in writing every control you leave out. Everything else in the document, the families, the priority levels, the performance indicators, exists to structure those three obligations.
That structure is what makes the Regulation different from a checklist. It does not hand you a fixed list of things to do. It hands you a catalogue, a rule for selecting from it, and a requirement to defend your selection. An entity that implements 60 controls with a defensible risk assessment is in a better position than one that implements 120 without.
| What the Regulation sets | Detail | Where it says so |
|---|---|---|
| Control families | 15 in total: six management families, M1 to M6, and nine technical families, T1 to T9. | Section 5.2 |
| Hierarchy | Family, then sub-family, then control, then sub-control. Sub-controls carry mandatory implementation requirements. | Section 5.1 |
| Always Applicable controls | 34 management controls that every entity implements regardless of its risk assessment. Omitting one is non-conformity. | Annex A |
| Priority levels | Four levels, P1 to P4, holding 39, 69, 35 and 45 controls respectively. | Annex B, Table 6 |
| Applicability rule | Every control is applicable until a risk assessment says otherwise, with justification submitted to the authority. | Section 3.3 |
What does the UAE IA Regulation actually require?
Four obligations, in the order the document builds them.
1. Implement the Always Applicable controls
Annex A names a set of controls that represent, in the Regulation's words, requirements for instituting foundational information assurance capabilities. They are all management controls, and they must be implemented by every relevant entity regardless of what its risk assessment concludes. There are 34 of them. Omission of any one constitutes non-conformity, and the same is true of their sub-controls: for an Always Applicable control, the entity implements all sub-controls, with no justified exception route.
2. Run the risk assessment that decides everything else
Before the assessment, an entity is required to consider all security controls applicable. The assessment is what narrows that. It is not optional and it is not a formality: in the absence of an entity risk assessment, every control in the document is deemed applicable and therefore mandatory. Skipping the assessment does not reduce your obligations, it maximises them.
3. Justify every exclusion
A control excluded on the basis of the risk assessment needs adequate justification submitted to the authority. Sub-controls have a slightly softer rule: an entity may decide not to implement a sub-control of a risk-selected control, or to implement it differently, provided the deviation is justified and evidenced, with the associated risks accepted by accountable persons or authorizing entities. Both routes end in the same place, which is a named person signing something.
4. Measure with performance indicators
Each family and sub-family carries a performance indicator. Entities are required to use performance indicators to measure the quality and effectiveness of the controls they implement. They may deviate from the suggested ones, but only by giving a reason and specifying the replacements. This is the part most programmes skip, and it is an explicit element of the compliance monitoring scheme rather than a nice-to-have.
How do the four priority levels work?
Prioritisation is the Regulation's answer to the problem of where to start. Controls are grouped into four levels, P1 to P4 in order of importance, based on their relative impact in mitigating common threats and building foundational capabilities. Annex B sets out the distribution: 39 controls at P1, 69 at P2, 35 at P3 and 45 at P4.
The levels are not severity ratings. They are a sequencing instruction. All applicable controls across all four levels are mandatory for critical entities; the priority tells you the order. Entities are required to begin with P1, and they may promote or demote the suggested priority of a control based on their own risk assessment, with one exception: a P1 control, if applicable, may be augmented but never reduced. That asymmetry is the only place the document takes discretion away from the entity's own risk work.
What is in the 15 control families?
Six management families cover the programme. M1 Strategy and Planning asks for an information security strategy, an operating model and per-service security plans. M2 Information Security Risk Management is the engine described above. M3 Awareness and Training and M4 Human Resources Security cover people before, during and after employment. M5 Compliance covers legal requirements, policies and technical standards. M6 Performance Evaluation and Improvement closes the loop.
Nine technical families cover the estate: T1 Asset Management, T2 Physical and Environmental Security, T3 Operations Management, T4 Communications, T5 Access Control, T6 Third-Party Security, T7 Information Systems Acquisition, Development and Maintenance, T8 Information Security Incident Management, and T9 Information Systems Continuity Management.
If that reads like a familiar shape, it should. The Regulation states that its implementation guidance derives from ISO/IEC 27001, 27002, 27005, 27010 and 27032, NIST Special Publication 800-53 Revision 4, the Abu Dhabi Information Security Standards, and the SANS 20 Critical Security Controls. An entity holding ISO 27001 has already paid for a large part of the technical families. What it has not paid for is the applicability and justification machinery, which is where UAE IA diverges.
Who has to comply?
The Regulation applies to critical entities, and it is the authority that designates them, as provided for by the UAE Critical Information Infrastructure Protection Policy. Designation is therefore not something you self-assess your way into or out of. If your organisation has been designated, the Regulation applies to the use, processing, storage and transmission of information and to the systems and processes used for those purposes, whether that information is in physical or electronic form and whether it is owned, leased or otherwise in your custody.
The Regulation sits inside a wider set of national documents: the National Information Assurance Framework, the Critical Information Infrastructure Protection Policy that drives designation, the National Cyber Risk Management Framework, and the National Cyber Information Sharing Policy. Requirements from the last of those are embedded in the control set rather than kept separate, which is why information sharing obligations turn up inside your control catalogue.
What the other results get wrong
Three things recur across the published summaries.
The first is presenting a control count as the requirement. It is not. Two designated entities of the same size can owe very different numbers of controls and both be compliant, because the applicable set is an output of the risk assessment, not an input. The number that is fixed is the Always Applicable set.
The second is version confusion. Several vendor summaries describe a newer edition of the standard with a different control count. We have not been able to confirm the content of any such edition against a primary source, so nothing in this guide relies on one; everything above is the Regulation as published. Before you scope a programme, confirm with the authority that designated you which version binds you, because the answer changes your control catalogue and nothing else in your plan will be right if that is wrong.
The third is treating the implementation guidance as requirements. The Regulation is explicit that automation guidance, threat and vulnerability descriptions, and implementation guidance for controls are provided for information purposes only and may be implemented as the entity prefers, without further explanation or justification. Auditing yourself against guidance text inflates the programme for no compliance benefit.
Where does your entity stand?
Fill this in. Any row you cannot complete is the next piece of work, in the order shown.
| Question | Your answer | Why it matters |
|---|---|---|
| Have you been designated as a critical entity, and by which instrument? | Designation is the trigger. Without it you are choosing to adopt, not required to. | |
| Which version of the standard did the authority tell you applies? | It sets your control catalogue. Do not infer it from a vendor summary. | |
| Can you produce a current, dated entity risk assessment? | Without one, every control in the document is applicable and mandatory. | |
| Is every excluded control backed by a written, accepted justification? | Exclusions without justification are the fastest route to a non-conformity. | |
| Are all Always Applicable controls implemented, sub-controls included? | There is no justified exception route for these, at control or sub-control level. | |
| Which performance indicators do you actually report against? | They are an element of the compliance monitoring scheme, not optional colour. |
Budgeting the work is a separate question, and the answer depends on which of those rows is blank rather than on your headcount. Our guide to what UAE IA compliance actually costs takes it mandate by mandate. If you need a baseline first, the free compliance check will tell you which rows you are going to struggle with, and the UAE IA framework page shows how the control set is held in one place.
Frequently asked questions
How many controls does the UAE IA Regulation contain?
Annex B of the published Regulation distributes the controls across four priority levels: 39 at P1, 69 at P2, 35 at P3 and 45 at P4. Those four bands are the whole catalogue, and the catalogue is not the size of your obligation: the risk assessment determines that.
Which controls can we never exclude?
The Always Applicable set in Annex A: 34 management controls, together with all of their sub-controls. Everything else is selected by the risk assessment and can be excluded with an accepted, evidenced justification.
Do we have to implement P1 controls first?
Yes, where they are applicable. Entities are required to begin with P1 given its relative impact, and a P1 control may be augmented but never demoted, unlike the other three levels.
Does ISO 27001 cover this?
Partly. The Regulation draws its guidance from the ISO 27000 series among other sources, so a mature ISO 27001 programme covers a lot of the technical families. It does not cover designation, the Always Applicable set, the justification trail or the performance indicator obligation.
Do policies and evidence have to be in Arabic?
That depends on what the regulator asks for rather than on the Regulation's control text. Our guide to bilingual policies and evidence for Gulf regulators sets out what usually has to be in Arabic and what can stay in English, and the same question comes up under SAMA CSF next door.
Primary sources
Every figure and rule above comes from the UAE Information Assurance Regulation, Version 1.1, March 2020, specifically section 2.1 on scope, 3.3 on applicability, 3.4 on prioritisation, Chapter 4 on compliance, 5.1 and 5.2 on control structure and families, Annex A on Always Applicable controls and Annex B, Table 6, on the priority distribution. The link is a public mirror of the authority-published text. Confirm the current version and your designation directly with the authority before relying on any of it for a programme decision.
