Reading NCSI Guidance for AI Systems in Omani Government

Procurement teams across Omani ministries and regulators keep asking the same question about AI: what does NCSI actually require, and what is just good practice. The answer matters, because the difference between guidance and law decides whether a control goes into the contract or into the optional roadmap. This is a working read of the National Centre for Information Safety material as it applies to AI systems, written for a sovereign buyer reviewing a tender. It is paired with our pillar on AI sovereignty under Omani PDPL, which covers the personal-data side in depth.

What NCSI actually publishes (and what is law versus guidance)

The National Centre for Information Safety sits inside the Ministry of Transport, Communications and Information Technology and runs the operational side of national cybersecurity, including the Oman National Computer Emergency Readiness Team (OCERT). What it publishes falls into three layers, and only one of them is law.

• Royal Decrees and primary law. Royal Decree 12/2011 on Electronic Transactions, Royal Decree 64/2008 amended by Royal Decree 6/2007 on Cybercrime, and Royal Decree 6/2022 on Personal Data Protection. These bind every entity in Oman, public or private. NCSI does not author them, it operationalises them.
• National policies adopted by Council of Ministers decision. The National Data Strategy and the National Data Classification Policy sit here. They are not Royal Decrees but they bind the public sector and any entity processing public sector data, because a Council of Ministers decision adopted them as the operating standard. The National Data Strategy is the most quoted example.
• Guidelines and standards published by NCSI directly. The Cybersecurity Governance Guideline, the Basic Information Security Controls Guideline, the Cloud Service Adoption Guideline, and a growing set of sector-specific notes. These are formally advisory, but they are referenced as binding inside public sector tenders and audit reports, which is what makes them mandatory in practice.

For AI specifically, NCSI has not yet published a single dedicated "AI Guideline" document with that title. What it has done is extend the existing governance, classification, and supply chain frameworks to cover AI systems as a class of information system. That is the architecture a sovereign buyer needs to read against an AI tender.

The two pillars relevant to AI: data classification and supply chain integrity

Two NCSI pillars do most of the work when an AI system enters an Omani government environment. Both are established, both are referenced by every public sector procurement of any size, and both shape what an AI deployment is allowed to do.

Pillar one: the National Data Classification Policy. This is the framework that places every public sector dataset into a tier (Public, Restricted, Confidential, Secret) and binds each tier to a custody and processing regime. The policy made one structural change worth noting for AI buyers: it set the default classification of public sector data to unclassified and prohibited over-classification, while empowering NCSI and MTCIT to enforce correct classification. For AI, the practical reading is that any model that touches Restricted-and-above data is itself a processor of that data, and the model weights, the prompt logs, and the embedding store inherit the custody requirements of the tier. Hosting the index in-country is necessary but not sufficient. The institution must retain key custody and audit access to the inference path.

Pillar two: supply chain integrity. NCSI's governance and basic controls guidelines import the supply chain control families from ISO/IEC 27001:2022 and ISO/IEC 27036, then add Oman-specific overlays around vendor disclosure, in-country support, and verified update channels. AI procurement multiplies the surface area: model weights are a dependency, training data provenance is a dependency, the inference framework is a dependency, the GPU driver and firmware are dependencies, and an orchestration agent that pulls from a public registry at runtime is a dependency. NCSI's expectation is that a public sector buyer can produce a complete bill of materials and a verified offline update path. A vendor that cannot provide both fails the supply chain check before any technical evaluation begins.

How NCSI's AI guidance maps to a Hosn-class deployment

A Hosn-class deployment, meaning an on-premise appliance running open-weight Arabic-capable models inside the institutional perimeter, maps cleanly onto both pillars without bolt-on compliance work.

• Custody. Weights, retrieval index, prompt logs, and observability live inside the institution's network. Restricted, Confidential, and Secret data never leave the perimeter for inference. The cloud-hosted-model question (export of the prompt to a third country) does not arise.
• Key custody. Encryption keys for the model store, the audit log, and the document index sit on hardware controlled by the institution, with NCSI-aligned key management procedures. The vendor never holds a copy.
• Bill of materials. A signed manifest covers the base model weights (Gemma 4, Qwen 3.6, Falcon Arabic), inference framework versions, container digests, and driver versions. Updates flow through a verified offline mirror, not a live external pull. The Cloud Service Adoption Guideline's expectations apply by analogy and are met.
• Audit. The Cybersecurity Governance Guideline expects a documented governance, risk and security framework. Hosn's standard delivery includes an ISO 27001-aligned controls map, a logged inference audit trail, and a quarterly review cadence the institution's CISO can sign off on.

Mu'een, Oman's national shared AI platform, sits in a different lane: a centralised service for general productivity workloads on Public and lower-Restricted material. NCSI's classification policy is what makes the lanes legible. Hosn-class on-premise systems handle the higher tiers; shared platforms handle the lower ones; both can coexist in a ministerial environment without ambiguity.

Practical compliance checklist for AI procurement

What a procurement officer should put into an AI tender so that NCSI alignment is an artefact, not an aspiration.

1. Reference the National Data Classification Policy and require the vendor to map every system component to the tier it processes, with custody location named per component.
2. Require an ISO 27001-aligned controls map, with cross-references to the NCSI Cybersecurity Governance Guideline and the Basic Information Security Controls Guideline.
3. Require a complete bill of materials covering model weights, training-data provenance disclosure where available, inference framework, container digests, GPU drivers and firmware.
4. Require a verified offline update path. No runtime pulls from external registries during normal operation. Updates are imported, signed, scanned, then promoted.
5. Require an in-country incident response plan with named OCERT liaison, response time commitments, and a documented data residency clause for any vendor-side telemetry.
6. Require a key custody clause: encryption keys for weights, indexes, and audit logs sit on institutional hardware. The vendor receives no copy and no remote unlock capability.
7. Require an annual NCSI-aligned audit and a quarterly internal review with documented remediation tracking.

Vendors that cannot meet these clauses without negotiation are not ready for sovereign work. Vendors that meet them by default are the ones a procurement officer can defend in front of an auditor a year later, when the question stops being "did this AI deliver value" and starts being "where is the documentation".

Hosn was built so that this checklist reads like an inventory of standard deliverables rather than a wishlist. Email [email protected] for a one-hour briefing in which we walk through the NCSI mapping line by line against your specific institutional context, and leave you with a procurement-ready document you can drop into a tender pack.