The Regulator Changed and Your Controls Did Not: IT After the Insurance Authority Transfer

Get the sequence right, because most of the confusion I hear comes from people compressing it into a single event. In August 2023 the Cabinet approved establishing the Insurance Authority as a unified independent regulator for insurance. On 23 November 2023 the Authority began operating, subject to a transition period. In early 2024 the insurance-related competencies transferred from SAMA. On 4 March 2024 health insurance responsibilities transferred from the Council of Health Insurance. Four dates, three institutions, one sector.

Then comes the fact that almost nobody leads with, and it is the only one that changes what you do on Monday: the laws, regulations, rules and instructions previously issued by SAMA and CHI for the insurance sector remain in force and unchanged until the Insurance Authority issues instructions that override them. Nothing was voided. Nothing was renumbered on your behalf. No control you operated in February 2024 became wrong in March 2024.

So the honest summary for an IT function is short: the supervisor changed, the rulebook did not. Anyone who tells you the control environment reset is selling you a programme. Anyone who tells you nothing at all happened has not read their own escalation matrix lately. The truth is narrower and more useful than either.

That was the starting condition, not a permanent state. The Authority has been superseding parts of it since, selectively and on published dates, and the last section goes through exactly what has landed. But persistence is the default, and you cannot spot the exceptions until you know the default.

The failure mode here is not non-compliance. It is staleness, and staleness is the failure nobody staffs for. Your firewall policy, your access review cadence, your restore drills, your incident classification, your retention rules: none of that became invalid on 4 March 2024. What became wrong is the paper wrapped around it.

Go and read your own artifacts with this one question in mind: does this document name a supervisor? The information security policy that names one in its scope statement. The business continuity plan whose notification section points at an institution that no longer holds the competency. The vendor contract with a regulatory-cooperation clause drafted for a different addressee. The audit evidence pack with a cover page that was correct for six years and is now quietly wrong. The partner onboarding form. The disaster recovery runbook. Every one of those describes a real, working control, addressed to the wrong door.

That is a documentation exercise, not a remediation programme, and the distance between those two framings is an entire quarter of your team’s capacity. Refuse the reframe. When I owned an annual IT budget of SAR 6M across seven operating entities, the fastest way to lose a quarter was to accept someone else's insistence that a naming problem was an architecture problem. It usually is not. Make them show you the control that broke.

Here is where teams get the sequencing backwards. When supervision transfers, the first thing that changes is not what you must do. It is who you tell, and how fast. Escalation paths, notification recipients, the internal chain that decides a matter has become regulator-facing, the person who signs the cover letter, the mailbox that receives the acknowledgement, the RACI row that says who is accountable for the relationship. That surface moves early. The control surface moves late, or not at all.

So split the work into two streams and staff them differently. Re-pointing escalation is a governance and legal task with an IT dependency: contact registers, distribution lists, the escalation matrix inside your ITSM tool, the on-call runbook that names a body to notify at 2 a.m. That is finite, it is cheap, and it should be done. Re-pointing controls is an engineering task, and it starts only where the Authority has actually named a target. Where it has — and the capital framework in the last section is the clearest case — you build, on the published timeline, and you resource it properly. Where it has not, you wait, because building toward a guess is how you end up with two control sets and no evidence for either.

I have reported into a board of directors and into an executive committee, and the pattern held in both rooms: the body above you tolerates ambiguity about future requirements far better than it tolerates ambiguity about who picks up the phone. Fix the phone tree first, then go back to the roadmap.

This is the moment your previous five years of operating discipline get graded, and the grade is binary. If your evidence is structured, re-addressing it is an afternoon. If it lives in inboxes and personal spreadsheets, it is a quarter. Nothing in between.

Structured means a service catalog where every service has a named owner and a documented dependency chain, so you can query which services carry regulatory exposure instead of convening a workshop to guess. It means SLA records generated from ticket data rather than assembled by hand at month end. It means access reviews with timestamps and named approvers held in a system rather than in an email thread that ends with someone saying approved. It means Power BI reporting built on a model, so changing one label changes it everywhere at once instead of in every saved copy that repeated it. It means vendor scorecards that already carry a regulatory column, so you know which contracts to open first.

Unstructured means the supervisor’s name was typed as free text into documents nobody inventoried, by people who have since left, across years nobody logged. There is no query for that. There is only reading.

I have run both kinds of migration. Through the Odoo 15 to 18 programme and the Microsoft 365 tenant and domain transition, the work that finished on schedule was always the work where the data had a shape and the exceptions were already known. The work that overran was always the work where someone had promised the number would be easy to find. Structure is not a compliance virtue. It is an option you buy in advance against every future change you could not predict, and a change of supervisor is precisely the change nobody put in the plan.

I work at a Tadawul-listed insurance and fintech group. That sentence carries a compliance consequence people outside these organisations consistently underestimate: only insurance-related competencies moved to the Insurance Authority. SAMA did not go anywhere. It remains the central bank, and it remains the supervisor for everything on the financial side that was never part of the transfer.

So a group operating across both does not swap one regulator for another. It holds both at once, over shared infrastructure. The same identity platform, the same network, the same FortiGate and Sophos estate, the same SOC, the same ticket queue, and frequently the same three engineers. Your control environment is singular and your supervisory map is plural. The mistake is letting the singular infrastructure make you careless about the plural map, because that is how a single generic policy document ends up satisfying neither reader properly.

Practically, tag services in the catalog by supervisory exposure rather than by the department that requested them. Some are insurance-facing, some are financial-services-facing, some are both, and a few are neither and should stop being described as though they were. Then keep PDPL and the NCA in a separate column entirely. Personal data obligations and national cybersecurity expectations sit outside this transfer and were not touched by it. A change of supervisor in one regime does not renumber the others, and I have watched teams burn weeks assuming it did.

Anyone operating across insurance and fintech deals with both supervisors simultaneously. That is my position, not a hypothetical, and it is worth saying plainly, because most of the guidance circulating in this market was written by people who only ever had to satisfy one of them.

The persistence rule was never a permanent state. It was the starting condition, and the Insurance Authority has been changing it since — selectively, in named areas, on published timelines. That is exactly the pattern I argued for three sections ago: controls do not get re-engineered wholesale, they get re-pointed, and then in named areas they get replaced on a schedule. So look at what the pattern has actually produced.

In August 2025 the Authority issued a circular requiring all foreign reinsurance companies to register on its designated digital platform, with a deadline of 1 March 2026. That deadline has passed. Notice the shape of the obligation: not a rewrite of your control environment, a registration discharged through a platform. For IT that is an onboarding and records problem — who registered, on whose credentials, where the confirmation lives, and whether your own partner records agree with the Authority’s. If you cannot answer that today in a minute, that is the staleness problem from section two wearing a different coat.

The one that matters most to anyone reading this as an IT leader is capital. The Authority is moving the market to a risk-based capital framework: pilot implementation runs during 2026 alongside the current regime, with full rollout in January 2027. During the parallel run, insurers must calculate solvency under both the new and the current frameworks, per the Authority’s guidelines. Most of 2026 is already behind us and January is roughly four months away.

Read that as an actuarial exercise and you have handed it to the wrong team. Calculating the same position under two frameworks for a full year is a data problem before it is a capital problem: two models over one set of source data, two reporting paths, a reconciliation between them that somebody has to own by name, and version discipline strict enough that in December you can still say which framework produced which number, from which extract, on which date. Then a controlled cutover in January. Lineage, versioning, dual-running, cutover — that is my job description with a different noun in front of it. If your parallel run is a spreadsheet maintained by two people who also have day jobs, you do not have a parallel run. You have a reconciliation you will discover in December.

What is genuinely still open is the law itself. The Authority published a draft Insurance Law for public consultation; the consultation closed on 22 July 2025, and the draft is being prepared for submission to the legislative authorities. It is not law yet. I do not know what the final text will say or when it will arrive, and I will not build toward a guess about it. That is a real open question rather than an unresearched one, and the difference is worth stating to a committee in exactly those words.

So the honest position in August 2026 is neither “nothing has changed” nor “everything has.” Two things have landed, with dates you can check. One is drafted and pending. Everything else still runs on the SAMA and CHI rulebook until it does not. The organisations that will handle the rest of this well are not the ones with the best prediction. They are the ones that made changing the name cheap, and that made running two versions of a number, briefly and provably, something they already know how to do.