UAE software supply chain and AI security rules: a 90-day plan

In the United Arab Emirates, the software you build and buy is governed by a stack of rules, not one law: the federal UAE Information Assurance Regulation for designated critical entities, the Central Bank's new Operational Risk Management Regulation for financial institutions (in force since 14 September 2026), Abu Dhabi's ADHICS for anyone touching health data, and Dubai's Information Security Regulation for Dubai Government entities. Each one asks you to know what is inside your systems, control your suppliers, fix vulnerabilities on a plan and report incidents on a clock. This guide maps each regime to the evidence a supervisor asks for and gives a 30/60/90-day plan that works with the tools you already run.

This is not legal advice. Where a rule is still unsettled, we say so and point you at the primary text.

Key takeaways

• Financial institutions have the tightest clocks. The Central Bank of the UAE (CBUAE) Operational Risk Management Regulation, Circular C 1/2026, effective 14 September 2026, requires notice of significant events within 4 hours, a summary report within 24 hours, and notice of any high-risk incident within 72 hours (Article 15). It also requires the Master System of Record to stay in the UAE (Article 8) and a Central Bank notice of non-objection before outsourcing anything that could significantly disrupt Critical Operations (Article 13).
• Health data in Abu Dhabi stays in the UAE. ADHICS V2 (Department of Health, effective August 2024) says health information and its copies, even encrypted or anonymised, must not be stored, processed or transferred outside the UAE without DoH approval, and cloud environments must be hosted in the UAE including backup and disaster recovery.
• Critical entities follow the UAE IA Regulation. Version 1.1 (March 2020) applies to entities designated under the UAE Critical Information Infrastructure Protection policy. Without a risk assessment, every control is mandatory. T7.7.1 (technical vulnerability management) is a top-priority P1 control and its guidance names a software inventory, with vendor and version, as the prerequisite.
• Supply chain controls are explicit. IA Regulation T7.6.5 (outsourced development) and T7.8 (supply chain management), and ADHICS SA 5 and SA 6, ask for secure coding clauses, source code review, right to audit and proof that delivered software has not been altered.
• AI is governed by principles, not a federal AI statute. The UAE Charter for the Development and Use of Artificial Intelligence sets out principles such as human oversight, transparency, data privacy and governance and accountability. Sector rules and data protection law do the enforcing.
• Safeguard capabilities covered here are all GA: SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV enrichment, reachability analysis, autonomous remediation (ships switched off, every category set to Manual), policies and gates, license compliance, CSAF and VEX upload, the Compliance and GRC suite, Trust Center, TPRM, AI-BOM discovery, AI Gateway, MCP Guardrail, agent identity, Zero AI mode, bring your own model, the local runner, and private VPC, on-prem and air-gapped deployment.

Who this applies to in the United Arab Emirates

Cyber and data rules in the UAE are set at three levels: federal, emirate and financial free zone, and most organisations sit under more than one.

None of these regimes regulate an overseas software vendor directly. They tell the bank, hospital, utility or government entity to push security requirements, audit rights and incident notification into supplier contracts, so if you sell software into the UAE, these clauses will arrive in your contract.

The rules, regulator by regulator

Every status below was checked against the regulator's own page or document on 25 and 26 October 2026. Where we could not reach a primary source, the regime is described more narrowly or left out, and we say so.

UAE Information Assurance Regulation (TDRA)

Status: in force, version 1.1 dated March 2020. The document on TDRA's site is titled "UAE Information Assurance Regulation, March 2020, Version 1.1". Many vendors and auditors still call it "NESA", after the authority that issued the earlier UAE Information Assurance Standards, and Safeguard's own docs use that name too. We could not confirm on a TDRA page whether a later version has replaced 1.1, so treat 1.1 as the current text until TDRA publishes otherwise.

Scope. Section 2.1 says the regulator "will designate the critical entities, as per the UAE CIIP Policy", and those entities must apply the regulation to the information they own, lease or control and to the systems that process it. Other entities may adopt it voluntarily.

How applicability works. Section 3.3 is the part most teams misread. Controls become mandatory through the entity's own risk assessment. An entity may exclude a control only with justification submitted to the regulator, and a set of "Always Applicable" controls (listed in Annex A) must be implemented whatever the risk assessment says. The sharpest line: in the absence of a risk assessment, all controls are deemed applicable and mandatory. Each control also carries a priority from P1 (highest) to P4 that tells you the order to implement it.

The controls that touch software and open source:

• T7.7.1 Control of Technical Vulnerabilities (P1). The entity must obtain and act on information about technical vulnerabilities, identify vulnerabilities in new systems before production, test for them throughout the development life cycle "preferably by the use of automated testing tools", and decide remediation with a cost-benefit view. The implementation guidance says a current and complete asset inventory, including software vendor and version numbers, is a prerequisite. That is a software bill of materials in everything but name.
• T7.6.5 Outsourced Software Development (P3). Define a secure coding policy and a QA process, put secure coding and audit rights into the development contract, and review source code for vulnerabilities or malicious code.
• T7.8 Supply Chain Management (T7.8.1 to T7.8.5, P4). A supply chain protection strategy, checks that every delivered product meets your security requirements, contractual compliance with your policy, audit rights over the supplier, supplier reviews, and reliable delivery. The stated performance indicator is the percentage of systems received and validated as genuine.
• T6 Third-Party Security. T6.2 covers service delivery monitoring and changes to third-party services; T6.3.1 requires security requirements for data in cloud environments, due diligence on processing and storage restrictions, communication of incidents at the cloud provider, and where possible a right to audit.
• T8 Information Security Incident Management. T8.2.1 requires an incident response plan and T8.2.2 a Computer Security Incident Response Team (both P2).

Dubai Information Security Regulation (DESC)

Status: in force for Dubai Government entities. DESC's Standards and Policies page says the ISR applies to all Dubai Government entities, is broken into thirteen domains grouped as Governance, Operation and Assurance, and that DESC maintains it under Dubai Law No. 11 of 2014. The first Dubai Government Information Security Regulation dates from 2012. Entities must assess which domains and controls apply to them.

The full ISR text is released on email request rather than published openly, and the public page does not state the current version number. Press reports describe a version 3.0; we could not confirm the version on DESC's own page, so check with DESC before quoting a version in a contract. The same page lists other DESC standards, including IoT and ICS (operational technology) security standards.

ADHICS V2 (Department of Health Abu Dhabi)

Status: in force. The standard's cover sheet gives document reference DOH/SD/ICSO/ADHICS/V2/2024, publication May 2024, effective August 2024, revision date May 2027. It applies to "any entity" in the Emirate of Abu Dhabi that generates, accesses, stores, uses, processes or transmits health information, explicitly including healthcare technology and service providers. Many ADHICS controls cite the matching UAE IA Regulation control (for example "UAE IAR Reference: T7.6.5" under SA 5), which makes it easy to run one evidence set for both.

The controls that matter most for software teams:

• SA 5 Outsourced Software Development. SA 5.1 requires that outsourced development follows secure engineering principles, that the entity holds sole custody of the source code and its backups, that contracts require compliance with industry secure coding practices and include a right to audit, and that the entity conducts source code review and security assessments for vulnerabilities, back doors and malicious code.
• SA 6 Supply Chain Management. SA 6.1 requires highly critical third-party products and services to meet security requirements before procurement. SA 6.2 asks for a supplier evaluation process, agreed control measures in supplier contracts, acceptance criteria for new systems, and assurance that "software delivered has not been altered or modified", plus right to audit and compliance with federal and local requirements in the contract.
• CO 7 Security Assessment and Vulnerability Management and CO 8 Patch Management. CO 8.1 restricts obsolete software, requires critical security patches "as soon as practicable from the date of release", testing on a subset before wide rollout, patches from trusted sources, and advance notice from third parties before they release patches. CO 8.2 requires tracking of patches and updates.
• DP 1.4 data location. Health information and its copies, whether "encrypted, anonymized, deidentified, pseudonymized", must not be stored, processed or transferred outside the UAE unless entity management approves an exemption and DoH approves it. Access to systems containing PII or PHI is limited to people physically present in the UAE or holding a DoH licence, again with exemptions through DoH.
• CS 1.2 cloud. Cloud environments must be physically hosted in the UAE with nothing outside the country, "including backup and disaster recovery", and health data in the cloud must not be open to analytics providers that send data abroad or to remote support from outside the UAE.
• DP 1.7 breaches. Breaches are reported to DoH on the timelines in the ADHICS implementation guidance, with the Data Breach Form submitted within 72 hours of acknowledging the incident and full investigation evidence within 30 working days of the initial report.

Central Bank of the UAE: Operational Risk Management Regulation

Status: in force from 14 September 2026. The CBUAE Rulebook lists Circular C 1/2026, "Effective from 14/9/2026", status in force, issued under Federal Decree-Law No. 6 of 2025 regarding the Central Bank. Article 19 cancels Circular No. 163/2018 (the Operational Risk Regulation) and the Operational Risk Standards of 29 August 2018. Article 20 says it takes effect one month after publication in the Official Gazette. It applies to licensed financial institutions (LFIs). The Central Bank also publishes an Outsourcing Regulation for Banks; we could not retrieve its text on the day of writing, so this guide relies on the 2026 regulation.

The articles that reach software and suppliers:

• Article 7 (internal controls). Periodic operational risk stress tests, including penetration testing; for Critical Functions the testing must include penetration testing by an independent third party, with results to the Board.
• Article 8 (ICT and cybersecurity). A board-approved ICT and cybersecurity risk framework covering vendor management security, vulnerability testing, change and patch management, and the use of actionable intelligence about vulnerabilities in systems, networks and applications. LFIs must manage ICT systems "including those operated or made available by Third-Party Service Providers" and keep a strategy and timeline for renewing or retiring obsolete and unsupported hardware and software. The Master System of Record must be maintained and stored within the UAE, including when outsourced; foreign branches may keep an up-to-date copy in the UAE with Central Bank approval.
• Article 9 (incident management). Incident response and recovery plans that cover ICT and cybersecurity incidents, an inventory of internal and third-party resources needed for recovery, severity classification, root cause analysis of all material incidents and a register of every incident.
• Article 12 (change management). For Changes in Operations, the LFI must notify the Central Bank and provide an external expert's report at least 30 calendar days before implementation, with a rollback plan and a parallel run where one ICT system replaces another.
• Article 13 (third-party risk). A board-approved third-party risk strategy; risk assessment and due diligence before any arrangement; for arrangements touching Critical Operations, proof the provider has at least equivalent operational resilience; a Central Bank notice of non-objection before outsourcing anything whose disruption could significantly affect Critical Operations; contracts with rights to records, audit and risk reports and Central Bank on-site examination; the same terms enforced on subcontractors that handle data; a register of outsourced activities (13.9.1); and viable exit plans (13.11).
• Article 15 (notification). Significant events: notify within 4 hours, summary report within 24 hours, notice on return to normal. High-risk incidents: notify within 72 hours, with the high-risk criteria defined in board-approved policy.

Federal Decree-Law No. 45 of 2021 (PDPL)

Status: the law is in force; we could not confirm the executive regulations. The official legislation portal blocked automated access on the day of writing, so we could not re-read the text or confirm on a primary source whether executive regulations have been issued. Secondary reporting in 2026 is split, and several sources say they still have not been issued. Treat any compliance deadline you see quoted for the PDPL as unconfirmed until it appears on the UAE legislation portal or a UAE Data Office page.

What does not change with the regulations is the dependency: security of processing, records of processing and breach handling all rest on knowing which systems and suppliers touch personal data, the same inventory every other regime asks for. Our earlier post on UAE PDPL and sector data localisation covers the privacy angle in more depth.

DIFC, ADGM and the Cybersecurity Council

The Dubai International Financial Centre and Abu Dhabi Global Market run their own data protection laws (DIFC Data Protection Law No. 5 of 2020 and the ADGM Data Protection Regulations 2021) and their own regulators. Both free zones' legislation pages refused automated requests on the day of writing, and so did the UAE Cybersecurity Council's site, so we quote no clause numbers or policy documents for them. If your entity sits in a free zone, read the commissioner's current text before you map controls.

UAE AI guidance

Status: a national charter, not a binding AI act. The UAE government portal publishes the UAE Charter for the Development and Use of Artificial Intelligence as a policy that serves the UAE Strategy for Artificial Intelligence. Its objectives include ethical and responsible use, protecting privacy and data security, and transparency and accountability. Its principles include data privacy, transparency, human oversight, governance and accountability, technological excellence, and commitment to treaties and applicable laws. The charter does not set penalties or deadlines. In practice the enforcing rules for AI are the data protection laws above, sector rules like the CBUAE regulation (whose Article 8 risk framework covers every ICT system, including AI services you buy), ADHICS for health data, and the DIFC's AI processing regulation for free zone entities. For the infrastructure side of the national AI build-out, see our comparison of Gulf AI data centres in 2026.

What the rules ask of software and open source

Put the regimes side by side and the asks are remarkably consistent. The table maps each requirement to the source clause and the evidence a supervisor, auditor or customer usually asks to see.

Two consequences follow. The inventory comes first: every regime assumes you can say what software you run, from whom, at which version, and a 4-hour notice leaves no time to email product teams. Residency applies to your security tools too: a scanner that uploads source code or health data to a cloud outside the UAE can itself breach ADHICS DP 1.4 or a bank's data rules.

Real public incidents in or affecting the UAE

We used only official statements carried by the state news agency WAM. We draw no conclusions about any organisation beyond what the statements say.

• 21 February 2026: attacks the Council described as terrorist in nature. The UAE Cybersecurity Council said national systems thwarted organised attacks on digital infrastructure and vital sectors, including attempts to infiltrate networks, deploy ransomware and run systematic phishing campaigns against national platforms. The Council said the attackers used artificial intelligence to build offensive tools.
• 10 August 2026: coordinated attacks on aviation, energy and education. The Council said national cyber systems detected and stopped advanced, coordinated attacks on the aviation, energy and education sectors, using breach attempts against systems and digital infrastructure, attempts to target accounts and operational data, targeted phishing, and attempts to use people as the entry point. It said intrusion attempts were contained before attackers reached their objectives.

Neither statement names a software supplier or a specific vulnerability, and we infer none. They do show the threat model UAE supervisors are working from: persistent, sector-targeted and increasingly AI-assisted attempts on the critical entities the IA Regulation and the CBUAE rules cover. Our UAE AI strategy timeline is related reading.

The personas who own the problem

The CISO

What they need: a defensible answer to the Board and the supervisor that the institution knows its software estate, manages third-party ICT risk and can meet the reporting clocks. Under CBUAE Article 4 the Board must approve and oversee the ICT and cybersecurity risk framework, so the CISO now owes the Board regular reporting on ICT risk exposure, incidents and testing gaps (Article 8).

When: the first post-14 September 2026 supervisory review of operational risk; any significant event that starts the 4-hour clock; the annual Board review of risk appetite and tolerance for disruption.

The Head of AppSec or VP of Engineering

What they need: vulnerability management that keeps up with release speed, a clear patch policy the business accepts, and proof for the outsourced code their teams depend on. IA Regulation T7.7.1 wants vulnerabilities found before production; ADHICS CO 8.1 wants critical patches as soon as practicable.

When: each release; each critical advisory; each new outsourced development contract.

The GRC or regulatory compliance lead

What they need: one control map across the IA Regulation, ADHICS, the DESC ISR (where relevant), the CBUAE regulation and the PDPL, with evidence that refreshes itself. ADHICS already cites IA Regulation control IDs, so you can map once and report twice.

When: DoH assessments under ADHICS, TDRA requests to justify excluded controls, internal audit under CBUAE Article 4, and the PDPL whenever its executive regulations land.

Procurement and vendor risk

What they need: a vendor register that covers software suppliers, contract templates with secure coding, audit, incident notification and data location clauses, and an exit plan for every provider that supports Critical Operations (CBUAE Article 13.11). For outsourcing that could significantly affect Critical Operations, the Central Bank's notice of non-objection must come before signature, so procurement needs to know early.

When: onboarding, renewal, and any time a supplier changes how it hosts data.

The DPO and, in health, the information security officer

What they need: records of processing that name the systems and suppliers, a breach runbook that can produce the ADHICS Data Breach Form inside 72 hours, and certainty that no tool is quietly moving health or personal data out of the UAE.

When: every breach, every new cloud or AI service, every DoH request.

Step by step: a practical 30/60/90-day plan

This plan works with or without any particular product. Each phase ends with something you can show a supervisor.

Days 1 to 30: know what you run and what clocks you are on

1. Write down which regimes apply to which legal entity. Use the table in "Who this applies to". Confirm with legal whether each entity is a designated critical entity under the IA Regulation, an LFI under the CBUAE, in scope of ADHICS, a Dubai Government entity, or in a free zone.
2. Name the Critical Operations and critical systems. CBUAE Article 3 requires a mapping of the people, technology, data and third parties behind each Critical Operation. Start with the top ten systems by business impact.
3. Produce an SBOM for each critical system. Generate SPDX or CycloneDX from source repositories and container images. For bought software, ask the vendor for one. Record vendor, version, licence and owner, which is what IA Regulation T7.7.1 guidance asks for.
4. Run a first vulnerability pass and rank it. Combine severity with exploitability signals such as CISA's Known Exploited Vulnerabilities catalogue and FIRST's EPSS scores, then ask which vulnerable code is actually called.
5. Build the incident clock runbook. For the CBUAE: who decides an event is significant, who sends the 4-hour notice, who writes the 24-hour summary, and what the board-approved definition of a high-risk incident is (Article 15.3). For ADHICS: who completes the Data Breach Form within 72 hours.
6. Audit where your own tools send data. List every scanner, AI assistant, code host and SaaS tool in the pipeline and record where it stores code, findings and data. Flag anything that moves health data or systems of record outside the UAE.

Day 30 evidence: applicability memo, Critical Operations map, SBOMs for critical systems, a ranked vulnerability list, the incident runbook and a data flow register for security tools.

Days 31 to 60: control the flow of new risk

1. Write the patch policy with real timelines. Define standard, urgent and critical classes (ADHICS CO 8.1 item 3) and time targets your Board accepts. Add an end of life register to meet CBUAE Article 8's obsolete software strategy.
2. Put a gate in CI. Decide what blocks a release (for example a known exploited vulnerability in reachable code), what only warns and what simply notifies the owner. Write the exception process down, with expiry dates.
3. Fix the top of the list. Work the ranked list from day 30. Raise upgrade pull requests rather than tickets wherever a fixed version exists.
4. Update supplier contracts. Add secure coding, source code custody, audit rights, incident notification, patch advance notice (ADHICS CO 8.1 item 8), SBOM delivery and data location clauses. Flag every arrangement that needs a CBUAE notice of non-objection.
5. Inventory AI use. List models, AI services and agents in use, what data each touches, where it runs and the human oversight step. Map each to the AI Charter principles your policy adopts.
6. Verify software at intake. Record hashes and check signatures or provenance for third-party software before deployment, which answers IA Regulation T7.8 and ADHICS SA 6.2 item 6.

Day 60 evidence: approved patch policy, CI gate configuration and exception log, merged fix pull requests, updated contract templates, an AI inventory and intake verification records.

Days 61 to 90: prove it and keep proving it

1. Map controls once. Build one control map across IA Regulation, ADHICS, the CBUAE regulation, the DESC ISR where relevant, and the PDPL. Use ADHICS's own "UAE IAR Reference" lines as the crosswalk.
2. Automate evidence. Connect scanners, code hosts and ticketing so the evidence for each control refreshes on a schedule rather than at audit time.
3. Run a tabletop on the 4-hour clock. Pick an illustrative scenario: a critical vulnerability in a widely used open source library is announced at 09:00. Can you say by 13:00 which Critical Operations contain it, and send the notice if the event qualifies as significant?
4. Test penetration and recovery. Schedule the independent third-party penetration test that CBUAE Article 7 requires for Critical Functions, and test the rollback and parallel run plans that Article 12 expects for system changes.
5. Report to the Board. Use the evidence above to report ICT risk exposure, open incidents and testing gaps (CBUAE Article 8).
6. Set the review cadence. Quarterly vendor reviews and an annual review of every excluded IA Regulation control.

Day 90 evidence: a unified control map, automated evidence feeds, a tabletop report, a penetration test plan and a Board report.

How Safeguard does this

Everything below is GA and is taken from Safeguard's offering documentation and docs.safeguard.sh. Where the docs do not show a screen or command, we describe the outcome rather than invent one. Safeguard helps a team produce and keep the evidence these regimes ask for; it does not make an organisation compliant with any of them, and Safeguard holds no UAE certification or assessment.

1. Choose where Safeguard runs before anything else. For UAE buyers residency is often a legal requirement, not a preference. Safeguard's SaaS is multi-region in the US, EU and Gov regions only, and there is no UAE region. The GA answers for residency are private VPC or dedicated tenancy, full on-prem in your own data centre, and fully air-gapped with the AI models running entirely inside your environment and signed offline snapshot delivery.
2. Or keep code on your machines with the local runner (GA). The CLI runs as a local runner on your own systems. It pulls the repository locally, scans there and pushes only encrypted results back. Source code never leaves your environment. If even results must stay in-country, pair the runner with an on-prem or air-gapped deployment.
3. Decide the AI mode per tenant. Zero AI mode (GA) runs the whole platform deterministically with no LLM in the loop, which suits a hard no-AI policy. Bring your own model (GA) lets you plug in a provider already on your approved list, and local models (GA) run quantised Safeguard models inside your environment. Safeguard states that customer code, SBOMs and telemetry are not used to train shared models.
4. Build the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX for repositories, container images and uploaded SBOMs, and software composition analysis (GA) builds the full transitive dependency inventory. The platform shows which projects contain a given component and version, which is the query you need inside a 4-hour window. Safeguard's UAE IA framework page checks each scan for the component versions and supplier data that IA Regulation T7.7.1 guidance and ADHICS SA 6 ask for.
5. Rank vulnerabilities. Vulnerability management (GA) matches components against public vulnerability databases and enriches them with EPSS and CISA KEV. Reachability analysis (GA) then ranks the vulnerable code paths your application actually calls, so the patch policy's "critical" class means something.
6. Fix with pull requests, under your control. Autonomous remediation (GA) uses Safeguard's Griffin models to open tested, policy gated fix pull requests, singly or in bulk. It ships switched off, with every category set to Manual, so your change management (CBUAE Article 12) decides what runs on its own.
7. Enforce at the gate. Policies, gates and guardrails (GA) evaluate findings at build, CI and release. Gate actions are Block, Warn and Notify, and approvals for anything that should pass anyway run through exceptions, which gives you the exception log an auditor will ask for. Policies can be written in plain English (GA). License compliance (GA) applies the same gate to licence policy.
8. Map the controls. The Compliance and GRC suite (GA) includes frameworks, controls, evidence, monitoring, tests, policies, questionnaires, risks and vendors. Safeguard's docs page for the UAE IA standards lists it under its older name, "UAE NESA IA Standards", and shows scan requirements such as AE-NESA-ASSET (asset inventory), AE-NESA-3P (third-party security), AE-NESA-INT (system acquisition and integrity, evidenced by cryptographic hashes across components) and AE-NESA-OPS (operations security and patching), plus a policy template for a cyber incident notification procedure. The UAE PDPL page maps scan requirements for security of processing, records of processing, processor engagement, breach notification readiness and cross-border transfer readiness. Both frameworks are on in a workspace unless you switch them off in Compliance › Manage. Treat the clause references on those pages as Safeguard's mapping and check them against the law's current text with your counsel.
9. Cover suppliers. TPRM (GA) onboards vendors, requests SBOMs, projects or products from them, scores and continuously monitors supplier risk and applies policies and gates to what they deliver. CSAF and VEX upload (GA) takes in a supplier's advisories and "not affected" statements so they inform your findings.
10. Answer customers once. If you are the supplier, Trust Center (GA) publishes your security posture and helps answer questionnaires. On Safeguard's own posture, the accurate wording is "SOC 2 Type II audit in progress" and "designed for FedRAMP High"; neither is a UAE assessment.
11. Govern AI. AI-BOM discovery (GA) inventories AI assets across code, cloud and SaaS. AI Gateway (GA) puts a guardrail proxy in front of LLM traffic for prompt injection, jailbreak and PII egress. MCP Guardrail (GA) issues guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access. Together they give you the inventory and the human oversight record that the AI Charter's principles point to.

What Safeguard does not do

• It does not report to the Central Bank, DoH or TDRA for you. Safeguard can tell you within minutes which products contain an affected component. Deciding whether an event is significant or high risk, and sending the 4-hour, 24-hour or 72-hour notice, stays with your people under your board-approved policy.
• It does not host in the UAE as SaaS. The SaaS regions are US, EU and Gov. If your data or code must stay in the UAE, use on-prem, air-gapped or private VPC deployment in a UAE facility you choose, or the local runner.
• It does not hold any UAE certification, listing or assessment. Nothing here makes your entity compliant with the IA Regulation, ADHICS, the DESC ISR, the CBUAE regulation or the PDPL. Those are judged by your regulator and your auditors.
• It does not replace legal interpretation. Designation, high-risk incident criteria and the PDPL's open questions are for counsel.
• It does not fix code it does not build. When a vulnerability lives in a vendor appliance, a hosted service or a core banking package you do not compile, the fix has to come from that vendor; Safeguard tracks the exposure and the supplier, but the patch is theirs.
• It does not run your penetration test or tabletop. CBUAE Article 7 asks for independent third-party penetration testing for Critical Functions. Use Safeguard's findings as input, not as a substitute.

Common mistakes

• Calling the IA Regulation "optional" because nobody designated you. If you supply a designated critical entity, its T6 and T7.8 obligations flow to you by contract.
• Skipping the risk assessment. Under section 3.3 of the IA Regulation, no risk assessment means every control is mandatory.
• Assuming encryption solves residency. ADHICS DP 1.4 explicitly covers encrypted, anonymised and pseudonymised copies.
• Forgetting backups and disaster recovery. ADHICS CS 1.2 puts backup and DR inside the UAE requirement too.
• Quoting a PDPL deadline from a blog. Until the executive regulations appear on an official source, no specific PDPL compliance date is confirmed.
• Treating the 72-hour clock as the only one. Under CBUAE Article 15 a significant event needs notice in 4 hours and a summary in 24.
• Sending code to a cloud scanner abroad. Your security tooling is part of your data flow. Check it before your supervisor does.
• Leaving outsourced code out of scope. IA Regulation T7.6.5 and ADHICS SA 5.1 make the entity responsible for code written by contractors, including source code custody.

FAQ

Is the NESA standard still in force in the UAE?

The rules many people still call "NESA" are published today as the UAE Information Assurance Regulation, version 1.1 from March 2020, on TDRA's site. It applies to critical entities designated under the national critical information infrastructure policy.

Does the UAE require an SBOM?

No UAE law uses the term SBOM. But IA Regulation T7.7.1 guidance makes a software inventory with vendor and version a prerequisite for vulnerability management, CBUAE Article 3 requires mapping the technology behind Critical Operations, and ADHICS SA 6 requires verifying that delivered software is unaltered. An SBOM is the most practical way to meet all three.

What are the Central Bank of the UAE incident reporting deadlines?

Under the Operational Risk Management Regulation (C 1/2026, effective 14 September 2026), Article 15: notify the Central Bank within 4 hours of a significant event, send a summary report within 24 hours, notify on return to normal, and notify any high-risk incident within 72 hours.

Can a UAE bank use a cloud or SaaS security tool hosted abroad?

The CBUAE regulation requires the Master System of Record to stay in the UAE and a notice of non-objection before outsourcing that could significantly affect Critical Operations. Whether a given tool is acceptable depends on what data it receives and on the bank's own assessment. Tools that run on-prem or keep code local avoid the question.

Must health data stay in the UAE under ADHICS?

Yes, unless DoH approves an exemption. ADHICS V2 DP 1.4 covers health information and its copies in any form, and CS 1.2 requires cloud environments, including backup and disaster recovery, to be hosted in the UAE.

Have the UAE PDPL executive regulations been issued?

We could not confirm their issuance on an official source on 26 October 2026, and secondary reports disagree. Check the UAE legislation portal and the UAE Data Office before relying on any deadline.

Is there a UAE AI law?

There is no federal AI statute with penalties. The UAE Charter for the Development and Use of Artificial Intelligence sets principles, while data protection law, sector rules and the DIFC's regulation on autonomous systems do the enforcing.

Is Safeguard certified or approved by any UAE authority?

No. Safeguard helps teams produce and keep evidence for these regimes. Its own posture is described as "SOC 2 Type II audit in progress" and "designed for FedRAMP High".

Every UAE regime above asks you to fix known vulnerabilities on a defined timeline, and ADHICS CO 8.1 adds that critical patches go in as soon as practicable from release. The section below sets out how Safeguard shortens the time from a published fix, or a missing one, to patched code in your own builds.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the CLI reads the finding and the advisory, asks before any command that changes something, edits package.json, runs the install and the tests with approval, and pushes nothing. The same approval step is what a UAE bank's change management under CBUAE Article 12 will want to see.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code and scans from the terminal. This is the flow for teams whose code must not leave the UAE: the scan runs where the code lives and only encrypted results leave.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For a GRC lead, that tool-by-tool choice is the human oversight and access record the UAE AI Charter's governance principles point towards.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• UAE Information Assurance Regulation, Version 1.1, March 2020 (TDRA)
• Operational Risk Management Regulation, C 1/2026 (CBUAE Rulebook)
• Abu Dhabi Healthcare Information and Cyber Security Standard V2 (Department of Health Abu Dhabi)
• Standards and Policies, including the Information Security Regulation (Dubai Electronic Security Center)
• The UAE Charter for the Development and Use of Artificial Intelligence (UAE government portal)
• UAE Cybersecurity Council thwarts advanced attacks targeting vital sectors (Aletihad, WAM)
• UAE Cybersecurity Council announces systematic terrorist cyberattacks targeting vital sectors thwarted (Aletihad, WAM)
• CISA Known Exploited Vulnerabilities Catalog
• FIRST Exploit Prediction Scoring System
• Safeguard docs: UAE NESA IA Standards
• Safeguard docs: UAE PDPL
• Safeguard docs
• Safeguard download

To try the flows above, download Safeguard or start with the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.