1. Define the acquisition decision
The board should begin with the customer decision the target enables. Regulated institutions do not buy sovereignty as an abstract attribute. They approve a particular workload, data class, model, operating arrangement and supplier chain under specified legal, security and resilience conditions. The transaction thesis should therefore identify which approvals become faster, which risks become controllable and which services become commercially repeatable because the target is owned.
Possible theses include access to regulated customers, ownership of domestic infrastructure, control of encryption and identity services, a certified operating model, scarce security capability, an AI-governance platform, a managed-service channel or a regional consolidation base. Each thesis requires distinct evidence. Customer-access claims require executed contracts, acceptance records, renewals and collections. Technology claims require reproducible architecture and control tests. Infrastructure claims require title, capacity, power, network and continuity evidence.
The board should compare acquisition with licensing, partnership, minority investment, joint venture and internal build. Ownership may be justified where the buyer needs control over security operations, customer obligations, regulated personnel, intellectual property and integration priority. A narrower arrangement may be proportionate where the benefit is access to domestic capacity or a distribution relationship that can be secured contractually.
Transaction timing should follow the evidence. Customer contracts and architecture can be reviewed before signing. Regulatory acceptance, service migration and renewal may only become observable later. Base consideration should follow transferable rights and demonstrated performance at closing. Deferred consideration should follow defined customer, control and integration outcomes.
The proposed chain connects a customer obligation to evidenced controls, service acceptance and collected cash.
2. Define the sovereign-security stack
The sovereign-security stack is the complete set of legal rights, physical assets, technical controls, operating processes, people and evidence required to run an accepted workload within its governing constraints. It should be described as an architecture and operating model rather than a marketing category.
The physical layer includes data centres, power, cooling, connectivity, security zones and recovery sites. The platform layer includes compute, storage, containers, model-serving infrastructure, observability and orchestration. The control layer includes identity, privileged access, encryption, key management, secrets, configuration, vulnerability management, logging, incident response and change approval. The AI layer includes data lineage, model provenance, evaluation, release approval, runtime monitoring and model retirement.
The governance layer binds these components to customer and regulatory obligations. It includes contracts, data-processing instructions, outsourcing approvals, audit rights, subcontractor controls, personnel requirements, records, reporting and exit. A provider can own infrastructure and still lack the rights or processes needed for a regulated customer. A managed-service provider can use third-party infrastructure and still create value if it controls obligations, evidence and service outcomes under enforceable agreements.
The buyer should map each claimed sovereign feature to its legal owner, operator, evidence source, customer benefit, complete cost and failure consequence. Features that cannot be traced to an accepted customer decision should not receive a valuation premium merely because they support the label.
The stack links physical infrastructure, cloud platform, cyber controls, AI governance, regulated operations and commercial evidence.
3. Establish the regulatory perimeter
The GCC is a regional market with distinct national and sectoral rules. A buyer should identify the legal entity, customer type, workload, data class, processing purpose, hosting location, support location, subcontractor chain and supervisory authority for every material service. A single regional policy cannot substitute for this mapping.
In the UAE, the Central Bank's outsourcing standards require board responsibility, due diligence, security, monitoring, data protection and supervisory access. Its enabling-technology guidance addresses cloud governance, auditability, materiality, resilience, data protection and exit. The UAE federal personal-data regime, the ADGM framework and the DIFC framework create separate questions concerning scope, controller and processor obligations, security, transfers and rights.[1][2][3][4][5][6]
Saudi requirements combine national cybersecurity controls, sector rules and personal-data obligations. The National Cybersecurity Authority's Essential Cybersecurity Controls address hosting and cloud use, including data classification, separation and domestic hosting for covered organisations. SAMA's Cyber Security Framework addresses outsourcing and cloud controls for member organisations. Saudi personal-data rules define controller and processor duties and provide mechanisms for transfers subject to stated conditions and safeguards.[7][8][9][10][11][12]
Qatar Central Bank's cloud and technology-risk requirements address approval, local processing, cryptographic control, evidence, testing and contractual controls for relevant entities. Bahrain's central-bank guidance addresses cloud outsourcing controls. Oman has a personal-data law, executive regulation and a 2026 cloud-first policy for government entities that couples cloud adoption with cybersecurity, data-protection and risk-management requirements.[13][14][15][16][17][18]
The acquisition team should record the precise version and applicability of every requirement. It should distinguish law, regulation, supervisory instruction, contractual promise, policy and customer preference. The distinction affects remediation priority and the evidence needed to maintain service.
| Jurisdiction or framework | Selected diligence lens | Evidence to obtain | Transaction consequence |
|---|---|---|---|
| UAE banking | outsourcing governance, due diligence, auditability, data protection, resilience and exit | approvals, risk assessments, contracts, audit records and exit tests | customer eligibility and remediation reserve |
| Saudi national controls | classification, separation, hosting, cloud controls and continuing review | scope analysis, architecture, control evidence and exceptions | addressable workload and operating design |
| Saudi financial sector | third-party, outsourcing and cloud cybersecurity | SAMA approvals, maturity evidence, contracts and monitoring | access to regulated financial customers |
| Qatar financial sector | prior approval, local processing, key control and security testing | approval record, key architecture, evidence reports and test rights | service design and customer acceptance |
| Bahrain banking | cloud-outsourcing governance and controls | board policy, risk assessment, provider diligence and continuity evidence | contract readiness and control cost |
| Oman government and personal data | cloud-first eligibility, cybersecurity, protection and transfer conditions | workload classification, provider licence, privacy records and review | public-sector eligibility and localisation design |
Requirements vary by entity, sector, workload and date; qualified local advice is required.
4. Convert regulatory obligations into product requirements
A regulation becomes commercially relevant when it changes product design, operating responsibility or customer acceptance. The buyer should create an obligation-to-control matrix for each material customer cohort. The matrix should state the obligation, applicability decision, control owner, technical implementation, evidence, reviewer, exception process and contractual allocation.
Data residency should specify what must remain where. Training data, prompts, model weights, embeddings, logs, telemetry, backups, support exports, security events and metadata can follow different paths. A claim that production data remains in-country may omit backups, support tooling or model-improvement data. Each path should be traced end to end.
Supervisory access should be designed before a contract is signed. Regulators and customers may need records, reports, audit access, test evidence or direct information rights. The provider should know which evidence it can deliver, which evidence belongs to an infrastructure supplier and which restrictions apply. Contractual audit rights without accessible evidence can fail in practice.
Exit requirements should be treated as product features. The provider should demonstrate export formats, key transfer or destruction, workload migration, data deletion, evidence retention and transition assistance. Exit feasibility affects customer approval, renewal and transaction value because a buyer inherits the obligation to support it.
5. Define regulated-customer access
Regulated-customer access is the repeatable ability to win, onboard, operate, renew and collect from customers whose technology decisions are subject to public law, supervisory expectation, formal risk governance or critical-infrastructure obligations. A logo or pilot does not establish this capability.
Access begins with eligibility. The provider may need a domestic entity, licensed partner, approved data centre, security certification, personnel screening, insurance, financial capacity or a recognised audit report. The buyer should verify which conditions were required in each procurement and whether they remain valid after a change of control.
Onboarding evidence includes security questionnaires, architecture approvals, risk acceptances, data-protection assessments, outsourcing notifications, contractual negotiations, penetration tests, business-continuity tests and implementation acceptance. The acquisition team should measure duration, seller effort, customer effort, exceptions and rework. A long onboarding period can create a defensible relationship while consuming unpriced engineering capacity.
Operating access requires continuing compliance, incident communication, service reporting, evidence delivery, change approval and audit support. Renewal depends on performance and on the customer's willingness to repeat these processes. Collected cash depends on accepted milestones, invoice documentation, budget timing and dispute resolution. Each stage should be measured separately.
| Stage | Required evidence | Quality test | Valuation implication |
|---|---|---|---|
| Eligibility | licence, entity, certification, insurance and approved hosting | still valid after change of control | addressable market boundary |
| Procurement | tender, security response and commercial submission | reusable content and win attribution | sales efficiency |
| Approval | risk, privacy, outsourcing and architecture decisions | exceptions are explicit and time-bound | delivery certainty |
| Deployment | accepted configuration and migrated workload | matches approved design | service credibility |
| Operation | control evidence, incidents, service levels and audit support | repeatable without founder intervention | recurring margin |
| Renewal and collection | renewal, invoice acceptance and bank receipt | cohort retention and cash conversion | sustainable value |
Access is demonstrated by repeated decisions and cash outcomes rather than customer names alone.
6. Build the demand-evidence ladder
Strategic demand is an important starting signal. National AI programmes, cloud policies, data-residency expectations and regulated-sector digitisation can expand the opportunity set. They do not establish a target's revenue. The buyer should convert market narratives into a documented ladder of customer evidence.
The ladder begins with stated policy and an identifiable customer problem. It progresses through funded procurement, qualified opportunity, approved solution, executed contract, deployed workload, accepted service, invoiced revenue, cash collection and renewal. Each step should have an owner, date and primary record. Forecasts should state which step each opportunity has reached.
Pipeline classification should prevent a memorandum of understanding, pilot, framework agreement and committed order from being treated as equivalent. Framework agreements may establish terms while leaving volume unfunded. Pilots may prove technical feasibility while failing procurement or budget tests. Strategic partnerships may create introductions without customer acceptance.
The buyer should analyse conversion by customer cohort, service, jurisdiction and source. It should also inspect losses. A target that repeatedly loses after security review has a different problem from one that wins approval but cannot deploy. A target that deploys successfully but collects slowly has a financing problem that belongs in valuation and working-capital planning.
Counts are management assumptions for method demonstration and do not represent observed market data.
7. Map architecture to residency and control
Architecture diligence should begin with actual data flows and administrative paths. Diagrams prepared for sales may omit monitoring, support, backup and model-development systems. The buyer should reconstruct the deployed environment from cloud accounts, network configuration, identity records, repositories, container registries, model endpoints, logging systems and customer-specific overlays.
Residency has several dimensions. Storage location covers active and backup copies. Processing location covers compute, inference, training and support analysis. Administrative location covers people and systems that can access or change the environment. Legal location concerns contracting entities and applicable jurisdiction. Control location concerns who can authorise, decrypt, restore, export or delete data and models.
The provider should classify every service component as customer-controlled, target-controlled, infrastructure-provider-controlled or jointly controlled. Shared responsibility should be recorded at control level. A generic cloud matrix may not cover a managed model endpoint, third-party security tool or subcontracted operations centre.
The buyer should test boundaries by attempting approved and prohibited actions. It can verify whether an overseas administrator can access data, whether logs leave the country, whether a backup can be restored domestically, whether a revoked account loses every path and whether the customer can obtain evidence without seller assistance. Results should be retained as transaction evidence.
| Layer | Core question | Evidence | Failure mode |
|---|---|---|---|
| Data | where are active, backup, derived and logged records processed | flow maps, configuration, storage inventory and tests | hidden transfer or incomplete deletion |
| Models | who can train, modify, approve and serve each model | lineage, registry, approvals and endpoint records | unapproved model or external dependency |
| Identity | who can authenticate and exercise privilege | identity architecture, role records and access reviews | uncontrolled support or orphaned access |
| Keys | who creates, holds, rotates, recovers and destroys keys | key design, ceremonies, logs and recovery tests | formal residency without practical control |
| Workloads | how are customers and environments separated | tenancy design, network policy and isolation tests | cross-customer exposure |
| Evidence | can customer and regulator obtain reliable records | log integrity, reports, audit rights and retrieval tests | unprovable compliance |
| Continuity | can service recover and exit within obligations | recovery, export, deletion and transition tests | customer lock-in without resilience |
Each layer requires evidence of location, authority, operation and recoverability.
8. Control identity, privilege and cryptographic authority
Identity and cryptographic control often determine whether a locally hosted service is operationally sovereign. The buyer should identify every human and machine identity that can administer infrastructure, deploy code, change models, access logs, manage backups or alter security policy. Privilege should be granted through controlled roles with strong authentication, approval, time limits and review.
The diligence team should inspect federation, break-glass accounts, vendor support, service accounts, automation tokens and inherited cloud roles. It should sample joiner, mover and leaver events and verify that privilege is removed from every connected system. Founder-held credentials and informal emergency access are transaction risks even when normal access reviews appear complete.
Cryptographic authority should be mapped separately. The team should determine who generates, stores, rotates, recovers and destroys keys; where those activities occur; and which party can compel or execute decryption. Customer-managed keys, provider-managed keys and external hardware-security modules create different responsibilities and costs. Key control should match contractual and regulatory promises rather than a preferred architecture label.
Tests should include key rotation, lost-key recovery, administrator revocation, certificate expiry, backup restoration and a simulated exit. Evidence should show both successful operation and controlled failure. A security design that cannot recover safely may satisfy an isolation objective while creating unacceptable continuity risk.
9. Secure the AI lifecycle
Cyber-AI hosting adds assets and decisions that conventional infrastructure reviews may miss. Training data, base models, adapters, prompts, evaluation sets, vector stores, model weights, serving images and safety policies should be inventoried and linked to each released system. The NIST AI Risk Management Framework, its Generative AI Profile and the secure-development guidance issued by the UK National Cyber Security Centre provide useful structures for governance, testing and lifecycle security.[31][32][33][34]
The buyer should distinguish infrastructure security from model security. Infrastructure controls protect accounts, networks, systems and data. Model controls address training-data manipulation, model extraction, prompt injection, unsafe tool use, insecure output handling, dependency compromise, excessive agency and performance drift. An acquired provider may offer strong hosting while depending on external models and tools whose controls do not satisfy customer obligations.
Every production model should have an approved purpose, owner, data basis, dependency record, evaluation, release decision, deployment configuration and monitoring plan. Customer-specific restrictions should follow the model into runtime. Changes to prompts, tools, retrieval data or safety policy can alter behaviour and should pass an appropriate approval gate.
The buyer should reproduce selected model releases and rerun sealed evaluations. It should test logging, incident reconstruction and model rollback. It should also inspect whether customer data is used for training or service improvement, how opt-outs are enforced and whether derived artifacts remain after source data is deleted.
| Lifecycle stage | Required control | Evidence | Acquisition test |
|---|---|---|---|
| Data preparation | approved sources, purpose, minimisation and transformation lineage | data register, rights, pipeline and review | trace sample output to governed sources |
| Model selection | approved model, supplier terms and dependency assessment | model record, contract and risk decision | match runtime artifact to approval |
| Evaluation | versioned tests, thresholds and accountable acceptance | sealed sets, results and sign-off | rerun critical evaluations |
| Deployment | protected artifact, configuration and release authority | digest, package, change record and endpoint | reconstruct production release |
| Operation | monitoring, abuse control, logging and incident response | events, alerts, cases and service reports | simulate detection and rollback |
| Retirement | export, retention, deletion and successor control | retirement plan and destruction evidence | complete a controlled removal |
Control evidence should follow each model and customer environment throughout the lifecycle.
10. Test workload isolation and operational resilience
Multi-tenancy can improve economics while creating concentration and separation risk. The buyer should identify every boundary between customers, environments, data classes, administrative planes and recovery systems. Logical separation should be supported by configuration, policy, monitoring and testing. Physical separation may be required for specific workloads, yet it should not be assumed from the sovereign label.
Isolation tests should address compute, storage, network, caches, queues, logging, support tools, model endpoints and backup. The team should examine noisy-neighbour effects, resource exhaustion, side-channel exposure and the consequences of a shared control-plane failure. Customer-specific controls should be compared with the common platform to identify costly exceptions.
Resilience should be tested against the actual service promise. Redundant components within one facility may not cover a site failure. Multiple sites may share power, connectivity, software, identity or operating teams. A domestic-only architecture can create a national-residency benefit while concentrating disaster risk. The solution should reconcile residency, recovery, capacity and customer obligations.
The buyer should review recovery-point and recovery-time objectives, observed incidents, test results, unresolved actions and customer communications. It should perform selected restoration and failover tests. Recovery should include models, keys, configuration, logs and evidence, not only application data. The complete cost of resilient capacity belongs in unit economics.
11. Make auditability an operating capability
Auditability is a product capability when customers and supervisors require evidence before approval, during service and after an incident. The target should know which records exist, how they are protected, how long they are retained, who can retrieve them and which party owns them. Evidence should be generated by normal operation rather than assembled manually for each review.
The evidence set may include risk assessments, architecture decisions, access reviews, key events, vulnerability results, penetration tests, incident records, changes, service levels, continuity tests, subcontractor reviews and data-deletion confirmations. Each record should have a source, owner, timestamp, integrity protection and retention rule.
Independent assurance can support customer due diligence, but its scope should be understood. A certification or assurance report may cover one entity, site, service, period or control set. It may exclude customer-specific configurations, AI models, subcontractors or recent changes. The buyer should reconcile each external report with the acquired perimeter.
Manual evidence production can be commercially significant. The team should measure hours spent per customer review, response reuse, engineering interruptions, external-audit cost and unresolved exceptions. A target may report attractive software gross margins while absorbing assurance work in engineering or founder time.
12. Analyse customer cohorts and contract quality
Regulated customers should be grouped by jurisdiction, sector, service, workload materiality, control pattern, procurement route and contract maturity. Revenue concentration alone does not show the difficulty of maintaining each relationship. A small critical-infrastructure account may create extensive operating obligations and reusable credibility. A large public-sector project may depend on a non-recurring implementation budget.
The buyer should reconcile contracts, orders, acceptance certificates, invoices, credit notes, bank receipts and renewals. It should identify termination rights, change-of-control provisions, subcontracting restrictions, data-location commitments, service levels, liability, audit rights, price adjustments and transition duties. Contract rights should be compared with actual operations and sales claims.
Cohort analysis should measure time to contract, time to acceptance, annual recurring revenue, implementation revenue, consumption, renewal, expansion, support effort, evidence effort, incident cost, cash collection and contribution after complete cost. Customers with similar headline revenue can have materially different value.
The team should also examine procurement dependence. Revenue won through a founder relationship, a specific local partner or a temporary national initiative may not be repeatable. A durable access capability should survive personnel change and should be supported by institutional references, reusable evidence and a qualified pipeline.
Amounts are management assumptions in USD millions for method demonstration.
13. Reconstruct complete delivery economics
Complete delivery cost should include domestic infrastructure, reserved capacity, connectivity, licences, model access, security tools, key infrastructure, operations, customer-specific engineering, compliance, assurance, incident response, insurance, subcontractor management, implementation, support, working capital and exit obligations. Cost should be assigned to the service and cohort that causes it.
Infrastructure commitments deserve particular attention. The target may reserve racks, accelerators, storage or network capacity before customer demand is contracted. Minimum commitments can improve availability and pricing while creating utilisation risk. The buyer should reconcile capacity, contracted demand, active workloads, billable usage and collected cash.
AI services can introduce variable costs that do not follow conventional hosting assumptions. Model inference, vector search, security scanning, human review and external API usage may scale differently. Customer-specific isolation and key arrangements can reduce pooling benefits. The team should model cost under observed workload patterns and stated contractual limits.
Implementation labour should be separated from recurring operation. Repeated custom integration may indicate a consulting business rather than a scalable platform. This can still be valuable, but the valuation multiple, staffing model and integration plan should reflect it. Unbilled evidence work and security exceptions should be included.
Working capital can also be material. Government and regulated customers may pay after formal acceptance and documentation. Infrastructure suppliers may require deposits or monthly settlement. The acquisition model should include timing of cash receipts, tax, guarantees, performance bonds and dispute reserves.
14. Separate strategic demand from repeatable revenue
Strategic demand describes the policy, security and operational reasons customers may seek domestic or controlled cyber-AI services. Repeatable revenue requires a proposition that can be sold, approved, delivered, supported, renewed and collected with predictable effort. The acquisition case should connect these concepts without treating them as the same evidence.
The buyer should first identify the recurring customer problem. Examples include approving a regulated AI workload, retaining cryptographic authority, evidencing national data controls, meeting supervisory access requirements or operating a sensitive model without external administrative access. The proposition should state the promised outcome and the customer's continuing responsibility.
Sales repeatability can be tested through cohort conversion, sales-cycle variation, reuse of architecture and evidence, partner dependence and win attribution. Delivery repeatability can be tested through configuration variance, implementation hours, exception rates, service-level performance and support effort. Renewal repeatability can be tested through customer outcomes, switching cost, price realisation and collections.
The buyer should challenge revenue labelled recurring when the underlying contract includes large periodic migrations, mandatory recertification, hardware replacement or customer-specific engineering. It should also identify recurring support obligations attached to one-time licence or build revenue. Cash-flow classification should follow economic substance.
| Revenue type | Evidence of quality | Principal risk | Valuation treatment |
|---|---|---|---|
| Contracted hosting | committed capacity, acceptance, service levels and collections | under-utilisation, concentration and renewal | value on retained contribution and duration |
| Managed security | recurring scope, measurable operation and staffed delivery | labour intensity and incident exposure | value on cohort margin and operating maturity |
| AI control plane | adopted workflow, model coverage and continuing decisions | shelfware, dependency and rapid obsolescence | value on use, renewal and replacement cost |
| Implementation | defined deliverable, acceptance and cash | non-recurring effort and scope dispute | value separately from recurring base |
| Framework agreement | enforceable terms and funded orders | uncommitted volume | exclude unfunded pipeline from base value |
| Strategic partnership | qualified referrals and conversion evidence | relationship dependence | value only observed contribution |
Classification follows evidence, customer acceptance and complete cost.
15. Design the diligence programme
The diligence programme should connect commercial, regulatory, technical, operational and financial evidence. Separate workstreams can miss contradictions. A sales presentation may describe domestic control while architecture shows offshore support. A compliance report may show policy maturity while incident records reveal repeated exceptions. A revenue schedule may show recurring contracts while acceptance evidence depends on continuing custom work.
The buyer should select a representative sample of customers and workloads. The sample should cover jurisdictions, sectors, service types, contract sizes, new and renewed customers, incidents, high-margin and low-margin cohorts and significant exceptions. Population reconciliation should ensure the sample is drawn from complete customer, workload and revenue records.
For each sample, the team should trace the full chain from opportunity and obligation through architecture, control, deployment, acceptance, invoice, collection and renewal. It should reproduce selected control evidence and interview customer-facing, engineering, security, finance and legal owners. Seller explanations should be tied to primary records.
Technical tests should be proportionate and authorised. They can include identity review, key rotation, isolation test, restoration, log retrieval, model-release reconstruction, vulnerability closure and exit simulation. Results should distinguish design, implementation, operation and evidence gaps.
| Workstream | Core request | Reproduction test | Decision output |
|---|---|---|---|
| Regulatory | applicability map, approvals, notices and exceptions | trace one obligation to operating evidence | eligible perimeter and remediation |
| Commercial | pipeline, procurement, contracts, renewals and losses | rebuild selected customer journeys | repeatable access and concentration |
| Architecture | deployed diagrams, accounts, data flows and suppliers | reconcile production to approved design | sovereignty boundary and dependency |
| Cybersecurity | controls, incidents, vulnerabilities and assurance | rerun selected identity, key and evidence tests | control maturity and reserve |
| AI governance | model inventory, lineage, evaluations and releases | reproduce a regulated model release | product credibility and obsolescence risk |
| Operations | service levels, capacity, continuity and support | restore, fail over and retrieve evidence | resilience and complete cost |
| Finance | contracts, invoices, receipts, cost and working capital | rebuild cohort contribution and cash | sustainable earnings and valuation |
Requests are designed to reconcile customer claims, controls and financial outcomes.
16. Identify red flags and remediation economics
Red flags should be expressed as decision-relevant exposures. Examples include offshore administrative access inconsistent with customer promises, undocumented subprocessors, keys controlled by an unapproved party, incomplete data flows, unsupported residency claims, expired assurance, untested recovery, customer-specific code branches, founder-held credentials, incident backlogs, loss-making cohorts and revenue recognised before acceptance.
Each issue should have a population, affected customers, governing obligation, cause, interim control, permanent action, owner, time, cost, service impact and residual risk. A generic high-medium-low rating cannot support valuation or transaction terms without this translation.
Remediation cost should include engineering, infrastructure, customer communication, reapproval, contract amendment, external advice, assurance, duplicated capacity, incident response, credits, delay and working capital. It should also include lost sales and renewal risk where a control gap changes customer eligibility.
The buyer should distinguish fixable defects from architecture constraints. A missing review can be remediated through process and evidence. A product built around overseas control-plane dependency may require redesign, migration and customer reapproval. The latter can affect the core thesis and should influence price, perimeter or transaction structure.
Remediation milestones should be observable. Completion should require operating evidence and customer or regulator acceptance where relevant, not only a policy update. Consideration protection and integration funding can then follow the verified closure of defined exposures.
17. Build the valuation framework
The valuation should begin with customer-level cash generation rather than a premium attached to the word sovereign. Forecast revenue should be separated into contracted accepted workloads, contracted but unaccepted services, probable renewals, qualified funded pipeline and strategic opportunity. Each category should have distinct timing, conversion and cost assumptions.
Recurring contribution should be measured after complete delivery cost. Central infrastructure, security and assurance costs should be allocated on a defensible basis. Customer-specific isolation, key control, reporting, implementation and support should follow the customer that causes them. The model should identify capacity that remains unabsorbed under downside demand.
The buyer can use income, market and cost approaches as appropriate, while recognising the limits of each. Discounted cash flow can reflect customer, capacity and remediation scenarios if inputs are evidenced. Market multiples can provide a reasonableness check when comparables have similar revenue quality, regulation, infrastructure intensity and growth. Replacement cost can inform specific technology and control assets without establishing enterprise value by itself.[45][46][47][48][49][50]
Identifiable intangible assets may include customer contracts and relationships, developed technology, data, licences, certifications, trade names and contractual rights, subject to the relevant accounting requirements. Goodwill should not become a repository for untested claims concerning access or sovereignty. Forecasts and purchase-price allocation require specialist judgement.
Scenario analysis should vary retained customers, accepted-workload conversion, capacity utilisation, price, complete cost, remediation, working capital and terminal assumptions. The valuation memorandum should state which inputs are observed, contractual, externally sourced or management assumptions.
18. Apply a hypothetical transaction model
Consider a hypothetical provider with USD 18 million of reported annual revenue from local hosting, managed cybersecurity, AI-control services and implementation. The provider serves banks, public-sector entities and critical-infrastructure operators in several GCC jurisdictions. These figures are management assumptions used only to demonstrate the framework.
The model separates USD 4 million of non-recurring implementation revenue. It attributes USD 3 million to third-party capacity and licence cost, USD 2 million to assurance and customer-specific support, and USD 1 million to incident, credit and service reserves. Hypothetical recurring contribution is therefore USD 8 million before central corporate cost, growth investment, tax, financing and working capital.
The buyer then classifies the recurring base. USD 5 million is linked to accepted workloads under contracts extending beyond twelve months. USD 2 million relates to contracts approaching renewal, and USD 1 million depends on completion of customer approval. The model applies different retention and timing assumptions to each category.
The diligence programme identifies a hypothetical USD 3 million remediation programme covering domestic key infrastructure, control-plane separation, additional recovery capacity, customer reapproval and automated evidence production. It also identifies a potential USD 1.5 million increase in annual operating cost after removing founder intervention and allocating complete support capacity.
The decision model should compare the stand-alone case, buyer-enabled distribution, shared infrastructure, remediation delay and customer-loss scenarios. Synergy belongs in buyer value only when it has an owner, implementation plan, cost, customer dependency and measurable cash result.
Values are management assumptions in USD millions across retained recurring revenue and recurring-contribution margins.
19. Translate evidence into transaction protections
Transaction protections should follow identified uncertainty. A broad warranty cannot replace price adjustment, escrow, retention, deferred consideration or a closing condition when the exposure is measurable and central to value. The chosen mechanism should match who controls the outcome and when evidence becomes available.
Closing conditions may address material customer consents, regulatory approvals, specified control remediation, key personnel, infrastructure rights and release of security interests. Pre-closing covenants may restrict material architecture changes, subcontracting, pricing, capacity commitments and unusual access grants. The buyer should retain sufficient verification rights.
Representations can address customer contracts, data processing, regulatory compliance, cybersecurity controls, incidents, intellectual property, subcontractors, infrastructure rights, service levels and financial records. Disclosure should be complete enough to identify affected customers and systems. Knowledge qualifiers and materiality thresholds require careful allocation.
Escrow or retention can protect identified remediation and liability exposures. Deferred consideration can follow accepted workloads, renewals, collections or demonstrated contribution. Earn-outs require definitions that prevent value from being created by underinvesting in security, support or compliance. Operational covenants should preserve the resources needed to achieve the measure.
| Exposure | Evidence gap | Possible protection | Release evidence |
|---|---|---|---|
| Customer access | consent or approval depends on change of control | condition, retention or deferred value | written consent and accepted service |
| Residency and control | architecture differs from promise | remediation escrow and covenant | tested configuration and customer acceptance |
| Cyber incident | scope or cost remains unresolved | specific indemnity and reserve | agreed closure and quantified residual exposure |
| Revenue quality | recurring classification is uncertain | price adjustment or contingent value | renewal, acceptance and collection |
| Capacity commitment | utilisation depends on pipeline conversion | debt-like treatment or seller sharing | contracted and active workload utilisation |
| Key personnel | control knowledge is concentrated | retention, documentation and succession plan | tested operating handover |
| Exit obligation | portability or deletion is unproven | closing deliverable and reserve | successful migration and destruction test |
Each protection should match the exposure, control and verification date.
20. Design integration around customer trust
Integration can destroy the access being acquired if it changes legal entities, support locations, administrators, infrastructure, subprocessors or evidence without customer approval. The buyer should map each planned integration action to customer and regulatory obligations before execution.
The initial principle should be controlled continuity. Critical services, identities, keys, incident channels and evidence repositories should remain stable until the combined team understands dependencies. Any temporary separation should have an owner, cost and exit condition. Parallel systems may be justified while customer approvals are obtained.
Control integration should use the stronger evidenced standard, subject to jurisdiction and customer requirements. The buyer should reconcile identity, vulnerability, incident, change, supplier, continuity and AI-governance processes. It should avoid imposing a global tool that moves data or administrative control outside approved boundaries.
Commercial integration should preserve account ownership and trust while introducing the buyer's services. Cross-selling should follow customer need and approval readiness. Sales incentives should reward accepted, renewable and collected work rather than strategic announcements.
Finance should create a contribution ledger that links each customer to revenue, complete cost, working capital, incidents, remediation and renewal. This makes integration value observable and prevents centralisation savings from concealing service deterioration.
21. Execute a 180-day programme
The first thirty days should establish control. The buyer should confirm the service perimeter, critical customers, incident authority, privileged access, key custody, capacity commitments, regulatory calendar and cash controls. It should freeze unapproved architecture and subcontractor changes while maintaining customer service.
Days thirty-one to sixty should reproduce the evidence. Teams should complete customer and workload mapping, rebuild representative obligation-to-cash chains, test identity and keys, reconcile model releases, restore selected services and verify assurance scope. Material exceptions should receive owners, budgets and customer communication plans.
Days sixty-one to ninety should protect value. The buyer should prioritise remediation, secure consents, update contracts and evidence, establish a combined incident process, approve the integration architecture and align sales qualification with service eligibility. Finance should implement cohort contribution and cash reporting.
Days ninety-one to one hundred and eighty should scale the repeatable model. The business should automate evidence, standardise approved architectures, reduce custom branches, rationalise suppliers, execute recovery and exit tests, and launch controlled cross-selling. The board should review whether strategic demand is converting into accepted workloads, renewals and collected cash.
The roadmap sequences control, evidence reproduction, remediation and scale.
22. Govern the board scorecard
The board scorecard should connect obligations, controls, customers and cash. It should avoid a single sovereignty percentage because different requirements have different consequences. The scorecard should show population coverage, exceptions, trend, ownership and decision thresholds.
Regulatory measures can include workloads with current applicability decisions, required approvals obtained, material exceptions, overdue actions and supervisory requests. Technical measures can include privileged-access review, key-control tests, model-release reproduction, isolation results, vulnerability closure, recovery performance and evidence retrieval.
Commercial measures can include funded qualified pipeline, architecture approval, contracted workloads, time to acceptance, renewal, price realisation and collection. Financial measures should include recurring contribution after complete cost, utilisation, customer concentration, assurance cost, incident cost, remediation spend, working capital and cash.
The board should review causal links. A fall in conversion after security review may indicate product or evidence weakness. A rise in accepted workloads without contribution may indicate unpriced custom work. Improved margin with declining recovery testing may reflect deferred risk. Exceptions should be investigated before the headline metric is celebrated.
Decision thresholds should be explicit. They can trigger remediation funding, sales restrictions, customer notification, architecture change, supplier substitution or reconsideration of the transaction thesis. The scorecard should support action rather than ceremonial reporting.
23. Decision and conclusion
A GCC cyber-AI hosting provider should be acquired for evidenced control capability and repeatable regulated-customer outcomes. Domestic infrastructure can be strategically important, but value depends on how rights, architecture, people, processes and evidence combine to support accepted workloads and collected cash.
The buyer should define the service and regulatory perimeter, reproduce obligation-to-cash evidence, test identity and cryptographic authority, examine AI lifecycle controls, verify workload isolation and resilience, and rebuild customer contribution after complete cost. Strategic demand should remain separate from revenue until procurement, acceptance, renewal and collection are evidenced.
Valuation should follow contracted accepted workloads, retained customer relationships, transferable control capability, complete cost, remediation and working capital. Transaction protections should follow the timing and control of unresolved exposures. Integration should preserve customer trust while stronger controls and repeatable architectures are established.
The resulting decision is practical. A target deserves a premium when it can repeatedly translate regulated obligations into approved architecture, operating control, accepted service and cash. A target requires price protection, redesign or a narrower perimeter when the sovereign claim depends on location alone, informal knowledge or customer tolerance that may not survive ownership change.
Sources
- Central Bank of the UAE, Outsourcing Regulation for Banks Read the primary source
- Central Bank of the UAE, Outsourcing Standards for Banks Read the primary source
- Central Bank of the UAE, Guidelines for Financial Institutions Adopting Enabling Technologies Read the primary source
- Central Bank of the UAE, Cloud Computing Read the primary source
- ADGM Office of Data Protection, Data Protection Guidance Read the primary source
- DIFC, Data Protection Law DIFC Law No. 5 of 2020 Read the primary source
- Saudi National Cybersecurity Authority, Essential Cybersecurity Controls Read the primary source
- Saudi National Cybersecurity Authority, Essential Cybersecurity Controls 2-2024 Read the primary source
- Saudi National Cybersecurity Authority, Cybersecurity Controls Implementation Guides Read the primary source
- Saudi Central Bank, Cyber Security Framework Read the primary source
- Saudi Data and AI Authority, Personal Data Protection Law Read the primary source
- Saudi Data and AI Authority, Personal Data Protection Knowledge Centre Read the primary source
- Qatar Central Bank, Cloud Computing Regulation Read the primary source
- Qatar Central Bank, Technology Risk Instructions for Financial Services Operators Read the primary source
- Qatar Central Bank, Insurance Sector Cyber Security Regulation Read the primary source
- Central Bank of Bahrain, Cloud Outsourcing Control Guidelines Read the primary source
- Oman Ministry of Transport Communications and Information Technology, Personal Data Protection Law and Executive Regulation Read the primary source
- Oman Ministry of Transport Communications and Information Technology, Cloud Computing First Policy Read the primary source
- Oman Ministry of Transport Communications and Information Technology, Executive Regulations of the Personal Data Protection Law Read the primary source
- Oman Official Gazette, Personal Data Protection Law Read the primary source
- UAE Legislation, Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data Read the primary source
- UAE Cybersecurity Council, UAE Information Assurance Regulation Read the primary source
- Dubai Electronic Security Center, Cloud Security Standard Read the primary source
- Saudi Data and AI Authority, Implementing Regulation of the Personal Data Protection Law Read the primary source
- Saudi Data and AI Authority, Regulation on Personal Data Transfer Outside the Kingdom Read the primary source
- Saudi Communications Space and Technology Commission, Cloud Computing Services Provision Regulations Read the primary source
- Central Bank of Bahrain, Rulebook Operational Risk Module Read the primary source
- Bahrain Personal Data Protection Authority, Personal Data Protection Law Read the primary source
- Kuwait Communications and Information Technology Regulatory Authority, Data Privacy Protection Regulation Read the primary source
- Kuwait Communications and Information Technology Regulatory Authority, Cloud Computing Regulatory Framework Read the primary source
- National Institute of Standards and Technology, AI Risk Management Framework Read the primary source
- National Institute of Standards and Technology, AI RMF Generative AI Profile Read the primary source
- National Institute of Standards and Technology, AI Resource Center Read the primary source
- UK National Cyber Security Centre, Guidelines for Secure AI System Development Read the primary source
- National Institute of Standards and Technology, Cybersecurity Framework 2.0 Read the primary source
- National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations SP 800-53 Rev. 5 Read the primary source
- National Institute of Standards and Technology, Secure Software Development Framework SP 800-218 Read the primary source
- National Institute of Standards and Technology, Secure Software Development Practices for Generative AI SP 800-218A Read the primary source
- National Institute of Standards and Technology, Zero Trust Architecture SP 800-207 Read the primary source
- US Cybersecurity and Infrastructure Security Agency, Secure by Design Read the primary source
- International Organization for Standardization, ISO IEC 27001 Information Security Management Systems Read the primary source
- International Organization for Standardization, ISO IEC 42001 Artificial Intelligence Management Systems Read the primary source
- International Organization for Standardization, ISO IEC 27017 Cloud Security Controls Read the primary source
- Cloud Security Alliance, Cloud Controls Matrix Read the primary source
- IFRS Foundation, IFRS 3 Business Combinations Read the primary source
- IFRS Foundation, IAS 36 Impairment of Assets Read the primary source
- IFRS Foundation, IFRS 13 Fair Value Measurement Read the primary source
- IFRS Foundation, IAS 38 Intangible Assets Read the primary source
- International Valuation Standards Council, International Valuation Standards Read the primary source
- International Valuation Standards Council, Deciphering Technology Read the primary source
