Most Microsoft 365 compliance gaps in DIFC-regulated firms are not unknown to the engineering team. They are just not on the COO's radar until the auditor flags them. The pattern repeats so consistently that after eight years of UAE managed IT engagements, we can predict with uncomfortable accuracy what a DFSA or SCA review will surface in a firm that has never had its M365 tenant properly reviewed. There are three gaps in particular that appear in audit findings with regularity. None of them are expensive to fix. All of them become materially more expensive when the regulator finds them first.
The firms that get ahead of it spend less and move faster. The ones that don't end up with a remediation programme that started as a regulator finding, and that is always the harder, more expensive version of the same work.
Gap 1: Devices Accessing M365 With No Conditional Access Enforcement
Conditional Access is the gate that sits between a user's credentials and your tenant. Without it, a stolen password is enough. With it, a stolen password still has to pass device compliance, location, risk, and multi-factor checks before anything useful happens. DFSA's general technology risk expectations, and ADGM's equivalent under its cybersecurity guidance, assume that regulated firms enforce access policies proportionate to the sensitivity of the data being accessed. Trading systems, client KYC data, and regulated communications sit squarely inside that bracket.
In practice, the gap we see most often is not the absence of Conditional Access entirely. It is policies that exist but only apply to a subset of users, or policies that exclude service accounts and admin roles "temporarily" from a rollout two years ago. The audit trail does not forgive that distinction. Either every privileged account is protected by Conditional Access, or the control cannot be considered in place.
Gap 2: No Centralised Endpoint Management
If a partner's laptop is lost in a taxi, what can your IT function do about it in the next hour? If the answer involves calling the partner, asking them to log in to a self-service portal, or escalating to a third-party support contract, the answer is functionally "nothing useful". Microsoft Intune, which ships with most M365 Business Premium and E3 plans, provides the baseline here. Remote wipe, device compliance policies, app protection, and the ability to block a compromised device from the tenant within minutes rather than days.
The reason this gap persists in so many firms is straightforward: the licensing is already paid for, but nobody ever configured it. Intune is a deployment discipline, not a licensing decision. It takes a competent engineer two to three weeks to stand up properly across a 40-person firm. It takes an auditor about eight minutes to identify that it does not exist.
Gap 3: Email Security Posture Below Baseline
SPF, DKIM, and DMARC are three DNS-level controls that verify who is allowed to send mail claiming to be from your domain. They are, individually, unremarkable pieces of email infrastructure. Collectively, they are the difference between a domain that can be reliably impersonated by an attacker and one that cannot. DFSA-regulated firms are expected to have these properly configured, not just present in DNS, but enforced at a policy level that actually rejects spoofed mail.
The gap is almost always in DMARC. SPF is usually configured, because without it external mail often fails to deliver. DKIM is normally enabled, because Microsoft 365 turns it on by default. DMARC, the record that tells receiving mail servers what to do when SPF or DKIM fails, is where firms leave a permissive policy in place ("p=none") and never tighten it. Until DMARC is set to quarantine or reject, the domain remains practically spoofable. Moving from "none" to "reject" requires two to four weeks of DMARC report analysis and some careful phasing, but the engineering work is modest. The harder part is usually organisational: agreeing who owns the change.
Why These Three, and Why Now
These three gaps appear together more often than any other combination because they share the same root cause: they are configured once, during a tenant build, and then never revisited. Conditional Access drifts as new users and roles are added. Intune never gets rolled out past the initial pilot. DMARC sits at "none" because the person who set it up left the firm. None of them fail loudly. All of them fail under regulatory scrutiny.
For firms supervised by DFSA, ADGM's FSRA, or SCA, the operational reality is that cybersecurity baselines are shifting from recommended practice to documented expectation. A firm that cannot demonstrate, on demand, that these three controls are in place is increasingly carrying regulatory risk that did not exist three years ago.
Frequently Asked Questions
How long does a full M365 compliance review take? For a firm of 20 to 60 staff, a baseline review against DFSA expectations typically takes two to three weeks: one week of data gathering across Conditional Access, Intune, Exchange Online Protection, and DMARC records, followed by a remediation plan prioritised by audit risk.
Do we need M365 E5 to close these gaps? No. All three controls (Conditional Access, Intune, and DMARC) are available in Business Premium and E3. E5 adds advanced threat protection and identity features that are valuable but not required to close these specific audit findings.
What is the most common single finding? Conditional Access with admin role exclusions. Every firm we have reviewed has at least one privileged account excluded "temporarily" that has never been re-added.
Can we handle this with our current IT provider? That depends on whether the provider is positioned as a managed IT function or as a reactive support contract. The distinction matters. See our companion piece on proactive vs reactive IT for why.