DIFC and ADGM Fintechs: The DFSA and FSRA Cyber Rules Side by Side, and the One Control Set That Answers Both

Two regulators, one engineering team, the same month

The chief operating officer of a nineteen-person payments firm keeps two folders open on her desktop. One is labelled DIFC. The other, opened in November when the group decided to licence a second entity in Abu Dhabi, is labelled ADGM.

Her problem is not that she cannot read a rulebook. Her problem is that she has read both, and each one asks the same question in a different vocabulary. One folder wants a description of how the governing body oversees technology risk. The other wants the same thing under a different heading, in a different template, with a different owner named.

So her engineering lead, who is also the only person who can deploy to production, has spent six working days in January writing prose. Not patching. Writing. On the Thursday, an email from the group's largest merchant asks for the firm's incident notification commitments before renewal, and there is now a third template.

She does the arithmetic on the drive home. Two regulators, one merchant, three documents, one engineer. And the engineer is the same person who was supposed to finish the review of the twenty-eight software packages the platform imports.

Nobody in this story has done anything wrong. They have simply organised the work by regulator instead of by control, and the cost is paid in engineering days they do not have.

What the heck does this mean

The Dubai Financial Services Authority, the DFSA, regulates firms licensed in the DIFC. The Financial Services Regulatory Authority, the FSRA, does the same job in Abu Dhabi Global Market. They are separate regulators with separate rulebooks, and a group with entities in both carries both sets of duties.

On cyber, they converge more than the paperwork suggests. Each one puts technology and cyber risk on the firm's governing body rather than on an outsourced IT provider. Each expects you to understand your own systems and the dependencies you have rented. And neither wants to learn about a material incident from a newspaper.

Jargon translated. Technology risk: the chance that something you run, or something you rent, stops working or leaks. Outsourcing: anything a third party does that you would otherwise have to do yourself, including your cloud. Governing body: the people who sign, not the people who deploy.

Data rules ride alongside. A DIFC entity sits under DIFC Data Protection Law, including Regulation 10 from September 2023 covering personal data in AI systems. An onshore back office sits under federal PDPL. The regulator you answer to on conduct is not always the one you answer to on data. Our DFSA page and FSRA page set out each side.

The numbers that matter

Third parties were involved in 48% of breaches in the Verizon 2026 Data Breach Investigations Report, up 60% on the year before. For a fintech, "third party" is not an abstraction. It is your payment processor, your KYC vendor and the four open-source libraries in your build.

Exploitation of a known vulnerability was the initial access route in 31% of breaches in that same Verizon 2026 report. Somebody published the fix. Nobody applied it.

The median time to patch an internet-facing vulnerability was 43 days in the Verizon 2026 report. Attackers do not need forty-three days. They need one afternoon and a scanner.

What to do this week

1. Build one control set, not two compliance programmes. Write each control once, then keep a two-column sheet mapping it to the DFSA rule and the FSRA rule it answers. When either regulator asks, you produce the same evidence with a different cover page. (CIS 1 Inventory and Control of Enterprise Assets)
2. List every system, every cloud tenant and every production repository, with a named human owner for each. Both rulebooks assume you have this list. Most firms of your size have it in one engineer's head. (CIS 1 Inventory and Control of Enterprise Assets)
3. Fix the internet-facing gaps on a clock, not on a mood. Set a target of seven days for anything reachable from outside and thirty for the rest, write the target down, and review the exceptions at the operations meeting. (CIS 7 Continuous Vulnerability Management)
4. Name your critical providers in one table: what they hold, what breaks if they stop, and what their contract says about telling you. Ask each for the shared responsibility document. The gap between what you assume they cover and what they actually cover is where the surprise lives. (CIS 15 Service Provider Management)
5. Write the incident notification page and rehearse it for forty minutes. Who decides an incident is material, who drafts the regulator's notification, who calls the merchant, and where the phone numbers are kept if email is the thing that is down. (CIS 17 Incident Response Management)
6. Run the obligations finder once with the second entity included. Groups usually discover one rulebook they had assigned to nobody. (CIS 1 Inventory and Control of Enterprise Assets)

Where AccuSights fits

We assess your firm once and map the findings to the DFSA rulebook, the FSRA rulebook and your data obligations at the same time, so a single piece of work answers both folders. The read-only compliance agent then gives you continuous insight into your cloud and infrastructure, so you can see which controls are in place and which have slipped, prioritise the right things and keep an eye on them. We have no access to your systems and we do not remediate. You or your IT partner fix it, and we show you exactly where.

There is a falcon on our mark for a reason. From a long way up it picks the one thing that matters out of a wide field of noise, and ignores the rest.

Questions people ask

Do the DFSA and the FSRA expect different cyber controls? The wording differs and the underlying expectations rhyme. Both regulators put cyber and technology risk on the governing body rather than on the IT vendor, both expect the firm to know its systems and its outsourced dependencies, and both expect an incident to be reported to them rather than quietly handled. Build one control set, then keep a short mapping sheet that shows which rule in each rulebook the control answers. Read your own licence conditions for the specific notification route, because those are set per firm and per activity.

We are a DIFC firm using an onshore Dubai back office. Which rules apply? Both, on different data and different entities. The DIFC entity answers to the DFSA and to DIFC Data Protection Law, including Regulation 10 from September 2023 on personal data in AI systems. The mainland service company is a mainland company under federal PDPL, whatever the client agreements say. The practical fix is a data flow map that shows which entity holds what, so you stop guessing at the boundary.

Does a cloud provider's certification cover our regulatory obligation? It covers their side of the line and not yours. A cloud provider's certificate speaks to the platform: physical security, hypervisor, availability. Your identities, your access rules, your configuration, your data retention and your customer notifications stay yours. Ask every critical provider for the shared responsibility document in writing, then list what falls to you and check it. Third parties were involved in 48% of breaches in the Verizon 2026 Data Breach Investigations Report.

Two rulebooks, one engineer: organise the work by control and she gets her week back, organise it by regulator and you will hire a second one to write the same paragraph twice.