There is no single CBUAE IT regulation. That is the first thing to understand.
Central Bank technology and information security obligations sit in different regulations depending on what you are licensed as, so the first question is never what the rules say, it is which rules apply to you. We map that against the Rulebook, then assess you against the articles that actually bind you.
- By licence typeObligations differ by what you are
- UAE IA StandardsThe floor for payment providers
- Independent auditA named function, not a task
- Rulebook citedEvery claim to an article
Eight obligations, quoted from the articles that impose them.
First, establish which regulation binds you
Article 13 of the Retail Payment Services and Card Schemes Regulation, circular C 15/2021 and in force since June 2021, applies to Payment Service Providers. Article 31 of the Open Finance Regulation, circular C 03/2025 issued in July 2025, applies to Open Finance Providers and the API Hub. Banks sit under the Risk Management Regulation and its standards. These are different obligations. Establishing which apply to your licence is the whole foundation, and it is skipped surprisingly often.
The UAE Information Assurance Standards as a minimum floor
For Payment Service Providers the Rulebook is unambiguous: they shall apply and meet at a minimum the UAE Information Assurance Standards, as amended from time to time. That single sentence turns a national standard into a licensing obligation, and it means a payment provider assessing itself only against generic best practice is measuring against the wrong benchmark. If you already hold national standard alignment, a substantial share of this is done.
Three named functions, one of which must be independent
Both Article 13 and Article 31 require IT governance including an effective IT function, a robust technology risk management function, and an independent technology audit function. That third one is the requirement organisations most often fail on, because technology audit is being performed by the same team that runs technology. Independence is stated in the text, and an examiner will look for it structurally rather than as a claim.
Board-level accountability, stated explicitly
Both articles place responsibility on the Board, or a committee designated by the Board, for ensuring a sound and robust risk management framework is established and maintained for technology risks. This is not delegable to the IT function by implication. What an examiner looks for is evidence: minutes, papers, decisions taken, and a framework that shows signs of having been reviewed by people who are accountable for it.
Privileged and emergency access, in ten specific controls
Article 13 lists them individually, and they are testable rather than aspirational: change default passwords, enforce strong password control, restrict the number of privileged users, control remote privileged access, grant only strictly necessary authority, obtain formal senior approval before release, log preserve and monitor privileged activity including peer review of logs, prohibit sharing of privileged accounts, safeguard the credentials themselves, and change them immediately on return. Shared administrator accounts fail this outright.
Security built in at design, including in Agile delivery
Security requirements must be defined in the early stage of system development or acquisition as part of business requirements, and Article 13 addresses Agile explicitly: providers using Agile methods to accelerate development must incorporate adequate security practices so software is not compromised at any stage. Where you develop or provide an API, safeguards are required for the interaction and exchange of data between applications.
A threshold that changes what applies to you
Article 13 sets specific additional requirements for a Payment Service Provider whose monthly average value of payment transactions reaches ten million dirhams or above, including clearly assigning overall responsibility for network management to individuals equipped with the expertise to fulfil it, with network standards, design, diagrams and operating procedures formally documented, kept current, communicated and reviewed periodically. Knowing which side of that line you are on matters.
A cyber incident response plan that addresses real scenarios
Both articles require a cyber incident response and management plan able to swiftly isolate and neutralise a threat and resume affected services, describing procedures for plausible cyber threat scenarios. The operative word is plausible. A generic plan that could belong to any organisation does not meet this, and the difference is visible immediately to anyone who reads it properly.
If an adviser cannot cite the article, they are guessing.
There is a lot of confident content about Central Bank cyber requirements that does not correspond to anything in the Rulebook. Some of it is plausible, some is imported from other jurisdictions, and it is easy to build a programme against requirements nobody actually imposed.
- The Rulebook is public. Every requirement carries a circular reference, an effective date, a status and a clear statement of which entities it applies to. Any adviser telling you the Central Bank requires something should be able to name the article. Ask. It is a fast and entirely fair test, and you should apply it to us.
- The most common category of error is jurisdictional. DFSA governs firms in DIFC and FSRA governs firms in ADGM, and neither is the Central Bank. Requirements get quoted across these boundaries constantly. If you are onshore and CBUAE-licensed, DIFC guidance does not bind you, and the reverse is equally true.
- The second most common is applying requirements from the wrong regulation. Article 13 sits in the Retail Payment Services and Card Schemes Regulation and applies to Payment Service Providers. It is not a general banking rule, and treating it as one means a bank builds against the wrong text while a payment provider may miss the UAE Information Assurance Standards obligation that genuinely applies to it.
- We will not quote penalty figures, notification deadlines or testing mandates that we have not read in the applicable regulation for your licence. Where an obligation exists we will show you the article. Where we have not verified it for your specific licence type, we will say that plainly and go and check rather than fill the gap.
Four commitments for an area where confident wrong answers are common.
Every requirement we assert carries an article reference
Circular number, effective date, and the entities the article applies to. If we cannot point you at the text, we tell you we have not verified it for your licence rather than filling the gap with something plausible. You should hold every adviser in this area to that, and it is a quick test to apply.
We scope by licence before we assess anything
Which Central Bank regulations apply to what you actually are, and equally which do not. This prevents the two failure modes we see most: building against requirements that were never yours, and missing a specific obligation such as the UAE Information Assurance Standards floor that applies to payment providers and to nobody else in the same words.
We reuse what you already hold
Firms in this sector frequently have ISO 27001, national standard alignment, or work done for a card scheme or a partner bank. Because Article 13 sets the UAE Information Assurance Standards as its floor for payment providers, existing national standard work maps across directly. We establish that overlap before proposing anything new, since duplicated control sets are the largest avoidable cost here.
We can be the independent technology audit function, or help you build it
The articles require an independent technology audit function, and for a smaller regulated firm resourcing that internally is genuinely difficult. We can perform that role, with the important caveat that where we also deliver your technology we would not be independent of it and would say so. Independence that exists only on an organisation chart satisfies nobody.
Six situations we are brought into.
A payment service provider preparing for or holding a licence
Article 13 applies directly, including the requirement to meet at a minimum the UAE Information Assurance Standards, the three governance functions with an independent technology audit among them, and the ten named privileged access controls. For a firm approaching licensing this is a defined body of work with a defined text behind it, which makes it plannable rather than open-ended.
An open finance provider under the 2025 regulation
Article 31 of the Open Finance Regulation is recent, issued in July 2025, which means fewer firms have built against it and there is correspondingly less reliable guidance circulating. It carries the same governance structure as Article 13 and adds obligations around adhering to security requirements set by the API Hub, which is a dependency on somebody else that needs managing rather than assuming.
A bank working under the Risk Management Regulation
Banks sit under a different part of the Rulebook, with risk governance, the risk management function, information systems and internal reporting, and separate standards including operational risk. We map the specific articles applying to your institution rather than importing the payment services text, because the two are genuinely different and conflating them is the error this page exists to prevent.
A firm that has received a supervisory question
Something specific has been asked and the honest internal answer is that nobody is certain what the requirement actually says. The immediate work is establishing the applicable article and the current position against it, precisely and without overstating. Answering a regulator optimistically is a substantially worse outcome than answering slowly.
A firm needing an independent technology audit function
The requirement is explicit in both articles and it is structurally awkward for a smaller institution, because the people who understand the technology are the people who run it. This is a defined, recurring engagement rather than a project, and it needs setting up so the independence is real and evidenced rather than asserted on a chart.
A technology vendor serving CBUAE-regulated clients
You may not be licensed yourself, and your clients will still push their obligations down to you contractually, particularly around access control, incident response and audit rights. Understanding what the articles actually require of them tells you what you will be asked to evidence, which is far better established before a contract is signed than during a client audit.
How CBUAE-regulated firms actually approach this.
| Feature | Mapped to the applicable articles | Working from generic guidance | Not yet addressed |
|---|---|---|---|
Applicable regulations identified by licence | Assumed | ||
Requirements traceable to a cited article | |||
Independent technology audit function exists | Rarely | ||
Board engagement evidenced | Nominal | ||
UAE IA Standards alignment where required | By coincidence | ||
Privileged account sharing eliminated | Partially | ||
Incident plan addresses your own scenarios | Generic template | ||
Effort spent on requirements that do not apply | None | Substantial | None |
Could evidence compliance on request | Yes | With difficulty | No |
Cost of correcting later | Low | High | Highest |
The technology risk provisions we work with most often.
| Provision | Applies to | Reference | |
|---|---|---|---|
| Technology Risk and Information Security | Payment Service Providers | Article 13, Retail Payment Services and Card Schemes Regulation | C 15/2021, in force from 6 June 2021 |
| Technology Risk and Information Security | Open Finance Providers and the API Hub | Article 31, Open Finance Regulation, Part III | C 03/2025, issued 10 July 2025 |
| Risk governance and risk management function | Banks | Risk Management Regulation and its Standards | Banking section of the Rulebook |
| UAE Information Assurance Standards as a minimum | Payment Service Providers | Stated directly in Article 13 | C 15/2021 |
| Independent technology audit function | PSPs, Open Finance Providers, API Hub | Articles 13 and 31 | C 15/2021 and C 03/2025 |
| Board or designated committee accountability | PSPs, Open Finance Providers, API Hub | Articles 13 and 31 | C 15/2021 and C 03/2025 |
| Ten privileged and emergency ID controls | Payment Service Providers | Article 13 | C 15/2021 |
| Network management responsibility assigned | PSPs at or above ten million dirhams monthly average | Article 13 | C 15/2021 |
| Cyber incident response and management plan | PSPs, Open Finance Providers, API Hub | Articles 13 and 31 | C 15/2021 and C 03/2025 |
| Best practice guidance | Payment Service Providers | Annex II, consultation encouraged | C 15/2021 |
Five stages, and the first one is the one people skip.
- 1
Map your licence to the applicable articles
What you are licensed as, which Central Bank regulations apply, which articles within them address technology and information security, and where thresholds such as the ten million dirham monthly average change what is required. The output is a short, referenced list of what actually binds you, and it is frequently different from what the organisation assumed.
- 2
Assess against those articles specifically
A control-by-control assessment against the text that applies, not against a generic framework. For payment providers that includes measuring against the UAE Information Assurance Standards, because Article 13 sets them as the minimum. Findings are reported with the article reference attached so anybody can check them.
- 3
Close the governance gaps first
The independent technology audit function, the distinct technology risk management function, and evidenced Board or committee engagement. These are named explicitly in the articles, they are structural rather than technical, and they take longest to establish, so they start early rather than being left until the controls are tidy.
- 4
Remediate the control detail
Privileged and emergency access against the ten named controls, security requirements in the development lifecycle including Agile delivery, API safeguards where applicable, network management responsibilities where the threshold applies, and an incident response plan addressing scenarios plausible for your business rather than any business.
- 5
Evidence it, and keep it current
A referenced evidence pack mapping each obligation to what demonstrates it, so a supervisory question is answered from documents rather than from recollection. Then the ongoing work, including the independent technology audit function on a recurring basis, and a review whenever the Rulebook is updated, since articles carry amendment dates and change.
What CBUAE-regulated firms ask.
Fifteen checks against the articles quoted on this page.
Scope, which comes first
- What exactly are you licensed as, in Central Bank terms?The answer determines which articles bind you.
- Have you identified every regulation applying to that licence?Not just the one somebody mentioned in a meeting.
- If you are a Payment Service Provider, are you above ten million dirhams monthly average?Article 13 attaches additional requirements at that threshold.
- Do you hold or provide an API?Triggers specific safeguard requirements in both articles.
- Are you confusing CBUAE requirements with DFSA or FSRA ones?Different regulators, different jurisdictions, common mistake.
Governance the articles name
- Is there an independent technology audit function?Independent of the function that runs technology. Stated in the text.
- Is there a distinct technology risk management function?Named separately from the IT function itself.
- Has the Board or its designated committee actually engaged?Evidenced in minutes and decisions, not asserted.
- Does your framework document its own proportionality?Fit for purpose and commensurate with nature, size and complexity.
- For PSPs, are you measuring against the UAE Information Assurance Standards?The Rulebook sets them as the minimum, not as an option.
The control detail
- Are privileged accounts ever shared?Article 13 prohibits sharing them. This one is binary.
- Is privileged activity logged, preserved and reviewed, including peer review?Named specifically in the article.
- Do emergency IDs require formal senior approval before release?And are passwords changed immediately on return.
- Are security requirements defined at the design stage, including in Agile work?Article 13 addresses Agile delivery explicitly.
- Does your incident plan address plausible scenarios specific to you?A generic plan does not meet the wording.
The pages around this one.
NESA and UAE Information Assurance compliance
The national standards that Article 13 sets as the minimum for payment service providers, and how alignment to them maps into the Central Bank obligation.
DFSA IT compliance
The DIFC equivalent for firms in that jurisdiction, which is a different regulator with different requirements and is frequently confused with this one.
IT audit services in Dubai
The wider audit practice, including how an independent technology audit function is structured and evidenced over time.
Start by establishing which articles actually bind you.
That answer is free, it is public, and it frequently differs from what a firm has been working to. We will map your licence against the Rulebook and point you at the relevant text so you can read it yourself before deciding whether you need any help with the rest.
Related Services
Explore more solutions that work great with this service
NESA / IA Compliance
UAE Information Assurance Standards compliance
DFSA IT Compliance
IT compliance for DFSA-licensed firms in the DIFC
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
ADGM IT Compliance
IT compliance for ADGM-licensed firms under FSRA
ISO 27001 Certification UAE
The 2022 edition, and whether you should certify at all
PCI DSS Compliance UAE
Scope reduction first, then the controls that remain
Virtual CISO Dubai
Security governance and accountability, not more tools
Managed Security Services
MSS on Microsoft Defender XDR and Sentinel