Dubai Information Security Regulation Version 2
Dubai mandatory information security requirements for government and service entities. Requires detailed CRUD logging for property registry and citizen service databases.
What Dubai ISR v2 draws on
This framework pulls on all three pillars — which is why running them as three separate tools means reconciling three sets of evidence at audit time.
Compliance
Security
What your auditor cites,
and what produces the evidence
The regulator's text is quoted below in italic, exactly as written. What follows each one is what the platform records, detects, or proves — not a claim about your compliance status, which no tool can confer.
Access Control
Organizations MUST implement access control with detailed logging of all access events.
Authorisation is configured in the database; proving it holds is what this requirement actually needs. Vulnerability scanning surfaces excessive privilege and role sprawl, default and weak credentials, and stale or orphaned accounts — including privilege inherited through nested roles, which is where least-privilege reviews usually go wrong. Real-time SQL auditing then shows which of those grants were exercised, so an access review reflects observed use rather than intent.
Security Monitoring
REQUIRES detailed CRUD (Create/Read/Update/Delete) logs for sensitive government data.
A record of processing is only as good as the layer producing it. Real-time SQL auditing captures every statement against the data — the identity, the session, the client, the objects touched, the outcome — with no nightly batch window where activity goes unrecorded. Classification is what makes that a record of *regulated* data rather than a log of everything: it tells you which tables are in scope, so the register describes the processing you actually have to declare. Policy templates then produce it in the shape the framework asks for, instead of leaving you to assemble it from raw logs the week before an inspection.
Incident Management
Security incidents MUST be logged, investigated, and reported to relevant authorities.
Findings route by severity to Slack, Teams, email, PagerDuty, or your SIEM, and escalate automatically when nobody acknowledges them and again when nobody resolves them. Every alert arrives with the query, the identity, and the data classification already attached, so the response starts with context rather than with an investigation. The acknowledge-to-resolve history is retained, which is what evidences that the procedure was followed. Your ticketing system stays where it is — what this produces is a finding worth opening a ticket for.
Audit Trail
Tamper-proof logs MUST be stored centrally and protected from modification.
A requirement like this is about the record surviving the person who would rather it did not, which means the audit trail has to be protected as carefully as the data. File activity monitoring hashes the datafiles, the transaction logs, the backups, and the audit trail itself with XXH3, then baselines them — so an alteration or a deletion is evident rather than inferred, and it is attributed to the session and OS user behind it. Because the same platform holds the query trail, a destructive statement and the file-level change it produced are two views of one event rather than two investigations.
What Dubai ISR v2 covers
This instrument defines no data category of its own. A control set for Dubai Government entities. Classification levels come from the separate Dubai Data Law, not from the ISR.
How Dubai ISR v2 is enforced
Every figure below is the ceiling the instrument publishes about itself, not a prediction of what anything would cost. Enforced by Digital Dubai, through the mandatory ISR compliance audit.
The Information Security Regulation is mandatory for Dubai Government entities and for the organisations that serve them. Compliance is established by audit against the control set and reported centrally; a poor result drives directives and remediation timelines, and it is visible to the entities deciding who to contract with.
No penalty table is published. The consequence is procurement and directive, not a fine.
Uncapped exposure that sits outside this instrument
These come from company law rather than from Dubai ISR v2, and they are not penalties — they are liability for a loss, which is why nothing caps them at a published maximum.
Duty of oversight
Delaware, and followed in most US corporate jurisdictions. It is a rule of company law, not of any privacy or security statute.
Triggered by. A sustained or systematic failure by the board to establish a reporting system for a mission-critical risk — or, having one, consciously disregarding what it reported. The second limb is what a documented, unremediated finding goes to.
Who. Directors, in their personal capacity, in a derivative action brought on behalf of the company.
This is liability for the loss the company suffered, not a statutory penalty, so nothing caps it at a published maximum. A bad-faith finding also takes the conduct outside the exculpation and indemnification the charter would otherwise provide.
In re Caremark Int’l Deriv. Litig. (Del. Ch. 1996); Marchand v. Barnhill (Del. 2019); In re Boeing Co. Deriv. Litig. (Del. Ch. 2021).
Enforcement data reviewed August 2026. Several figures are indexed annually and move.
Built for Dubai ISR v2,
not configured for it afterwards
Dubai Government Data Monitoring
Detailed CRUD logs for property registry and citizen services
ISR v2 Compliance Report
Tamper-proof centralized log documentation
UAE Data Patterns
Identify Emirates ID, property records, and government data
Sensitive Data Access Alert
Alert on access to government and citizen data
Other Consumer & Education frameworks
Walk into the Dubai ISR v2 audit knowing the answer
228 cited requirements across 57 frameworks are mapped to the controls that evidence them. A fixed-fee gap assessment tells you which of them you can already prove today.