NESA, DESC & CBUAE Secure CI/CD Checklist (2026)

UAE cybersecurity compliance used to be a slide in a board deck. In 2026 it is an enforceable obligation with numbers attached - AED 100,000 to AED 1,000,000 under PDPL, AED 500,000 to AED 3,000,000 for harm to critical infrastructure, plus license-action risk for regulated financial institutions. And the scope has widened: NESA now explicitly covers source code supporting critical information infrastructure, which pulls your repos, build systems and artifact stores inside the control boundary for the first time.

That changes who has to care. It is no longer just the security team - it is whoever owns the CI/CD pipeline. The problem is that most published guidance gives you a single-framework summary or a generic “UAE cybersecurity overview”, and none of it tells you which pipeline gate satisfies which control. So this is the missing piece: a cross-framework secure CI/CD compliance checklist that maps NESA, DESC ISR v3 and CBUAE controls onto the actual stages of your pipeline - commit, build, scan, deploy, residency, runtime - with the 2026 penalty numbers attached and auditor evidence noted for every row.

If you run on a specific cloud, pair this with the platform-specific deep dives: the Azure DevOps UAE NESA compliance guide and the AWS DevOps UAE DESC-certified deployment playbook. This page stays platform-agnostic on purpose - it is the master checklist those guides hang off.

What NESA, DESC ISR v3 and CBUAE actually require from a CI/CD pipeline in 2026

Short answer first, because that is what most people search for. Three frameworks, three audiences:

• NESA / SIA (UAE Information Assurance Standards, under the Cybersecurity Council) applies to operators of national critical information infrastructure - energy, telecom, transport, government CII.
• DESC ISR v3 (Dubai Electronic Security Center, Information Security Regulation version 3) applies to Dubai government entities and Dubai-regulated bodies.
• CBUAE (Central Bank of the UAE) applies to licensed financial institutions - banks, payment providers, and fintechs operating under a CBUAE licence.

Layered on top of all three is PDPL (the federal Personal Data Protection Law), which applies whenever you process UAE-resident personal data regardless of sector.

From a pipeline perspective, all three frameworks press on the same three control families:

1. Secure SDLC and source-code protection - controlled access to code, traceable changes, dependency and vulnerability management, and protection of the build supply chain.
2. Data residency - keeping UAE-resident data, and often the logs and artifacts derived from it, inside approved in-country regions.
3. Audit and logging - immutable, retained logs that prove who changed what, when, and that controls actually fired.

The 2026 penalty numbers

Here is the part that turned compliance into a buying decision. These are the figures regulated UAE organizations are now planning against:

For a CBUAE-licensed institution, the license-action risk is usually the one that focuses minds. A fine is a line item; a supervisory restriction can stop you onboarding customers.

Why source code is suddenly in scope

The meaningful 2026 shift is that NESA explicitly scopes source code supporting CII. Previously a lot of teams treated “compliance” as a production-runtime problem and left the pipeline out. Now the repository, the build runner, the dependency cache and the artifact registry are all in the control boundary, because that is where the software that runs critical infrastructure is actually produced.

On the financial side, CBUAE Article 13 and Annex II add the residency and outsourcing dimension: licensed institutions must control where data and processing physically sit, including work outsourced to third-party services. A SaaS scanner that ships your code or build logs to a region outside the UAE is exactly the kind of thing Annex II is written to catch.

In the UAE, the same pipeline control often satisfies NESA, DESC and CBUAE simultaneously. The work is not building three pipelines - it is proving one pipeline with policy-as-code evidence. - devsecops.ae

The secure CI/CD compliance checklist, mapped control-by-control to pipeline stages

This is the core of the page. Six stages, each with the concrete controls and the evidence an auditor will ask for. Run your own pipeline against it.

Stage 1 - Source & commit

• Signed commits enforced (GPG / Sigstore) so every change is attributable
• Branch protection on main / release branches - no direct pushes, required reviews
• Secret scanning gate that blocks the commit, not just warns (see the secrets scanners comparison)
• Least-privilege access control on repos, mapped to named roles
• Maps to: NESA T7 (access control / secure SDLC), DESC ISR identity-and-access controls

Stage 2 - Build & dependencies

• SCA scanning of every dependency on each build (compare options in the Snyk alternatives guide)
• SBOM generated and stored per release (see the SBOM tools comparison)
• Reachability / exploitability gating so you fail builds on real risk, not noise
• Pinned dependencies and a controlled internal registry - no unpinned upstream pulls
• Maps to: NESA secure-development / supply-chain controls, DESC ISR vulnerability management

Stage 3 - Scan & policy

• SAST on each pull request, results triaged and tracked
• IaC scanning of Terraform / Kubernetes manifests (see the IaC scanning comparison)
• Policy-as-code (OPA / Conftest) enforcing the rules in the pipeline itself
• Policy decisions logged as machine-readable evidence - this is what auditors actually ask for
• Maps to: all three frameworks’ secure-development and enforcement requirements

Stage 4 - Deploy & artifacts

• Artifact signing (Cosign / Sigstore) and signature verification at deploy time
• Environment segregation - dev / staging / prod isolated, separate credentials
• Change-approval audit trail linking each deploy to an approved change
• Immutable artifact registry with provenance / attestation
• Maps to: DESC ISR change-management controls, CBUAE change and segregation requirements

Stage 5 - Data residency

• UAE-region storage for code, build logs and artifacts (AWS me-central-1, Azure UAE regions)
• CI runners located in-country for in-scope workloads
• Residency review of every SaaS scanner / tool that receives code or logs
• Documented data-flow map showing nothing in-scope leaves the UAE
• Maps to: CBUAE Article 13 / Annex II, PDPL residency provisions

Stage 6 - Runtime & logging

• Immutable audit logs for the pipeline and production changes
• Retention windows that meet each framework’s minimum (typically 12 months or more)
• SIEM integration (Sentinel / Splunk / QRadar) so evidence is centralized and queryable
• Alerting on control bypasses (force-push, skipped gate, unsigned artifact)
• Maps to: all three frameworks’ monitoring, logging and audit requirements

Cross-framework control map: one pipeline control, three frameworks

This is the table no competitor publishes - one pipeline control, mapped across all three frameworks at once. Build the control once, satisfy three regulators, and use this as the index for your evidence pack.

Two things to read off this map. First, the overlap: most rows light up under all three frameworks, which means a single well-instrumented control produces evidence for every regulator you answer to. Do it once, prove it three ways. Second, the divergence: CBUAE residency (Article 13 / Annex II) is stricter than the others on where data physically lives, and DESC carries Dubai-government-specific controls that NESA does not.

That gives teams operating across emirates and sectors a clean shortcut: satisfy the strictest control in each row and you are compliant everywhere at once. It is almost always cheaper than maintaining separate pipelines per framework.

Data residency: the control most UAE pipelines fail

If your pipeline is going to fail one thing in an audit, it is data residency - and usually because nobody mapped where the data actually goes.

What must stay in-country. UAE-resident personal data, and for CBUAE institutions the records and logs derived from it, must sit in approved UAE regions. That increasingly extends to build logs and artifacts when they contain or reference in-scope data, because a build log can leak schema, secrets, or customer identifiers.

Cloud region implications. In practice this means AWS me-central-1 (UAE) or Azure UAE regions for build, artifact storage and CI runners handling in-scope workloads. The platform-specific mechanics are covered in the AWS DESC-certified deployment playbook and the Azure NESA compliance guide - including how to pin region, tighten the data perimeter, and prove it.

The common failure. SaaS scanners and hosted CI runners that ship your code or logs outside the UAE without anyone reviewing it. A cloud-scanning security tool sounds harmless until you realize it sends code context to a server in another region on every run - which is precisely what CBUAE Annex II is written to catch. This is one reason UAE-regulated teams lean toward locally-run scanners (Trivy, Semgrep, Checkov, Gitleaks) that keep code and findings inside the CI runner. The Snyk alternatives guide covers the residency trade-offs tool by tool.

The fix is unglamorous but decisive: a documented data-flow map that shows, for every in-scope pipeline, that nothing leaves the country. That single artifact closes more audit findings than any tool purchase.

How to use this checklist in an audit (and where teams get stuck)

A checklist is only useful if each row converts into evidence. Here is the translation an auditor wants:

The five controls teams most often have no evidence for

In readiness reviews, the same gaps come up again and again. These are the five where teams typically have the control but cannot prove it:

1. Policy-as-code output - the gate exists but nothing logs the decision.
2. Data residency - no data-flow map; nobody can say where build logs live.
3. Artifact signing verification - artifacts are signed but signatures are never verified at deploy.
4. Immutable audit logs - logs exist but are mutable, so they prove nothing.
5. Change-to-deploy traceability - deploys happen, but no record ties them to an approval.

If you can close those five, you are ahead of most regulated UAE pipelines.

Self-assess vs engage a consultant

You can run this checklist yourself - that is the point of publishing it. The honest line on when to bring in help: when an audit deadline is close, when you span two or three frameworks and the mapping is getting expensive, or when you have the controls but cannot produce the evidence. A gated readiness review that turns each checklist row into auditor-ready evidence usually pays for itself well before the audit date, because the alternative is discovering the gaps during the audit itself.

Book a UAE secure CI/CD compliance assessment

Download the checklist, run your pipeline against it, and find your gaps. Then let us do the part that is hard to self-serve: map your specific pipeline against NESA, DESC ISR v3 and CBUAE controls and produce the auditor-ready evidence - policy-as-code output, signed artifacts, data-flow maps, and a control map that survives scrutiny.

Book a UAE secure CI/CD compliance assessment with devsecops.ae - get your pipeline mapped to NESA, DESC and CBUAE before your next audit deadline, not during it.