Passing a NESA assessment once is not the hard part. The hard part is still being compliant eleven months later, and that is the problem GRC exists to solve. A GRC programme that works gives every control a named owner, ties the risk register to real technical findings, and produces evidence continuously instead of in a panic the month before the assessor arrives.
- The authority called NESA is gone; the standard remains. Compliance today means the UAE IA Standard: 188 controls in management and technical families, prioritised P1 to P4.
- Dubai banks answer to CBUAE first, but assessors on both tracks want the same artefacts: applicability matrix, live risk register, per-control evidence, honest exception log.
- Programmes fail at ownership, not documentation. A control without a named owner decays silently until an assessor finds it.
- Wire vulnerability and SIEM findings into the risk register or it turns into fiction within a quarter.
What "NESA compliance" actually refers to
The National Electronic Security Authority no longer operates under that name. Its functions were absorbed into the UAE's federal cyber structures, and policy direction now sits with the UAE Cybersecurity Council. The search term survives because the standard survives: when a regulator, an assessor or an RFP says NESA, it almost always means the UAE Information Assurance Standards. That is 188 controls, split between management families covering governance, risk management, human resources and awareness, and technical families covering access control, operations, communications and incident management, each control carrying a priority tier from P1 to P4. P1 is where every implementation is expected to start.
For a Dubai bank the picture is layered rather than singular. CBUAE supervision comes first, and its expectations overlap heavily with the IA Standard; I have written separately about what CBUAE actually requires of UAE banks. Dubai government entities follow DESC's ISR instead. The overlap is the good news: a control framework built properly for one maps to the others with an afternoon of cross-referencing, not a second programme.
Where GRC fits, and where the sales pitch gets it wrong
GRC gets sold as a platform. It is better understood as three questions a bank has to be able to answer at any moment. Governance: who decided this, and who owns it now? Risk: what have we accepted, what are we mitigating, and where is that recorded? Compliance: can we prove it, today, with evidence that predates the request?
A platform can help answer those questions at scale. What it cannot do is answer them for you. In my experience the deployments that fail are the ones where the licence was bought before the operating model existed: workflows unassigned, control owners never named, the risk register imported once from a spreadsheet and never touched again. Vendors selling GRC for NESA rarely dwell on this, because the fix is organisational rather than technical, and organisational fixes do not renew licences.
What assessors actually ask for
Assessment against the IA Standard is evidence-driven, and experienced assessors pull threads rather than reading binders. Expect to produce:
- A scoping statement and control applicability matrix, with justification for every control marked not applicable
- The risk assessment methodology and the register itself, with review dates that show it is alive
- Evidence for sampled controls: configurations, tickets, logs, meeting minutes, not policy PDFs
- An exception log with expiry dates and sign-off from someone senior enough to accept the risk
- Remediation tracking that shows findings from the last cycle were closed, not re-found
The thread-pull looks like this: the assessor picks one control, asks who owns it, when it was last reviewed, and for the evidence. If the owner turns out to be a job title rather than a person, or the evidence is a policy document rather than proof the policy operates, the rest of the assessment gets harder.
The failure patterns that repeat in Dubai banks
The same handful of failures show up across the region, and none of them are exotic.
Binder compliance. A gap assessment is done once, turned into slideware, and declared a programme. Twelve months later the controls have drifted and nobody noticed, because nothing was measuring drift.
Platforms without owners. The GRC tool is live, the dashboards are green, and every workflow is assigned to a distribution list rather than a person. Green dashboards with no owners are worse than no dashboards, because they manufacture false assurance.
A risk register disconnected from reality. If vulnerability scans and SOC findings never update the register, the register is fiction within a quarter. The banks that get this right pipe technical output into risk review: SIEM detections mapped to NESA control families on one side, and independent VAPT on the other to test whether implemented controls actually resist an attacker rather than merely existing on paper.
Third parties out of scope. The IA Standard expects supplier risk to be managed, and assessors increasingly ask for it. A register that covers your own estate but not your outsourced SOC, your core banking vendor or your cloud tenancy has a hole exactly where attacks now arrive.
A roadmap that survives contact with the audit
- Scope honestly. Decide what is in, document why anything is out, and get the applicability matrix signed by someone accountable.
- Gap assess against the control families, P1 controls first. Record the gap, the owner and the date in the same place you will track remediation.
- Run the risk assessment as a feed into a live register, not a standalone deliverable. Every high risk should trace to a control, an exception or a documented decision.
- Implement with evidence capture designed in. If producing evidence for a control takes manual effort every quarter, that control will stop being evidenced by the third quarter.
- Set a review cadence and keep the exception log honest. An expired exception nobody renewed is the single easiest finding for an assessor to write.
People Also Ask
What are the most common challenges in achieving NESA compliance?
Ownership and evidence, in that order. Most organisations can write policies and pass a point-in-time review; far fewer can name the owner of every applicable control or produce operating evidence on demand. Budget matters less than structure: a small team with clear ownership beats a large programme without it.
Do you need a GRC platform to comply?
No. A disciplined spreadsheet and a named owner per control will pass an assessment at moderate scale. A platform earns its place when control volume, evidence collection and multi-framework mapping, NESA plus CBUAE plus ISO 27001, outgrow manual tracking. More answers to common GRC questions are in the GRC FAQ.
The three-question test
Before spending anything on tooling or consultancy, put three questions to the current programme. Pick a control at random: who owns it, as a named person? When did the risk register last change because of a technical finding? Which exceptions expire this quarter, and who renews them? If all three have answers, you are ahead of most of the region and the next assessment is an exercise. If none do, that gap, not another slide deck, is where the work starts.
