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

If you build, buy or run software for a Saudi government entity, a critical infrastructure operator or a SAMA-regulated financial institution, four sets of rules decide what your software supply chain has to prove: the National Cybersecurity Authority's control documents (ECC-2:2024 and its extensions), the SAMA Cyber Security Framework, the Personal Data Protection Law with its implementing and transfer regulations, and SDAIA's AI Ethics Principles. None of them uses the word SBOM, yet all of them ask for an accurate asset inventory, timely vulnerability remediation, controlled third parties and evidence you can show a reviewer. This guide sets out each rule from its primary text, 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, and the Arabic text of each NCA and SDAIA document is the binding version.

Key takeaways

• Scope is set by who you are and who you serve. ECC-2:2024 binds Saudi government agencies, their affiliated companies and private operators of Critical National Infrastructure. SAMA's framework binds its member organisations. The PDPL binds anyone processing personal data of people in the Kingdom.
• The software asks are concrete. ECC 1-6-3 requires secure coding standards and "trusted and licensed sources" for development tools and libraries. ECC 2-10-3 requires periodic vulnerability assessment, severity classification and patch testing in a non-production environment. CSCC 2-9-1 sets monthly remediation for internet-facing critical systems.
• Third parties are inside the perimeter. ECC 4-1, CCC 4-1 and SAMA CSF 3.4 all require cyber clauses in contracts, risk assessment before signing and periodic review. ECC 4-1-3-2 requires managed security operations centres that use remote access to be fully located in the Kingdom.
• Data localisation moved. ECC-2:2024 deleted the old in-Kingdom hosting subcontrol and sent localisation questions to SDAIA's National Data Management Office. CSCC 4-2-1-1 still requires critical systems to be hosted in-house or with government or Saudi cloud providers that comply with the CCC.
• Breach clocks are short. The PDPL Implementing Regulation (Article 24) gives a controller 72 hours to notify SDAIA. SAMA CSF 3.3.15 requires member organisations to inform SAMA IT Risk Supervision immediately for medium or high incidents.
• 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), the Compliance and GRC suite with Saudi NCA ECC, SAMA CSF and Saudi PDPL framework pages (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

The trigger in the Kingdom is rarely a new law. It is usually one of four events. An NCA self-assessment cycle opens and the compliance tool asks for evidence against ECC subdomain 2-10. A SAMA examiner asks how the bank knows which of its outsourced applications carry a known-exploited vulnerability. A ministry tender asks a software supplier to accept ECC 4-1-2 clauses in its contract. Or a breach lands and the 72-hour PDPL clock starts while nobody can say which systems use the affected component.

In each case the question is the same: what software is running, where it came from, which known weaknesses it carries, who supplied it and who decided what to do about it. Teams that cannot answer from a current inventory end up reconstructing one under a deadline.

Who this applies to in Saudi Arabia

The NCA's documents define scope by entity type. ECC-2:2024 applies to "government agencies in the Kingdom of Saudi Arabia (including ministries, authorities, establishments and others) and their affiliated companies and entities (inside and outside the kingdom)", plus private sector entities "owning, operating, or hosting Critical National Infrastructures". The NCA "strongly encourages" every other entity in the Kingdom to use the controls as best practice. Compliance is required under Article 10(3) of the NCA's Statute and High Order No. 57231 dated 10/11/1439H, and the NCA evaluates it through self-assessment, reports from its compliance tool and field audit visits.

That scope reaches further than it first appears, for three reasons.

1. Affiliated companies count. A software company owned by a government entity is in scope even if it sells commercially.
2. Suppliers inherit obligations by contract. ECC 4-1-2-3 requires in-scope entities to oblige third parties to apply the entity's cybersecurity requirements and the relevant laws. A software vendor with no direct NCA obligation will meet the ECC through its customer's contract.
3. Cloud has its own scope. The Cloud Cybersecurity Controls apply to cloud service tenants in ECC scope and to any cloud service provider that serves them, which brings providers outside the ECC into NCA rules.

The supervisors line up as follows.

Many organisations sit in more than one row, and their software suppliers meet each regime through contract clauses and due diligence questionnaires.

The rules, regulator by regulator

Each status below was checked on 25 October 2026 against the regulator's own document or rulebook page.

NCA Essential Cybersecurity Controls, ECC-2:2024

Status: in force. The NCA's English PDF lists ECC-1 issued in 2018 and ECC-2 in 2024, with Appendix C recording every change. ECC-2:2024 has 4 main domains, 28 subdomains, 108 main controls and 92 subcontrols. The domains are Cybersecurity Governance (1), Cybersecurity Defense (2), Cybersecurity Resilience (3) and Third-Party and Cloud Computing Cybersecurity (4). The old domain 5 on industrial control systems was deleted and moved to the NCA's Operational Technology Cybersecurity Controls.

The controls that touch software, open source and suppliers most directly:

• 1-6 Cybersecurity in Information and Technology Project Management. 1-6-2 requires vulnerability assessment and remediation and a review of secure configuration, hardening and update packages before launching projects and changes. 1-6-3 adds, for software and application development projects, secure coding standards (1.6.3.1), "using trusted and licensed sources for software development tools and libraries" (1.6.3.2), compliance testing of software against the entity's requirements (1.6.3.3), secure integration between applications (1.6.3.4) and a hardening review before launching software products (1.6.3.5).
• 2-1 Asset Management. An accurate and updated inventory of information and technology assets, with requirements identified, documented, approved, implemented and periodically reviewed (2-1-1 to 2-1-6).
• 2-3 Information System and Processing Facilities Protection. 2.3.3.3 lists patch management for systems, applications and devices.
• 2-10 Vulnerabilities Management. 2-10-3 sets the minimum: periodic assessment and detection (2.10.3.1), classification by severity (2.10.3.2), remediation by classification and associated risk (2.10.3.3), patch management with integrity and effectiveness "verified using a non-production environment before being applied" (2.10.3.4), and subscription to trusted sources for new vulnerabilities (2.10.3.5).
• 2-13 Cybersecurity Incident and Threat Management. 2.13.3.3 requires reporting incidents to the NCA, and 2.13.3.4 sharing incident notifications, threat intelligence and incident reports with it.
• 4-1 Third-Party Cybersecurity. 4-1-2 requires contract clauses on non-disclosure and secure data removal at the end of service (4.1.2.1), incident communication procedures (4.1.2.2) and an obligation on the third party to apply the entity's requirements (4.1.2.3). 4-1-3 adds, for IT and cybersecurity outsourcing and managed services, a risk assessment before signing (4.1.3.1) and the rule that managed security operations centres using remote access "shall be fully located in the Kingdom of Saudi Arabia" (4.1.3.2). 4-1-4 requires periodic review.
• 4-2 Cloud Computing and Hosting Cybersecurity. Data protection by the provider according to classification, data returned in a usable format at the end of service, and separation from other tenants (4.2.3.1 and 4.2.3.2).

Two changes in Appendix C matter for anyone planning hosting. First, the ECC-1 subcontrol 4-2-3-3, which required an entity's information to be hosted and stored inside the Kingdom, was deleted. The NCA's note says controls on data localisation "have been transferred" to the National Data Management Office at SDAIA, and entities must refer to that office before taking any action on localisation. Separately, 1-2 states that cybersecurity positions shall be filled with full-time, qualified Saudi nationals, which shapes how a security team is staffed.

For a plain-language walk through every ECC domain, see our earlier explainer on the NCA Essential Cybersecurity Controls. This post stays on the software supply chain angle.

NCA Cloud Cybersecurity Controls, CCC-2:2024

Status: in force. CCC-1 was issued in 2020 and CCC-2 in 2024, with Appendix D listing the updates. The CCC applies to cloud service providers (CSPs) that serve in-scope tenants and to cloud service tenants (CSTs), defined as government agencies inside or outside the Kingdom, their companies and sub-entities, and CNI operators that use or plan to use any cloud service. The tenant controls are an extension of the ECC, so a tenant must comply with both.

The CCC tags every control P (provider) or T (tenant). The ones a software team will meet:

• 2-9-T-1 adds to ECC 2-10-3 for tenants: assess and remediate vulnerabilities in cloud services "at least once every three months" (2-9-T-1-1), and manage vulnerabilities the provider notifies (2-9-T-1-2). Providers must notify tenants of vulnerabilities that may affect them (2-9-P-1-2).
• 2-16 System Development Security (provider side) requires security requirements across the development lifecycle and protection of development, test and integration environments, including test data (2-16-P-3).
• 4-1 Supply Chain and Third-Party Cybersecurity requires providers to remove third-party software or services the NCA considers a threat from the marketplace they offer tenants (4-1-P-1-1), to obtain security documentation for equipment and services from suppliers (4-1-P-1-2) and to run risk management over third-party providers (4-1-P-1-4).

NCA Critical Systems Cybersecurity Controls, CSCC-1:2019

Status: in force as CSCC-1:2019. It applies to systems that an organisation deems critical under the document's criteria, whether the organisation is a government body in the Kingdom or abroad or a subsidiary of a government or private organisation. Its clauses reference ECC control numbers from the 2018 edition, so map carefully against ECC-2:2024.

CSCC is where the clocks become explicit:

• 1-3-2 adds to the ECC development requirements a security source code review before a critical system release (1-3-2-1), secured access, storage, documentation and release of source code (1-3-2-2), secured authenticated APIs (1-3-2-3) and trusted migration from test to production with test data and credentials removed (1-3-2-4).
• 2-3-1-3 requires security patches at least once a month for external and internet-connected critical systems and at least once every three months for internal ones, through approved change management.
• 2-9-1 requires trusted vulnerability assessment tools, remediation on the same monthly and quarterly cycle, and immediate remediation of critical vulnerabilities in line with change management. 2-9-2 requires monthly vulnerability assessments of critical systems' technical components.
• 4-1-1-2 requires outsourcing and managed services for critical systems to rely on Saudi companies and organisations, in line with the relevant rules.
• 4-2-1-1 requires critical systems and any part of their technical components to be hosted inside the organisation or with cloud services from government organisations or Saudi companies that comply with the CCC, taking data classification into account.

NCA Data Cybersecurity Controls, DCC-1:2022

Status: published as DCC-1:2022, an extension of the ECC focused on protecting data. Its structure follows the ECC in three main domains: Cybersecurity Governance, Cybersecurity Defense, and Third-Party and Cloud Computing Cybersecurity. The NCA also publishes an implementation guide (GDCC-1:2023). We could not extract the DCC control text reliably from the published PDF, so this post does not quote individual DCC control numbers. Read them from the NCA's PDF before mapping.

SAMA Cyber Security Framework

Status: in force. The SAMA Rulebook lists the framework under circular No. 381000091275 dated 24/5/2017 (28/8/1438H), status "In-Force".

The software and supplier controls:

• 3.3.6 Application Security. Application development "should follow the approved secure system development life cycle methodology (SDLC)", and the application security standard should cover secure coding, configuration, segregation of duties, data protection, vulnerability and patch management, backup and periodic compliance review.
• 3.3.15 Cyber Security Incident Management. Member organisations should inform SAMA IT Risk Supervision "immediately" when a medium or high classified incident occurs and submit a formal report after resuming operations that includes the information assets involved, root cause, corrective actions and estimated costs.
• 3.3.17 Vulnerability Management. The process should cover all information assets, a risk-based scan frequency, classification, "defined timelines to mitigate (per classification)", prioritisation for classified assets and patch management.
• 3.4 Third Party Cyber Security. SAMA expects "the same level of cyber security protection" at a third party as inside the member organisation, and defines third parties to include outsourcing providers, cloud providers, vendors and suppliers. 3.4.1 asks for a cyber risk assessment in procurement, cyber requirements in the tender, evaluation of vendor replies, risk-based testing of agreed requirements, an incident escalation process and exit terms including escrow where applicable. 3.4.2 requires SAMA approval before material outsourcing and compliance with SAMA's outsourcing circular. 3.4.3 requires SAMA approval before using hybrid or public cloud and states that "in principle" only cloud services located in Saudi Arabia should be used, with explicit SAMA approval needed for cloud outside the Kingdom.

Personal Data Protection Law and its regulations

Status: in force. The PDPL was issued by Royal Decree No. M/19 dated 9/2/1443H (16 September 2021) and amended by Royal Decree No. M/148 dated 5/9/1444H. SDAIA's guide for controllers and processors states that the law came into force on 14 September 2023 with a one-year grace period, and that controllers were expected to comply by 14 September 2024. SDAIA is the competent authority.

The articles that reach software:

• Implementing Regulation, Article 17, Choosing the Processor. The controller must choose processors with sufficient guarantees, set terms that include breach notification to the controller and disclosure of sub-processors, assess processor compliance periodically, and ensure sub-processors are chosen with the same guarantees.
• Article 23, Information Security. The controller must take organisational, administrative and technical measures, and comply with NCA controls, standards and rules, or with recognised best practice if it is not bound by the NCA's controls. This is the link that pulls ECC-style vulnerability management into privacy compliance.
• Article 24, Notification of Personal Data Breach. The controller must notify SDAIA "within a delay not exceeding (72) hours" of becoming aware of a breach that may harm personal data or data subjects, with a description, data categories, approximate numbers, risks and measures taken. Missing information goes in as soon as possible with reasons for the delay. Data subjects are notified without undue delay where the breach may harm them.
• Article 25, Impact Assessment. A written impact assessment is required in listed cases, including sensitive data and linking data sets from different sources.
• Regulation on Personal Data Transfer outside the Kingdom, Version 2.0, August 2024. Article 2 lists other purposes for transfer under Article 29 of the Law (central processing, a service or benefit to the data subject, scientific research). Article 4 sets the appropriate safeguards (standard contractual clauses, binding common rules, or a certificate from a body licensed by SDAIA) where an exemption applies. Article 5 applies the Law to onward transfers. Article 7 requires a risk assessment before transfers under Article 4 and before continuous or widespread transfers of sensitive data, covering purpose, legal basis, safeguards, data minimisation and potential harm.

For a fuller treatment of the transfer mechanics for engineering teams, see Saudi PDPL transfer rules for software teams.

SDAIA AI Ethics Principles

Status: published guidance. The AI Ethics Principles document on SDAIA's site (document number SDAIA-P114E, dated May 2025 in its control table) says the framework "shall apply to all AI stakeholders designing, developing, deploying, implementing, using, or being affected by AI systems within KSA". It sets seven principles: Fairness; Privacy and Security; Humanity; Social and Environmental Benefits; Reliability and Safety; Transparency and Explainability; and Accountability and Responsibility.

It also classifies AI risk into four levels. Little or no risk systems face no restrictions. Limited risk systems are subject to the principles. High risk systems "must undergo pre- and post-conformity assessments" alongside relevant statutory requirements. Unacceptable risk systems, such as social profiling or exploitation of children, are not allowed. For software teams, the practical consequence is an inventory question: you cannot place a system in a risk level until you know which models, AI SDKs and AI services it uses.

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 the clauses above and to the evidence a reviewer typically asks to see.

AI adds a ninth ask, under SDAIA's principles: an inventory of AI components and a documented risk level per system.

Real public incidents affecting Saudi Arabia from the last three years

We looked for incidents in the Kingdom with official or primary public reporting that involved the software supply chain. We did not find a Saudi case that met that bar with enough public detail to describe responsibly, so this section uses two global incidents with primary reporting that reached any organisation, in the Kingdom 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", assigned CVE-2024-3094. XZ Utils is a compression library present in Linux distributions, and CISA warned the code may allow unauthorised access. It recommended downgrading to an uncompromised version such as 5.4.6 Stable and hunting for malicious activity. Under ECC 2-1, the practical test was whether a team could say within hours which systems and images carried 5.6.0 or 5.6.1.

npm "Shai-Hulud", alert of 23 September 2025. CISA described a self-replicating worm that had compromised over 500 npm packages. It harvested credentials, including GitHub personal access tokens and cloud API keys, exfiltrated them and used compromised developer accounts to publish infected versions of other packages. CISA told organisations to review dependencies, check lock files for affected packages "including those nested in dependency trees", search artifact repositories for cached versions, pin to releases from before 16 September 2025, rotate developer credentials and require phishing-resistant MFA. Each of those steps maps to an ECC control: asset inventory (2-1), trusted sources (1.6.3.2), vulnerability handling (2-10) and identity (2-2).

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

The personas who own the problem

The CISO. ECC 1-2 requires cybersecurity positions to be filled by full-time, qualified Saudi nationals, so the CISO owns a team shaped by that rule. The CISO needs a defensible answer for the NCA compliance tool and field audits, a posture summary for the board, and the 72-hour PDPL and immediate SAMA reporting paths rehearsed. Their moments are the NCA assessment cycle, a SAMA examination, and the first hour of an incident.

The head of AppSec or VP Engineering. They own ECC 1-6-3, CSCC 1-3-2 and SAMA CSF 3.3.6 in practice: secure coding standards, approved library sources, code review before critical releases and the remediation cadence. What they need is fewer findings that matter more, fix work that fits change management, and the monthly cycle CSCC demands for internet-facing critical systems without stalling releases.

GRC and regulatory affairs. They map controls to evidence across NCA, SAMA and SDAIA, keep the register current and answer the compliance tool. They need one control mapping that handles overlaps, because ECC 2-10, CCC 2-9-T-1, CSCC 2-9-1 and SAMA CSF 3.3.17 all ask about vulnerability management in different words.

Procurement and vendor risk. ECC 4-1, CCC 4-1 and SAMA CSF 3.4.1 put them in charge of cyber clauses, pre-contract risk assessment and periodic review. Their moments are tenders, renewals and the exit of a supplier. They need a standard ask of every software supplier: a component inventory, a vulnerability disclosure route and incident notice terms.

The data protection officer. The PDPL Implementing Regulation puts processor selection (Article 17), information security (Article 23), breach notification (Article 24) and transfer risk assessments in their lane. They need to know which systems process personal data, which suppliers and sub-processors touch it, and where it flows outside the Kingdom.

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

Adapt the order to your next deadline.

Days 1 to 30: establish scope and inventory

1. Write down your scope in one page. Which documents bind you (ECC, CCC, CSCC, DCC, SAMA CSF, PDPL, AI principles), on what basis (government affiliate, CNI, SAMA member, controller, contract), and which systems are critical under CSCC criteria.
2. Build the application list. For every application in scope, record owner, criticality, hosting location, whether it processes personal data and which suppliers build or run it.
3. Produce a component inventory per application. Generate a software bill of materials in SPDX or CycloneDX from source, build output or container images. Keep the date with each one; this is your ECC 2-1 evidence for software.
4. Ask your top suppliers for theirs. Start with suppliers of critical and internet-facing systems. Ask for a component inventory, their vulnerability disclosure contact and their incident notice period.
5. Write the incident triage question down. "Which of our systems contain component X at version Y?" Time how long it takes to answer today. That number is your baseline for the 72-hour PDPL clock.

Days 31 to 60: set rules and remediation cadence

1. Adopt a severity scheme and remediation timelines per class. SAMA CSF 3.3.17 asks for "defined timelines to mitigate (per classification)". For critical systems, CSCC 2-9-1 sets a monthly cycle for internet-facing systems, quarterly for internal ones, and immediate action for critical vulnerabilities. Use exploit evidence (CISA KEV) and probability (EPSS) as inputs to priority, not just CVSS.
2. Publish an approved source and license policy. ECC 1.6.3.2 asks for trusted and licensed sources. Name the registries and mirrors builds may use, the licenses you accept, and how exceptions are approved.
3. Put a gate in CI. Decide which conditions stop a build (for example, a known-exploited critical vulnerability in a production dependency) and which only warn. Keep an exception path with an owner and an expiry.
4. Wire patches through a non-production test. ECC 2.10.3.4 requires it. Make the test result part of the change record.
5. Fix contracts at the next touchpoint. Add ECC 4.1.2 clauses (non-disclosure and data removal, incident communication, obligation to apply your requirements) and SAMA CSF 3.4.1 terms to renewals and new tenders.

Decision table for gates:

Days 61 to 90: prove it and keep it current

1. Map evidence to controls once. Build a single register that cross-references ECC, CCC, CSCC, SAMA CSF and PDPL clauses to the same evidence, so one scan history answers four questions.
2. Rehearse the incident path. Run a tabletop with a public advisory, find every affected system from the inventory, draft the SDAIA Article 24 notice and the SAMA 3.3.15 notice, and time each step.
3. Complete transfer risk assessments. For each supplier or tool that sends personal data outside the Kingdom, complete the Article 7 assessment in the transfer regulation, and check localisation questions with the National Data Management Office as ECC-2:2024 directs.
4. Inventory AI components. List AI SDKs, models and hosted AI services each application uses, and record a risk level under SDAIA's four categories.
5. Set the cadence. Regenerate inventories on every release, rescan on a schedule that meets CSCC and CCC clocks, and review suppliers at least yearly under ECC 4-1-4.

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 NCA, SAMA and SDAIA texts ask for. It does not make an organisation compliant, and choosing a framework in Safeguard does not certify anything.

1. Decide where Safeguard runs. For Saudi buyers this question usually comes first. Safeguard's SaaS runs in multiple regions (US, EU and Gov); there is no in-Kingdom SaaS region. Where CSCC 4-2-1-1, SAMA CSF 3.4.3 or an NDMO decision rules out an outside service, the GA answers are a private VPC or dedicated tenancy, a full on-prem installation in your own data centre, or a fully air-gapped deployment that includes Safeguard's own AI models, with updates delivered as signed offline bundles. Safeguard's offering notes that the platform holds no open or persistent connections and polls, and that customer code, SBOMs and telemetry are not used to train shared models.

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". All traffic is outbound HTTPS that the runner opens. 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 and checksums.

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) uses a model already on your approved list. Local models (GA) run Safeguard's quantized models inside your environment. This lets a CISO answer the SDAIA Privacy and Security principle and internal AI policy with a configuration, not a promise.

4. Generate the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX inventories, and software composition analysis (GA) covers the full transitive dependency tree and container layers. Vulnerability management (GA) enriches findings with EPSS and CISA KEV. Reachability analysis (GA) ranks findings on code paths your application actually calls. That gives you ECC 2-1 and 2-10 evidence, dated per scan.

5. Switch on the Saudi frameworks. In the Compliance and GRC suite (GA), open Compliance, then Manage, then the Frameworks tab, and switch on "Saudi Arabia NCA ECC", "SAMA Cybersecurity Framework" and "Saudi PDPL". The docs pages for NCA ECC, SAMA CSF and Saudi PDPL list the scan requirements each scan checks: for the ECC, asset management, vulnerability management, patch management, systems integrity, third-party component suppliers and documented records; for SAMA, asset inventory, vulnerability management, third-party provenance, integrity, risk identification and a documented baseline; for the PDPL, security measures, breach readiness, processor guarantees and records of processing. The rest is evidenced with uploaded evidence, policies or an attestation. Per the docs, a readiness score "is not an audit opinion or a certification".

6. Start policies from templates. Each framework page offers policy templates, including ones written for NCA ECC (for example an identity, access management and vulnerability management policy) and for SAMA (a third-party cybersecurity management procedure). Open the framework, then its Policies tab, select New policy and choose Start from template.

7. Enforce the gate in CI. Policies and gates (GA) turn your 60-day decision table into rules. In Settings, then Policies, you create a policy with conditions such as 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. The docs show this CI command; we did not run it:

   safeguard ci scan --wait --fail-on-gate <gate>
   

8. Stop bad packages at install time. For ECC 1.6.3.2, 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.

9. Collect supplier inventories. Third-Party Risk Manager (GA) handles the ECC 4-1 and SAMA 3.4.1 ask. Per the 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.

10. Inventory AI. AI-BOM discovery (GA) inventories AI assets across code, cloud and SaaS, which is the starting point for SDAIA's risk levels.

11. 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 changes go through your ECC 2.10.3.4 non-production test and change management.

What Safeguard does not do

• It does not make you compliant or certified. Safeguard is not certified, approved or assessed under any NCA, SAMA or SDAIA regime. Its own posture is SOC 2 Type II audit in progress and designed for FedRAMP High. It helps you produce and keep evidence; the NCA, SAMA and your auditors decide.
• It does not host data in the Kingdom as SaaS. The SaaS regions are US, EU and Gov. If your rules need in-Kingdom processing, use private VPC, on-prem, air-gapped or the local runner, and confirm the setup with your own regulator or the NDMO.
• It does not file your notifications. The 72-hour SDAIA notice, the immediate SAMA notice and NCA incident reports are yours to classify, approve and send. Safeguard helps you find affected systems faster.
• Its control labels are its own. The control catalog on Safeguard's framework pages uses Safeguard's own identifiers, which do not always match the NCA's ECC-2:2024 numbering. Keep your register keyed to the NCA's numbers, and use the Safeguard pages as evidence sources.
• It does not replace contract work or source code review. ECC 4.1.2 clauses, SAMA approvals for outsourcing and cloud, CSCC 1-3-2-1 source code review before release and Saudization of security roles 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

• Treating ECC-1:2018 numbers as current. ECC-2:2024 renumbered and removed controls; CSCC still cites ECC-1 numbers. Map against the current text.
• Reading the deletion of ECC 4-2-3-3 as "localisation is over". The NCA moved localisation to SDAIA's NDMO, CSCC 4-2-1-1 still applies to critical systems, and SAMA CSF 3.4.3 still asks for SAMA approval before cloud outside the Kingdom.
• Inventorying servers and not components. ECC 2-1 asks for an accurate inventory of technology assets. A server list cannot answer "where do we run XZ 5.6.1?"
• Patching straight to production. ECC 2.10.3.4 requires verification in a non-production environment first.
• Starting supplier evidence at renewal. SAMA CSF 3.4.1 expects cyber requirements in the tender and risk assessment before signing. By renewal, the supplier has little reason to agree.
• Leaving AI out of the inventory. SDAIA's risk levels cannot be applied to systems whose AI components nobody has listed.

FAQ

Does the NCA ECC apply to private companies in Saudi Arabia?

It applies to private sector entities that own, operate or host Critical National Infrastructure, and to companies affiliated with government agencies. Other private companies are strongly encouraged to adopt it, and many meet it through contracts with in-scope customers under ECC 4-1-2-3.

What changed between ECC-1:2018 and ECC-2:2024?

The industrial control systems domain moved to the OTCC, and the in-Kingdom hosting subcontrol was removed, with localisation passed to SDAIA's NDMO. ECC-2:2024 has 108 main controls and 92 subcontrols across four domains. Appendix C of the NCA PDF lists every change.

Does Saudi Arabia require an SBOM?

No primary text we reviewed uses the word. ECC 2-1 requires an accurate, updated inventory of technology assets, ECC 1.6.3.2 requires trusted and licensed library sources, and ECC 2-10 requires vulnerability management. An SBOM is the most practical way to evidence all three for software.

How fast must vulnerabilities be patched under NCA rules?

For critical systems, CSCC 2-9-1 requires remediation at least monthly for internet-connected systems, at least every three months for internal ones, and immediately for critical vulnerabilities. CCC 2-9-T-1-1 requires cloud tenants to assess and remediate at least every three months. The ECC itself asks for remediation by classification and risk.

What is the breach notification deadline under the Saudi PDPL?

Article 24 of the Implementing Regulation requires the controller to notify SDAIA within 72 hours of becoming aware of a breach that may harm personal data or data subjects, and to notify affected individuals without undue delay where they may be harmed.

Do SAMA-regulated banks need approval to use cloud outside Saudi Arabia?

SAMA CSF 3.4.3 says that in principle only cloud services located in Saudi Arabia should be used, and that explicit SAMA approval is needed for cloud services outside the Kingdom. SAMA approval is also required before using hybrid or public cloud at all.

Are SDAIA's AI Ethics Principles mandatory?

The document says it "shall apply" to all AI stakeholders in the Kingdom, and requires conformity assessments for high risk systems. How it is enforced in a given sector depends on the sector regulator; check with yours.

Can Safeguard run fully inside Saudi Arabia?

Safeguard's SaaS has no Saudi region. It can run on-prem in your data centre, in a private VPC or dedicated tenancy you choose, or fully air-gapped with its models inside your environment. The local runner keeps source code on your own machines in any setup.

Is Safeguard NCA certified?

No. Safeguard does not hold any NCA, SAMA or SDAIA certification or approval. It helps you produce the evidence those regimes ask for.

The first eleven steps above cover the inventory, gate and supplier evidence. 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 ECC 2-10-3 and CSCC 2-9-1 actually 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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. 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 Saudi entity whose repositories cannot be connected to an outside cloud service, 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 is the same discipline ECC 2.10.3.4 asks for before a patch reaches production.

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, that means asking an assistant for the 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

• The NCA Essential Cybersecurity Controls in plain language
• Saudi PDPL transfer rules for software teams
• UAE PDPL and sector data localisation: what teams should check
• Gulf AI data centres in 2026: UAE, Saudi Arabia and Qatar compared

Sources

• NCA, Essential Cybersecurity Controls (ECC-2:2024), English PDF
• NCA, Cloud Cybersecurity Controls (CCC-2:2024), English PDF
• NCA, Critical Systems Cybersecurity Controls (CSCC-1:2019), PDF
• NCA, Data Cybersecurity Controls (DCC-1:2022), PDF
• SAMA Rulebook, Cyber Security Framework 3.3.6 Application Security
• SAMA Rulebook, 3.3.15 Cyber Security Incident Management
• SAMA Rulebook, 3.3.17 Vulnerability Management
• SAMA Rulebook, 3.4 Third Party Cyber Security
• SAMA Rulebook, 3.4 Third Party Cyber Security, entire section
• SDAIA, Implementing Regulation of the Personal Data Protection Law
• SDAIA, Regulation on Personal Data Transfer outside the Kingdom, Version 2.0
• SDAIA, Guide to the Saudi Personal Data Protection Law for controllers and processors
• SDAIA, National Data Governance Platform, personal data protection
• SDAIA, AI Ethics Principles
• CISA, Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094
• CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem
• Safeguard docs, Saudi Arabia NCA ECC
• Safeguard docs, SAMA Cybersecurity Framework
• Safeguard docs, Saudi PDPL
• Safeguard docs, Compliance frameworks
• Safeguard docs, Local Runner
• Safeguard docs, Policies and Gates
• 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.