You Cannot Unmake the Tenant: Standing Up IT for a New Group Entity in Saudi Arabia

Most technology leadership writing assumes an estate. It assumes you inherited servers, a directory, a ticket queue, three contracts you did not sign, and a decade of decisions made by people who have since left. What follows is migration advice: how to rationalize, how to consolidate, how to retire. None of it applies to a company that does not exist yet.

Standing up the technology function for a new group entity is a different discipline, and the thing people get wrong is assuming it is the easier one. Greenfield removes migration risk and replaces it with sequencing risk, which is worse. Migration risk shows up as a failed cutover you can roll back. Sequencing risk shows up four months later as a decision you cannot unmake. There is no legacy to carry. There is also no identity provider, no domain, no mailbox, no ticket queue, no vendor contract, no asset register, no evidence trail, and nobody whose job it is to notice that none of those exist.

And there is a date. The legal registration date does not move for you. Saudi commercial registration has been through its own reform — the new Commercial Register Law came into force on 3 April 2025, registrations no longer carry an expiry date, and the company confirms its information annually instead. That is a genuine simplification, and it helps you not at all with the part that matters: on the day the entity legally exists, obligations attach to it, and the technology function either exists on that day or is late from its first hour.

Everything else assumes them. The finance system needs users. The service desk needs a queue people can email. The vendor portal needs a company address to send the contract to. Onboarding needs somewhere to put an account. Every one of those resolves back to two objects: an identity provider that says who someone is, and a domain that says where they are. Build anything ahead of those and you will build it twice.

The order is partly not yours to choose. A com.sa domain is registered through SaudiNIC at the Communications, Space and Technology Commission, and eligibility rests on a valid commercial registration issued in Saudi Arabia, or a locally registered trade name or trademark. The domain cannot precede the entity. So the front of the sequence is fixed for you: legal registration, then domain, then tenant, then identity, then everything anybody actually asked you for. Whoever is pushing a system go-live ahead of that is asking you to create accounts you will have to delete.

Then the Microsoft-specific traps, worth naming because they are permanent and because they are made in a text box in the first ten minutes. The initial onmicrosoft.com domain cannot be renamed or deleted, and your SharePoint URLs are derived from it. You can add further onmicrosoft.com domains and promote one to be the fallback, but you are limited to five in total, none of them can ever be deleted, and changing the SharePoint domain name is a separate operation with its own eligibility limits.

I have approved one of those names myself, on the understanding that it was a placeholder and we would tidy it up later. There is no later. It is in the SharePoint URLs, it cannot be deleted, and I now treat opening the trial as an architecture decision rather than a procurement one.

There is a live commercial consequence too. Since 15 October 2025 Microsoft has limited sending from onmicrosoft.com domains to 100 external recipients per organization per rolling 24 hours. A new entity that has not yet verified its custom domain cannot email its own market. That is not a governance risk. It is a launch-week outage with a published policy behind it, and it is avoided entirely by settling the domain before anyone is issued a mailbox.

Sort every decision in front of you into two piles: things you can change on a Tuesday, and things that would need a migration, a regulator conversation, or a new legal entity to undo. Make the second pile slowly, in writing, with the names of the people who agreed.

There are five things in it.

Start with the tenant country. When a Microsoft Entra tenant is created, the country entered at sign-up sets the Default Geography, and once the tenant exists that Default Geography cannot be changed. Microsoft currently lists Saudi Arabia among future local region geographies rather than current ones, and Saudi Arabia does not appear in its table of durable commitments on data location by geography. Read the consequence plainly: for the core workloads, a Saudi entity created today cannot contract a durable commitment to hold that data at rest inside the Kingdom, and the tenant you create in week one is the boundary of every future answer. Microsoft publishes no date for that region.

Then the identity provider. Whichever directory issues the first account becomes the thing every application federates to, every vendor integrates with, and every access review is run out of. Changing it later is not a configuration change, it is a re-onboarding of every system you signed in the interim.

Then the finance system of record. I get asked to defer this one more than any other. The first posted transaction is the beginning of the entity's audit trail. Move that system in year two and you are migrating a tax history, not a database.

Then naming, which gets treated as trivial because it is typed rather than architected. The tenant name, the mail domain, the entity code in the group chart of accounts, the service account convention, the site naming standard. Cheap to decide, expensive to change, which is the exact profile of a decision that should be made in week one at a senior level and then left alone.

And the first vendor contracts, which is the one people fight me on. In the Saudi financial sector the outsourcing expectation is explicit that accountability does not transfer to the supplier, and the contract is expected to carry breach-notification windows, audit rights, service levels, localization and cross-border data terms, approval for subcontracting, and an exit strategy. A contract signed in week two without an exit clause is an irreversible decision wearing a renewal date. The first three contracts become the template every later contract is compared against, and they get signed in the weeks when nobody has time to read anything.

Inside a group you always have a third option, and it is the one that gets taken by default rather than on purpose: borrow it from the parent. Put the new entity in the group tenant. Point it at the group service desk. Extend the group's endpoint management, monitoring, firewall estate and Microsoft agreement over it. Fast, cheap on day one, and frequently correct.

What it is not is free. Every borrowed platform merges the two entities' control surface and their evidence surface. A borrowed identity provider means the parent's conditional access policy is the new entity's conditional access policy, including the clauses written for a business the new entity is not in. A borrowed ticket queue means the new entity's service reporting is a filter applied to somebody else's data, which holds up fine until the day someone asks for it as a standalone artifact. A borrowed vendor contract means the new entity's supplier relationship is a line item in an agreement it is not party to.

So the rule I use prices separation, not setup.

Borrow what is cheap to separate later: endpoint management, monitoring, service desk tooling, most license agreements. Stand up separately what is expensive to separate later: identity, finance, and anything that will hold personal data. Those three are expensive because separating them means moving records that have history, and history is the part you cannot recreate.

The rule fails on the service desk, and I have stopped pretending otherwise. The tooling is genuinely cheap to separate: a new instance, a new queue, two weeks. The ticket history behind it is not, and the ticket history is the only evidence you have that a service was ever delivered at the level you claimed. So I borrow the tool and refuse its default configuration: the legal entity is a mandatory field on the ticket from ticket one, not a tag somebody backfills the week the first audit asks for it. That is the one place where I pay the setup cost the rule tells me to avoid.

Personal data deserves its own line rather than a mention. Saudi Arabia's Personal Data Protection Law was issued by Royal Decree M/19 of 16 September 2021, amended by Royal Decree M/148 of 27 March 2023, came into effect on 14 September 2023, and controllers had until 14 September 2024 to bring themselves into compliance. The Saudi Data and Artificial Intelligence Authority maintains a national register of controllers, and registration is required where the controller processes sensitive data or where its main activity is based on processing personal data. The question is therefore not which system holds the employee record. It is which legal entity is the controller of it. Answer that on paper before the first employee record exists, because after that it is an argument rather than a decision.

The alternative to an evidence trail is archaeology, and archaeology is charged to your team at the worst possible moment. Everything a first audit asks for — who approved this, when, against what, and where is it written — is nearly free to capture as it happens and nearly impossible to reconstruct a year later out of people's memory of a launch.

Tax is the clearest case because the clock is not negotiable. The e-invoicing generation phase run by the Zakat, Tax and Customs Authority has applied since 4 December 2021 to all taxpayers other than non-residents, and to any party issuing tax invoices on their behalf. There is no onboarding grace period for a new company: you are in it the moment you are VAT-registered. The integration phase runs in waves with at least six months' notice, and the waves have walked steadily down the revenue scale. Wave 25 covers taxpayers whose VAT-taxable revenue exceeded SAR 187,500 in 2022, 2023, 2024 or 2025, with integration required by 1 February 2027. A new entity should assume it lands in a near-future wave and build to the integration specification now, rather than ship a generation-only stopgap it has already scheduled itself to replace.

The artifacts are unglamorous and cost about an hour each. A decision register with a date, an owner, and what was rejected. The tenant creation record, including who created it and which country was entered. A vendor register carrying a regulatory column from its first row. An access model written before the first ten accounts rather than inferred from them. The first access review run in month three, when it is twelve people and takes an afternoon, so the practice exists before it matters.

At Tbar Holding I built a service catalog of more than a hundred services where nothing existed before, and every service in it carried a service level. That company had no service level agreements at all before I wrote them; the catalog and the first commitments behind it were one piece of work. Writing the commitment at the same moment you create the service costs an extra paragraph. Retrofitting a commitment onto a service that has run unmeasured for two years costs a quarter and produces a weaker number, because by then everyone has an opinion about what the service already does.

The launch date is fixed and the control expectations are not scoped to it. You will be assessed later against a floor that applies to the entity, not to how new it was when you built it. Pretending otherwise is how a new company acquires eighteen months of technical debt in ninety days.

Know that floor, and know that it is already being enforced. The Personal Data Protection Law is not a future obligation. It has been in force since 14 September 2023, the compliance grace period closed on 14 September 2024, and in the twelve months to mid-January 2026 SDAIA's violations committees issued 48 decisions confirming breaches of the law, with fines reaching SAR 5 million and doubling for repeat violations. Look at the clocks rather than the fines, because the clocks are what catch a new entity. Once the Authority notifies you of an alleged violation, you have five days to file your response with the committee; the parties must be notified of the committee's decision within fifteen days of its approval; and an appeal runs to sixty days. A ninety-day-old company gets the same five days as a twenty-year-old one.

So the question that belongs in week one is unglamorous and specific: which mailbox receives that notification, who monitors it, and who is authorized to answer. If that is unassigned on the day the entity is registered, the five days start running against nobody.

The cybersecurity baseline behaves the same way. The National Cybersecurity Authority's controls for private-sector entities that are not critical national infrastructure, NCNICC-1:2025, scope entities by size rather than by any review cycle. The larger category is more than 250 full-time employees or revenue above SAR 200 million; entities with between 6 and 249 employees, or revenue between SAR 3 million and SAR 200 million, sit in the smaller one. I am not going to print a control count for either. The totals in circulation do not agree, and the draft the Authority hosted for consultation does not match the summaries written about the published version, so I take the count from the text I am being assessed against and not from anybody's summary of it. Read the trigger carefully, because it is a size trigger, headcount or revenue, with no stated assessment cycle attached to it: a new subsidiary crosses into the larger category on the day it staffs up or the day it books the revenue, not at some later review. And those controls reach straight into the decisions this article is about: data classification, tenant separation, and return of data in usable format on termination. The Controls state no compliance deadline, and I will say that out loud, because the vendor content around them manufactures one. I do not know when this becomes enforceable against a specific entity. What I will not do is treat that as permission to build something expensive to bring up to it.

Which returns the tenant decision to what it actually is — a controls decision, not a preference. The Cloud Cybersecurity Controls, current at CCC-2:2024, bind cloud service tenants and not only cloud service providers, and the Authority has updated them in respect of data localization requirements. The version you cite therefore matters: quoting CCC-1:2020 at a supplier is quoting a superseded document to somebody who may well know it. In the financial sector, hosting outside the Kingdom requires prior approval from the Saudi Central Bank, which is why providers serving that sector default to domestic hosting. Now set that beside the fact from earlier: the Default Geography is fixed when the tenant is created and cannot be changed afterwards. Region is not an infrastructure preference you revisit in year two. It is a regulated, one-way decision made in the first week by whoever happened to be in the room.

On hiring I say less than people expect me to. Saudization rates are set profession by profession by ministerial decision, and I went looking for one written for information technology roles and came back without it. So I plan headcount against the decision in force for the professions I am actually posting, checked on the day I post them, and I do not repeat the percentages that circulate in recruitment blogs.

A launch does not end with everything built, and any plan that says it does is a plan somebody will be embarrassed by in month five. What it ends with is a deferral list: every item on it carrying the control the entity does not yet meet, the reason the deferral was accepted, and the date it comes back to the table.