Qatar Software Supply Chain and AI Security Rules: 90-Day Plan

If you build, buy or run software for a Qatari government entity, a critical sector operator or a Qatar Central Bank licensee, four sets of rules decide what your software supply chain has to prove: the National Cyber Security Agency's National Information Assurance (NIA) certification regime, the Qatar Central Bank's technology, cloud, data and AI regulations, the Personal Data Privacy Protection Law (Law No. 13 of 2016), and the AI guidance published by NCSA and QCB. None of them uses the word SBOM. Yet the bank texts ask, in plain words, for an up to date inventory of software components, tested patches, source code review, a register of every cloud and AI arrangement and approval before personal data leaves Qatar. This guide sets out each rule from its primary source, maps it to the evidence a supervisor asks for, and ends with a 30/60/90-day plan that works with whatever tools you already have.

This post explains public regulatory texts. It is not legal or regulatory advice. The Arabic text of each Qatari law is the binding version, and the government does not publish official English translations of its laws.

Key takeaways

• NCSA sets the national baseline. The National Cyber Security Agency, established under Emiri Decree No. 1 of 2021, issues certificates of compliance with national information security standards. Its NIA certification currently runs against NIA V2.1, through audits by accredited audit service providers.
• QCB rules are the most specific in the country. The Technology Risks Regulation for banks requires an up to date inventory of software and hardware components (8.8.2), testing of critical patches before production (8.3.4), source code review (9.7.1.4) and reporting of critical incidents to QCB within one hour of identification (8.2.10).
• Data location is a hard line for QCB licensees. The Cloud Computing Regulation (in force 15 April 2024) says personal and financial information is processed within Qatar only (21.4), and the Data Handling and Protection Regulation bars foreign storage or transfer of personal data without QCB approval (15.1).
• The privacy law covers almost everyone. Law No. 13 of 2016 requires controllers and processors to protect personal data (Article 13), controllers to notify serious breaches (Article 14), and allows fines of up to QAR 5 million per violation of the security article (Article 24).
• AI has a register and an approval gate for banks. The QCB Artificial Intelligence Guideline (in force 4 September 2024) requires a register of every AI system (10.1), QCB approval before high risk AI purchases or outsourcing (11.2) and protection against prompt injection (17.7). NCSA released voluntary guidelines for secure AI use in February 2024.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis (GA), software composition analysis with EPSS and CISA KEV enrichment (GA), reachability analysis (GA), policies and gates (GA), license compliance (GA), the Compliance and GRC suite with a Qatar PDPL framework page (GA), Third-Party Risk Manager (GA), the CLI and local runner (GA), private VPC, on-prem and air-gapped deployment (GA), Zero AI mode (GA), AI-BOM discovery (GA), Package Firewall (GA), and autonomous remediation (GA, ships switched off).

The situation

In Qatar the trigger is rarely a new law. It is usually an NCSA certification audit, a QCB inspection asking how the bank tracks end of support dates and patch delays, a ministry supplier questionnaire, a QCB approval request for a new cloud or AI service, or a public advisory that starts the one hour QCB incident clock while nobody can say which systems use the affected component.

Each event asks the same questions. What software is running, where did it come from, which known weaknesses does it carry, who supplied it, where does it process data, and who decided what to do about it? A team that cannot answer from a current inventory rebuilds one under a deadline.

Who this applies to in Qatar

The rules in this post do not share one scope clause. Who is in scope depends on who you are and who you serve.

Government and semi-government entities. NCSA's National Information Security Compliance Framework (NISCF) is the route to certification against national information security standards, and government agencies appear in its certification paperwork as applicants. Ministries and government-owned companies also pass NIA expectations to suppliers through contracts and tenders.

QCB licensees. The Qatar Central Bank regulates banks, insurers, finance companies, payment service providers and other financial institutions. QCB's Cloud Computing Regulation applies to every "organization regulated by the Qatar Central Bank". The Technology Risks Regulation is written for banks. The Data Handling and Protection Regulation covers QCB-regulated financial institutions, with different disaster recovery rules for local banks, branches of foreign banks and other institutions. The AI Guideline applies to every QCB-regulated entity that develops, buys or outsources AI.

Firms in the Qatar Financial Centre. The QFC is a separate legal and regulatory environment inside Qatar, with its own regulator and its own rules. This post does not cover QFC rules; confirm with the QFC which of its regulations apply to you.

Anyone processing personal data electronically. Article 2 of Law No. 13 of 2016 applies the law to personal data "electronically processed", or gathered in preparation for electronic processing, or processed through a mix of electronic and traditional methods. It excludes purely private or family processing and official statistics. That covers almost any software that handles customer, patient or employee data in Qatar.

Software and service suppliers. Foreign software makers and SaaS providers rarely hold a direct obligation to NCSA or QCB. They inherit it by contract: QCB's Technology Risks Regulation (4.1.4) applies the bank's controls to its vendors.

The rules, regulator by regulator

Each rule below was checked on the regulator's own site, an official document library or the official news agency on the date of this post. Where we could not confirm a detail on a primary source, we left it out.

NCSA: National Information Assurance and the NISCF

Status: in force; certification runs against NIA V2.1.

The National Cyber Security Agency is Qatar's national cyber authority. NCSA's own published procedures state that, "based on Emiri Decree No 1 of year 2021", its National Cyber Governance and Cyber Assurance Affairs is the entity responsible for issuing certificates to technology and information security service providers and certificates of compliance with national information security standards and policies.

NCSA's public service request form is titled "National Information Assurance (NIA) V2.1 Certification", which tells you the version auditors certify against today. Applicants appoint a nominated representative, sign a service agreement and submit scoping documents. Accredited audit service providers carry out the audits under NCSA procedures for audit risk, sampling and work programmes, issued as version 1.0 in October 2024; the work programme tells auditors to inquire about the change management process.

Older contracts may cite other versions. On 31 October 2019 the former Ministry of Transport and Communications announced a version 3 of the NIA Policy with a cloud and an industrial control systems standard, yet NCSA's certification paperwork today refers to NIA V2.1. Check which document your contract or auditor names. We could not retrieve the full NIA standard text for this post, so we do not quote its control numbers; get it from NCSA or your auditor and key your register to it.

NCSA: National Cyber Security Strategy 2024 to 2030

Status: published strategy, launched 17 September 2024.

The Qatar News Agency reported that NCSA launched the National Cyber Security Strategy 2024 to 2030 under the patronage of the Prime Minister and Minister of Foreign Affairs. The stated aim is to contribute to Qatar National Vision 2030 and to "position Qatar as a global leader in the secure adoption of emerging technologies". A strategy does not create controls by itself. It does explain why critical sector operators and their suppliers should expect more scrutiny, not less, through the rest of the decade.

Qatar Central Bank: Technology Risks Regulation for banks

Status: published on QCB's site; the document is dated January 2018.

This is the most detailed software security text in Qatar, and much of it reads like a software supply chain checklist. The clauses that matter most for software teams:

• Procurement and vendors (section 4). A procurement policy with cyber criteria (4.1.1), vendor assessment at the start of procurement (4.1.2), security clauses in contracts (4.1.3), the bank's controls applied to vendors (4.1.4) and independent vendor audits (4.1.5).
• Asset inventory (5.1.4). A detailed, up to date inventory of information assets, classified.
• Annual compliance reporting (7.1.1). A compliance report against the regulation goes to QCB at least annually.
• Incident reporting (8.2.10). "All critical incidents must be reported to QCB and the relevant governmental authorities within 1 hour of identification."
• Patch management (8.3). A process that identifies which vulnerabilities apply to which systems (8.3.1), expeditious emergency patching for publicly reported vulnerabilities (8.3.3), testing of critical patches before production (8.3.4), and measuring patch delay against the bank's baseline (8.3.6).
• Technology refresh (8.8). An up to date inventory of software and hardware components in production and disaster recovery (8.8.2), tracking of end of life and end of support dates (8.8.4), and inventories for UAT, test, staging and stock as well (8.8.5).
• Application security (9.4.2). Application security testing of web and mobile applications before and after implementation and after major changes (9.4.2.2), and vulnerability assessments, code reviews and penetration testing at least twice a year (9.4.2.3).
• Software development and acquisition (9.7). Secure development guidelines based on OWASP, CERT and MITRE CWE (9.7.1.1), source code review "to find vulnerabilities arising due to coding issues, poor coding practices or malicious attempts" (9.7.1.4), source code or escrow for custom critical applications (9.7.1.5), and review of applications for external connections (9.7.2.1).

Read 8.8.2 and 8.8.5 together: a current list of software components across every environment is, for software, close to an SBOM per environment.

Qatar Central Bank: Cloud Computing Regulation

Status: in force since 15 April 2024 for all QCB-licensed entities.

The regulation covers the full cloud lifecycle, from strategy to exit. The clauses with the most impact on software and security tooling:

• Register (section 9). A register with a complete inventory of cloud computing arrangements (9.1), disclosed to QCB annually and on request (9.4), distinguishing material arrangements from others (9.5), and recording for each arrangement whether a background check and risk assessment were done, the dates, the activities and data outsourced and the data classification (9.6).
• Due diligence (sections 11 and 12). Due diligence on the cloud service provider and on its sub-contractors, including the provider and location of the service (11.14.2).
• Approval (13.4 and 21.5). Official QCB approval before signing any material arrangement or materially changing one, and approval from QCB before entering into a cloud arrangement.
• Data location (21.4). "An Entity must ensure that PII and financial information is processed within Qatar only."
• Annual assessment (15.1). A full annual assessment of each arrangement, including breaches reported by the provider and any change of location.
• Testing (section 22) and exemptions (section 23). Cloud security testing, and a formal exemption process: requests go to QCB, are linked to a specific requirement, carry a business case and are recorded with an expiry date.

The definition of a cloud computing arrangement includes an arrangement with a third party "that utilizes a CSP in the services it provides to an Entity". A SaaS security tool hosted in a public cloud is therefore inside the regulation's scope for a bank.

Qatar Central Bank: Data Handling and Protection Regulation

Status: published on QCB's site. We could not confirm its effective date on the document itself.

This regulation ties the bank rules to the national privacy law. It requires data mapping of all data assets and flows (6.5). It requires the primary storage and processing environment for personal, sensitive personal and sensitive financial information to reside within Qatar (7.6), with an outside primary environment only after explicit QCB approval (7.7). It requires banks to assess third parties' compliance with data protection rules (9.2) and to make third parties report breaches promptly (9.4). Personal data must be processed in compliance with Law No. 13 of 2016 (13.1.1).

Section 15 bars storing or transferring personal data to a foreign jurisdiction without QCB approval (15.1) and requires a risk assessment of the jurisdiction and third party first (15.2). Section 16 requires data breaches to be reported under QCB's incident reporting guidelines, to QCB and to "the authorized agencies in Qatar which includes the National Cyber Security Agency and the Ministry of Interior" (16.3).

Personal Data Privacy Protection Law (Law No. 13 of 2016)

Status: in force. The official version was published in Official Gazette No. 15 of 2016.

The Arabic title is Qanun Raqm 13 li Sanat 2016 bi Sha'n Himayat Khususiyat al-Bayanat al-Shakhsiya. The clauses below are taken from the unofficial English translation prepared by the then ministry's Compliance and Data Protection Department, which itself points readers to the Gazette text on Al Meezan.

• Article 8: the controller must process personal data honestly and legitimately and take "appropriate administrative, technical and financial precautions" as determined by the competent department.
• Article 11: the controller must review privacy measures before new processing, build internal systems to report breaches, audit compliance and verify that processors protect data.
• Article 13: controller and processor must protect personal data "against loss, damage, change, disclosure, access thereto, or the inadvertent or illegal use thereof", in proportion to the data's nature and importance. The processor must notify the controller of any breach "forthwith".
• Article 14: the controller must inform the individual and the competent department of any breach of those precautions that may cause serious damage to personal data or privacy. The law itself sets no hour count; check the regulator's current guidelines for timing and form.
• Article 15: the controller may not take any decision or measure that limits cross-border data flow, unless the processing breaches the law or may cause serious damage. For QCB licensees, QCB's own approval rules above sit on top of this.
• Article 16: personal data of a special nature (ethnic origin, children, health, physical or psychological condition, religious creeds, marital relations and criminal offences) may only be processed with permission from the competent department.
• Articles 23 to 25: fines of up to QAR 1 million for breaching Articles 4, 8 to 12, 14, 15 and 22; up to QAR 5 million for breaching Article 13 (security precautions), Article 16 paragraph 3 and Article 17; and up to QAR 1 million for a legal person on whose behalf an offence is committed.
• Article 30: parties had six months from the law's effective date to adjust, extendable by the Council of Ministers.

The law defines the competent department as an administrative unit of the ministry. Supervision has since moved with the government's reorganisation of cyber and data functions; confirm today's competent authority, its guidelines and its notification channel before you need them.

Qatar AI guidance

Status: guidance. None of the AI documents reviewed here is a statute, but the QCB guideline is written in mandatory terms for licensees.

NCSA guidelines for secure AI use. On 19 February 2024 the Qatar News Agency reported that NCSA held a conference on the secure usage of AI and "released the guidelines for the secure usage of AI system", prepared by an agency team to help all AI users in Qatar adopt AI securely. NCSA presented them as encouragement rather than a mandate.

QCB Artificial Intelligence Guideline. In force from 4 September 2024 for QCB-regulated entities. Its software supply chain content is direct:

• An entity assessing an AI system from a third party vendor must consider the vendor's access to information and reputation as risk variables (9.5.2).
• An AI system must be classed as high risk where it can harm people through decisions on access to financial services, material decisions about employees, or processing of sensitive personal information (9.7).
• A register of all AI system arrangements (10.1), disclosed to QCB annually and on request (10.6), recording for each system its risk class, whether the entity is user or provider, its category and human oversight protocol (10.7), and for bought, licensed or outsourced systems the provider, a third party supplier assessment, the creation date of the system "and all subsequent upgrades", and contract dates (10.7.5).
• QCB approval before launching a new AI system as a provider (11.1) and before signing any high risk AI purchase, licensing or outsourcing agreement (11.2). QCB may send a system to its sandbox first (11.3).
• An AI trust, risk and security management programme with toolsets for third party system security (17.2.3), examination of each model's attack surface before deployment (17.4), and protection against integrity attacks, query attacks and prompt injection (17.5 to 17.7).

For the strategy and investment side of AI in Qatar, see our separate post on Qatar's AI plan, linked at the end.

What the rules ask of software and open source

Put the texts side by side and the same eight asks recur. The table maps each to its source and to the evidence a reviewer typically asks to see.

Inventory appears in more clauses than anything else, per environment rather than per server, and every QCB register (cloud, AI, exemptions) has a supplier dimension.

Real public incidents affecting Qatar from the last three years

We looked for software supply chain incidents in Qatar with official or primary public reporting and enough detail to describe responsibly. We did not find one that met that bar, so this section uses two global incidents with primary reporting that reached any organisation, in Qatar or elsewhere, running the affected open source.

XZ Utils, 29 March 2024. CISA reported "malicious code being embedded in XZ Utils versions 5.6.0 and 5.6.1", tracked as CVE-2024-3094. XZ Utils is a compression library shipped in Linux distributions. CISA recommended downgrading to an uncompromised version and hunting for malicious activity. For a QCB licensee, the practical test was 8.8.2 and 8.3.3 together: could the bank say within hours which production, disaster recovery and test systems carried the affected versions, and patch them expeditiously?

npm "Shai-Hulud", alert of 23 September 2025. CISA described a self-replicating worm that had compromised over 500 npm packages, harvested developer credentials and used compromised accounts to publish infected versions of other packages. CISA told organisations to check lock files including nested dependencies, search artifact repositories for cached versions, pin to releases from before 16 September 2025, rotate developer credentials and require phishing-resistant MFA. Those steps line up with QCB's inventory (8.8.2) and source code review for "malicious attempts" (9.7.1.4).

Neither alert names Qatari victims, and we draw no conclusion about any organisation.

The personas who own the problem

The CISO

The CISO owns the NIA certification position, the board summary and the first hour of an incident; in a bank, also the one hour QCB clock (8.2.10) and the annual compliance report (7.1.1). They need a dated answer to "what do we run and what is exposed" and a rehearsed path to QCB, NCSA and the Ministry of Interior. Their moments are the certification audit, a QCB inspection and the morning after a public advisory.

The head of AppSec or VP of Engineering

They own 9.7.1.1, 9.7.1.4 and 9.4.2.3 in practice: secure coding standards, source code review, twice yearly testing and the patch delay measured under 8.3.6. They need fewer findings that matter more, fixes that pass the 8.3.4 test environment, and gates that stop new risk without stalling releases.

GRC and regulatory affairs

They map controls to evidence across NIA, QCB and the PDPPL and prepare the annual QCB disclosures. They need one register where one piece of evidence answers overlapping clauses, because 5.1.4, 8.8.2, 8.8.5, cloud register 9.6 and AI register 10.7 all ask for inventory in different words.

Procurement and vendor risk

They own vendor assessments (4.1.2), contract clauses (4.1.3) and the supplier fields of the cloud and AI registers. Their moments are tenders, renewals and exits. They need a standard ask of every software supplier: a component inventory, a vulnerability disclosure route, incident notice terms that fit the one hour clock, and where data is processed.

The data protection officer

They own the PDPPL: Article 11 procedures, Article 13 precautions, Article 14 notifications, special nature data permits under Article 16 and, in a bank, the data mapping and foreign transfer approvals under the Data Handling and Protection Regulation. They need to know which systems process personal data, which suppliers and sub-processors touch it, and where each one runs.

Step by step: a 30/60/90-day plan that works with or without Safeguard

The plan assumes a mid-sized organisation with a few dozen applications. Adapt the order to your next deadline: if a QCB approval request or an NIA audit is closer, pull the relevant steps forward.

Days 1 to 30: know what you run and which clocks you are on

1. Write your scope on one page. Which regimes bind you (NIA, QCB regulations, PDPPL, QCB AI Guideline, contracts), why, and who owns each.
2. List applications and environments. Production, disaster recovery, UAT, test and staging, as 8.8.2 and 8.8.5 ask, with owner, data classification and whether personal data is processed.
3. Generate a component inventory per application. An SBOM in SPDX or CycloneDX for every build you ship and every third party application you can get one for, dated.
4. Enrich with risk signals. Match components to known vulnerabilities, add CISA KEV and EPSS, and flag components past end of support for 8.8.4.
5. Map data flows and locations. Record where each system runs and where its data goes, including SaaS tools. For a bank, mark anything processing personal or financial information outside Qatar against 21.4, 7.6 and 15.1.
6. Rehearse the first hour. Time how long it takes to name every system affected by a recent public advisory. Longer than an hour is your first finding.

Days 31 to 60: control the flow of new risk

1. Agree a severity scheme and a patch baseline. Set remediation targets by severity and exploit signal, and write down the baseline that 8.3.6 measures against. Use this decision table as a starting point:

2. Turn the scheme into gates. Add a check in CI that fails or warns on the conditions above, so new risk stops at the pull request.
3. Control library sources. Decide which registries and mirrors builds may pull from and enforce it, so a typosquatted or confused dependency cannot enter quietly. Pair this with license policy.
4. Send supplier evidence requests. Ask every material software and cloud supplier for a component inventory, vulnerability disclosure terms, incident notice terms that support your one hour clock and the location of processing. Record answers in the cloud register fields from 9.6.
5. Tighten code review. Make sure 9.7.1.4 source code review covers dependency changes, not just your own code: a lock file change is a code change.

Days 61 to 90: prove it and keep proving it

1. Map evidence to controls once. One register keyed to the regulators' numbering (NIA V2.1, QCB clauses, PDPPL articles), each row pointing at dated evidence.
2. Inventory AI components. List models, AI SDKs and hosted AI services per application. For a QCB licensee, fill the 10.7 register fields and flag high risk systems under 9.7.
3. Prepare approval packs. For each pending cloud or AI arrangement, assemble the risk assessment, register entry and data location answer QCB will want under 13.4, 21.5 or 11.2.
4. Run a tabletop. Walk a public advisory end to end and draft the QCB, NCSA, Ministry of Interior and Article 14 notices as they apply. Time each step.
5. Set the cadence. Regenerate inventories on every release, review suppliers yearly, and build the annual QCB disclosures from the same data.

A simple template for each register row:

The numbers in the example are illustrative.

How Safeguard does this

Safeguard is a software supply chain security platform. Everything below is GA and is described from Safeguard's offering documentation and docs.safeguard.sh. It helps a team produce and keep the evidence that the NCSA, QCB and PDPPL texts ask for. It does not make an organisation compliant, and switching on a framework in Safeguard does not certify anything.

1. Decide where Safeguard runs. For a QCB licensee this question comes first, because a SaaS tool is a cloud computing arrangement under the regulation. Safeguard's SaaS runs in multiple regions (US, EU and Gov); there is no Qatar region. Where 21.4, 7.6 or your own policy rules out an outside service, the GA answers are a private VPC or dedicated tenancy, a full on-prem installation in your data centre, or a fully air-gapped deployment. Per the air-gapped deployment docs, every product capability has an air-gapped equivalent, including the web app, the CLI, the runner and quantized builds of Safeguard's models running on your own GPUs, with vulnerability feeds delivered as bundles.

2. Keep source code on your own machines with the local runner (GA). The runner is part of the Safeguard CLI (GA). Per the docs, it polls the platform for scan jobs, runs each one locally and "uploads only the resulting SBOM and findings, never your source code". It suits restricted networks where only outbound HTTPS is allowed. Install and first run, as the docs show them:

   # macOS and Linux
   curl -fsSL https://cli.safeguard.sh/install | bash
   # then open the interactive terminal and type /login
   safeguard
   # or run headless for a workspace
   safeguard runner start --workspace ./path/to/repo
   safeguard runner status
   

   We did not run these commands for this post; check the CLI installation page for version pinning.

3. Choose how much AI is in the loop. Zero AI mode (GA) runs the whole platform deterministically with no LLM; bring your own model (GA) and local models (GA) are the alternatives. For a bank keeping the 10.1 AI register, this lets you decide and document whether your security tooling belongs in it.

4. Generate the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX inventories. Software composition analysis (GA) covers the full transitive dependency tree and container layers. Vulnerability management (GA) enriches findings with EPSS and CISA KEV, and reachability analysis (GA) ranks findings on code paths your application actually calls. Scan each environment's build and you have dated evidence for 5.1.4, 8.8.2 and 8.8.5.

5. Switch on the Qatar PDPL framework. In the Compliance and GRC suite (GA), open Compliance, then Manage, then the Frameworks tab. The Qatar PDPL framework page says the framework is on unless you switch it off, and lists five scan requirements that each scan checks against the product's SBOM: protective precautions, breach notification readiness, processor compliance, accuracy of processing and transparency of processing. It also offers three policy templates written for Qatar's law (a privacy notice, a data subject rights procedure and a cross-border data transfer policy). Per the frameworks docs, a readiness score "is not an audit opinion or a certification". There is no dedicated docs page for NIA V2.1 or the QCB regulations; evidence those clauses in your own register using the same scan outputs.

6. Enforce the gate in CI. Policies and gates (GA) turn your 60-day decision table into rules on severity, CVSS, EPSS, license or component age. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent); approvals run through exceptions, which you can align with your 8.3.4 test step and your exemption register.

7. Stop bad packages at install time. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build. License compliance (GA) evaluates licenses against your policy.

8. Collect supplier inventories. Third-Party Risk Manager (GA) handles the 4.1.5 and cloud register ask. Per the SBOM requests docs, you navigate to the vendor, click Request SBOM, select products, choose a template, set a deadline and send; bulk requests go out from the Vendors list. Requests are tracked by status, and vendor risk is scored and monitored over time.

9. Inventory AI. AI-BOM discovery (GA) inventories AI assets across code, cloud and SaaS. That is the starting list for the QCB AI register in 10.7, which you then complete with the business fields only your team can fill.

10. Fix with approval. Autonomous remediation (GA) can open tested fix pull requests, single or in bulk, through Safeguard's Griffin models. It ships switched off, with every category set to Manual, so every change still passes through your 8.3.4 test environment and change management.

What Safeguard does not do

• It does not make you compliant or certified. Safeguard holds no NCSA, QCB or other Qatari certification, approval or assessment, and using it does not count toward NIA certification by itself. Its own posture is SOC 2 Type II compliant and designed for FedRAMP High. It helps you produce and keep evidence; NCSA, accredited auditors and QCB decide.
• It does not host data in Qatar as SaaS. The SaaS regions are US, EU and Gov. If 21.4 or 7.6 applies to your use, choose on-prem, air-gapped, private VPC or the local runner, and treat the arrangement under QCB's cloud and approval rules as your counsel advises.
• It does not file your notifications or approval requests. The one hour QCB notice, the reports to NCSA and the Ministry of Interior, the Article 14 notice and every QCB approval request are yours to classify, approve and send. Safeguard helps you find affected systems and assemble evidence faster.
• Its control labels are its own. The control catalog on Safeguard's Qatar PDPL page uses Safeguard's own identifiers, and some of the article numbers in those labels do not match the law's numbering (in the translation we used, breach notification is Article 14 and cross-border flow is Article 15). Key your register to the law's articles and use Safeguard's pages as evidence sources.
• It does not replace code review, contracts or registers. Source code review under 9.7.1.4, escrow under 9.7.1.5, vendor contract clauses, the business fields of the cloud and AI registers and the annual compliance report stay with your people.
• It does not fix code you do not build. A vulnerability inside a supplier's hosted service or appliance still needs that supplier's fix.

Common mistakes

• Inventorying servers and not components. 8.8.2 asks for software components. A server list cannot answer "where do we run XZ 5.6.1?"
• Covering production only. 8.8.5 extends the inventory to UAT, test, staging and stock, which is where old components often linger.
• Treating the one hour clock as the time to finish the investigation. 8.2.10 starts at identification. Practise reporting what you know within the hour and updating later.
• Forgetting that your security tools are cloud arrangements too. A SaaS scanner hosted abroad is in scope for the Cloud Computing Regulation and the register.
• Leaving AI out of the inventory. The QCB AI register asks for every AI system, including bought and outsourced ones and their upgrade history.
• Quoting old NIA numbering. Contracts may cite older policy versions. Map against the version your auditor certifies, which NCSA's paperwork shows as V2.1.

FAQ

Does Qatar require an SBOM?

No text we reviewed uses the word. QCB's Technology Risks Regulation requires an up to date inventory of software and hardware components in production, disaster recovery, UAT, test and staging (8.8.2 and 8.8.5). An SBOM per application and environment is the most practical way to meet that for software.

What is NIA certification in Qatar?

It is NCSA's certification of compliance with the National Information Assurance standard, run under the National Information Security Compliance Framework. NCSA's current request form refers to NIA V2.1, and audits are performed by accredited audit service providers.

How fast must a Qatari bank report a cyber incident?

QCB's Technology Risks Regulation says all critical incidents must be reported to QCB and the relevant governmental authorities within one hour of identification (8.2.10). The Data Handling and Protection Regulation adds that data breaches go to QCB, NCSA and the Ministry of Interior (16.3).

Can a QCB-licensed bank use cloud services hosted outside Qatar?

The Cloud Computing Regulation requires QCB approval before entering a cloud arrangement (21.5) and says personal and financial information is processed within Qatar only (21.4). The Data Handling regulation allows a primary environment outside Qatar only with explicit QCB approval (7.7). Exemptions go through QCB's formal process.

What is the breach notification rule under Qatar's data privacy law?

Article 14 of Law No. 13 of 2016 requires the controller to inform the individual and the competent department of a breach that may cause serious damage to personal data or privacy. Article 13 requires processors to tell the controller forthwith. The law sets no hour count, so check the regulator's current guidelines.

Does Qatar restrict cross-border data transfers?

Article 15 of the privacy law stops controllers from limiting cross-border data flow unless the processing breaches the law or may cause serious damage. For QCB licensees, QCB's regulations are stricter: foreign storage or transfer of personal data needs QCB approval (Data Handling 15.1).

Is there an AI law in Qatar?

None of the AI documents reviewed here is a statute. NCSA released guidelines for secure AI use in February 2024. For QCB licensees, the Artificial Intelligence Guideline (in force 4 September 2024) requires an AI register, QCB approval for high risk AI purchases and outsourcing, and security controls including protection against prompt injection.

Is Safeguard certified or hosted in Qatar?

No. Safeguard holds no Qatari certification or approval, and its SaaS has no Qatar region. It can run on-prem, in a private VPC or dedicated tenancy, or fully air-gapped with its models inside your environment, and the local runner keeps source code on your own machines in any setup.

The steps above cover inventory, gates, supplier evidence and AI registers. The section below covers the other half of the job: closing the gap between finding a vulnerable component and getting a fixed one into production, which is what QCB's 8.3.3 expeditious patching and 8.3.6 patch delay measure.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a Qatari bank that cannot connect its repositories to a service outside the country, this is the route where only the SBOM and findings leave the machine.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That approval at each change mirrors the test-before-production discipline in QCB's 8.3.4.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For a GRC lead preparing the annual QCB disclosures, that means asking an assistant for the open critical findings on a system in your register while keeping its access limited to the tools you allow.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• Qatar's AI plan: Qai, Brookfield, gas power and conflict
• Gulf AI data centres in 2026: UAE, Saudi Arabia and Qatar compared
• UAE PDPL and sector data localisation: what teams should check
• Saudi Arabia software supply chain and AI security rules: 90-day plan

Sources

• NCSA, NISCF, NIA Audit Risk Procedure, V1.0, October 2024 (PDF)
• NCSA, NISCF, NIA Audit Work Program procedure (PDF)
• NCSA, NIA V2.1 Certification Service Request Form (PDF)
• Ministry of Transport, MoTC announces version 3 of the National Information Assurance Policy, 31 October 2019
• Qatar News Agency, National Cyber Security Strategy 2024 to 2030 launched, 17 September 2024
• Qatar News Agency, NCSA organizes conference on secure usage of artificial intelligence, 19 February 2024
• Qatar Central Bank, Technology Risks Regulation for Banks (PDF)
• Qatar Central Bank, Cloud Computing Regulation (PDF)
• Qatar Central Bank, Data Handling and Protection Regulation (PDF)
• Qatar Central Bank, Artificial Intelligence Guideline (PDF)
• Law No. 13 of 2016 on Personal Data Privacy Protection, unofficial English translation by the Compliance and Data Protection Department (PDF)
• Al Meezan, Qatar Legal Portal, Law No. 13 of 2016 (Arabic)
• CISA, Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094
• CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem
• Safeguard docs, Qatar PDPL
• Safeguard docs, Compliance frameworks
• Safeguard docs, Safeguard CLI
• Safeguard docs, Policies and Gates
• Safeguard docs, Package Firewall
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, Air-gapped deployment

Start with the free tier at safeguard.sh/download and read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.