Penetration testing in Saudi Arabia: what the rules require, how to scope it and how to choose a provider

In brief

• None of the NCA, SAMA, CST or PDPL texts requires every company in the Kingdom to run penetration tests. The obligation comes from the texts you answer to, such as those of the National Cybersecurity Authority (NCA), the Saudi Central Bank (SAMA) or the Communications, Space and Technology Commission (CST).
• The NCA Essential Cybersecurity Controls (ECC) require penetration testing "periodically" without setting an interval, and their minimum scope is the services you provide over the internet and their technical components.
• The intervals written into the texts: at least every six months for critical systems and for cloud service providers, every three, six or twelve months for operational technology depending on the facility level, annually for the customer- and internet-facing services of financial institutions, and at least twice a year for new financial entities under the CRFR.
• The Personal Data Protection Law (PDPL) does not mention penetration testing.
• As of 11 October 2026 there is no NCA licence in force for penetration testing, but registration with the NCA has been a regulatory requirement for anyone providing cybersecurity services since 1 August 2022.

Which requirements apply to you?

Start with the regulator you answer to, because the interval and scope differ from one text to the next:

• A government entity, one of its companies or affiliated entities, or a private-sector entity that owns, operates or hosts critical national infrastructure: the Essential Cybersecurity Controls (ECC) apply. If you have systems classified as critical, the Critical Systems Cybersecurity Controls (CSCC) apply to them as well.
• A cloud service provider, or one of the entities above that uses cloud: the Cloud Cybersecurity Controls (CCC), which add to the ECC rather than replace it.
• One of the entities above that owns or operates industrial control systems in facilities deemed critical: the Operational Technology Cybersecurity Controls (OTCC).
• A financial institution regulated by SAMA: the SAMA Cyber Security Framework (CSF), plus other SAMA texts depending on your situation.
• A licensed or registered service provider in the ICT sector: the CST Cybersecurity Regulatory Framework (CRF), unless you are classified as critical national infrastructure, in which case you follow the ECC.
• A private company outside these groups: none of these texts requires you to run penetration tests. The NCA encourages other organisations to apply the ECC, and testing remains a decision you base on your risks and on what your contracts require.

The Essential Cybersecurity Controls: subdomain 2-11

The edition in force is ECC-2:2024. Subdomain 2-11 exists to assess and test how effective the entity's cybersecurity defences are by simulating real cyber-attack techniques and methods, so that unknown weaknesses are found. It has four controls:

• 2-11-1: penetration-testing cybersecurity requirements are identified, documented and approved.
• 2-11-2: the requirements are implemented. The Arabic text is more direct: penetration testing must be carried out in the entity.
• 2-11-3: as a minimum, the requirements cover a scope that includes all externally provided services (via the Internet) and their technical components, including infrastructure, websites, web applications, smartphone and tablet applications, email and remote access, and penetration tests run periodically.
• 2-11-4: implementation of the penetration-testing requirements is reviewed periodically.

Three points that are often missed:

• The text sets no interval. "Periodically" is all the control says, and the word "annual" does not appear in ECC-2:2024. The NCA's ECC implementation guide suggests an action plan with an annual schedule, but it is guidance, not a binding control. Set the interval in your penetration-testing requirements, which 2-11-1 requires you to identify, document and approve.
• The minimum scope is what faces the internet. Internal systems are not in the ECC minimum, although they are in the CSCC scope for critical systems.
• The ECC does not tie penetration testing to project launches or changes. Control 1-6-2 asks, in those cases, for vulnerability assessment and remediation and a review of configuration, hardening and update packages before launch. That is a different requirement from a penetration test.

The substance of this subdomain has not changed since the 2018 edition.

Critical systems, cloud and operational technology

• Critical Systems Cybersecurity Controls (CSCC-1:2019): the scope widens to all technical components of critical systems and all their internal and external services, the test is run by a qualified team, and it happens at least once every six months (controls 2-10-1 and 2-10-2). The monthly and quarterly intervals in the CSCC are for vulnerability assessment, not penetration testing.
• Cloud Cybersecurity Controls (CCC-2:2024): a cloud service provider must test its whole Cloud Technology Stack at least once every six months. There is no penetration-testing control for cloud tenants in the CCC, so a tenant falls back on ECC subdomain 2-11, with a separate control requiring vulnerability assessment and remediation at least every three months.
• Operational Technology Cybersecurity Controls (OTCC-1:2022): the interval depends on the facility level: every three months at level 1, every six months at level 2 and every twelve months at level 3. At level 1 the controls also require the test to cover the OT environment and the networks connected to it, to be run by a qualified team, and to have limited or no impact on production, or to run on an identical separate environment.

Financial sector: what SAMA requires

The SAMA Cyber Security Framework is still version 1.0 (May 2017) and in force. On penetration testing it says:

• Customer- and internet-facing services should be subject to annual review and penetration tests (sub-domain 3.2.4). This is the only penetration-testing interval in the framework.
• Change management should include security testing that, where applicable, includes penetration testing and code review, plus a post-implementation review of the related cybersecurity controls (sub-domain 3.3.7). The framework has no text requiring a penetration test "before go-live".
• The framework expects the security operations centre's effectiveness to be tested independently and periodically, giving red teaming as an example.

Other SAMA texts add their own requirements:

• The Cyber Resilience Fundamental Requirements (CRFR), for new financial entities seeking a licence or entry to the Regulatory Sandbox: penetration testing at least twice a year, or after any major or critical change.
• In the Regulatory Sandbox, "Vulnerability Assessment & Penetration Testing" is one of the operational readiness criteria a fintech must meet before it may go live and onboard customers.
• Receiving and lending banks in initial public offerings: a comprehensive testing programme for IPO systems that includes vulnerability assessment, penetration testing and a compromise assessment.
• The Financial Entities Ethical Red Teaming framework (FEER): a red teaming test at least once every three years for each institution SAMA regulates. The framework itself states that red teaming is not a penetration test, and SAMA's Green Team approves the choice of provider, so the institution does not choose it alone.

ICT sector: the Communications, Space and Technology Commission

The CST Cybersecurity Regulatory Framework (CRF), second version (October 2023), applies to licensed and registered service providers in the ICT sector. Providers classified as critical national infrastructure follow the ECC instead, and give CST a copy of the compliance reports they submit to the NCA.

• The CRF's penetration-testing controls (4.16) start at compliance level 2, so they bind a provider only when CST has set it a target of level 2 or above.
• The provider sets its own requirements, including purpose and frequency, and defines a process that sets scope and frequency and uses standard methodologies.
• Testing "at least once quarterly" is given only as an example, not a fixed interval. The Arabic text, which prevails over the unofficial English translation, applies the example to sensitive information assets; the English says "critical information assets".
• The test report goes to the relevant departments to trigger remediation where needed, through patch management. The CRF does not require the tester to be independent.

The PDPL does not mention penetration testing

The Personal Data Protection Law requires the controller to implement the necessary organisational, administrative and technical measures to protect personal data (Article 19). Its Implementing Regulation asks for the security and technical measures needed to limit the risk of data leakage, and for compliance with the relevant NCA controls, or with generally accepted cybersecurity practices and standards where the controller is not bound by those controls (Article 23).

Neither the law nor the regulation mentions penetration testing. If someone tells you the PDPL requires one, ask for the article number. One clear deadline in the regulation is notifying the competent authority of a personal data breach within 72 hours of becoming aware of it, where the breach could harm data subjects (Article 24). Penetration testing is one practical way to make reaching that point less likely.

Does a penetration-testing provider need a licence?

• Registration: since 1 August 2022, registering with the NCA has been a regulatory requirement for any entity providing cybersecurity services, solutions or products in the Kingdom (Registration and Licensing). Ask the provider for proof of registration, and look for its name on the list of registered providers on the NCA website. The list shows only the entity's name and website, not the services it offers.
• Licensing: the only NCA cybersecurity services licence in force is the Managed Security Operations Center (MSOC) Services Licence, in its two tiers. There is no licence in force for penetration testing, so anyone citing an "NCA penetration-testing licence" should explain what they mean.
• What is coming: from 25 February to 26 March 2026 the NCA consulted publicly on a draft Regulatory Framework for Licensing Cybersecurity Services, Products and Solutions (RFCS-1:2026), which proposes a specialised licence category that includes penetration testing. As of 11 October 2026 we found nothing on the NCA website showing it has been issued in final form. If it is issued in this form, a licence check would be added to how you choose a provider, so watch for the official announcement.
• Certifications: NCA's controls (ECC, CSCC, CCC and OTCC) do not name specific certifications for testers; the CSCC and OTCC say only "qualified team". The draft RFCS-1:2026 proposes that services be delivered by personnel holding a qualification certificate specified by the NCA. Ask for the CVs of the people who will actually run your test, and a redacted report from a past engagement.

How to scope the test

• Start with the regulatory minimum. If you are within the ECC's scope, that is every service you provide over the internet and its technical components. The ECC implementation guide lists APIs, servers used for external services, email and remote-access servers, and network devices that provide external services within that scope.
• Then add what your risks or other controls call for: the internal network, critical systems (mandatory under the CSCC) and cloud environments.
• Choose the approach: black box with no prior knowledge of the system, grey box with partial knowledge and test accounts, or white box with access to source code. Choose between external testing from the internet and internal testing from inside the network, or both.
• Each kind of target has a recognised methodological reference: OWASP WSTG for web applications, OWASP MASTG for mobile apps, the OWASP API Security Top 10 for APIs, and NIST SP 800-115 for the overall method in four phases: planning, discovery, attack and reporting.
• Record the rules of engagement before you start: written authorisation, the approved targets, test windows, exclusions, contacts and escalation, and the host's or cloud provider's approval where its terms require it.
• Agree the retest in advance. It verifies that the vulnerabilities were actually closed.

How to choose a provider

The ECC third-party cybersecurity controls (subdomain 4-1) give you a ready list of what the contract should contain and what to do before signing it:

• Non-disclosure clauses, and secure removal of your data by the provider when the service ends.
• Communication procedures if a cybersecurity incident occurs.
• An obligation on the provider to apply your cybersecurity requirements and policies.
• Before signing: a cybersecurity risk assessment, and confirmation that controls to reduce those risks are in place.

If the test covers critical systems, also check the CSCC controls on outsourcing and managed services for critical systems (4-1-1). They require screening or vetting of the companies and personnel who work on those systems, and reliance on Saudi companies and organisations in line with the relevant legislative and regulatory requirements. The text is written about outsourcing and managed services in general, so confirm how it applies to a testing engagement.

Then ask the provider:

• Is it registered with the NCA?
• Who, by name, will run the test, and what experience do they have with your kind of targets?
• How does it handle test evidence and the data it sees, where does it keep them and when does it delete them?
• How will it tell you about a critical vulnerability found during the test, before the final report?
• Does the proposal include a retest after remediation?
• Does the report map findings to the controls you answer to (ECC, SAMA CSF or CRF)?

And watch for these signs:

• An automated scan sold as a penetration test, with no manual exploitation and no evidence.
• Promises of guaranteed results, or a "compliance certificate" issued after the test. A test report is one piece of compliance evidence, not a certificate of compliance.
• A claimed NCA licence for penetration testing: no such licence is in force as of the date of this article.

How often must you run a penetration test in Saudi Arabia?

It depends on the text you answer to:

• ECC: periodically, at an interval you set in your approved requirements.
• CSCC (critical systems): at least once every six months.
• CCC (cloud service providers): at least once every six months.
• OTCC: every three, six or twelve months depending on the facility level.
• SAMA CSF: annually for customer- and internet-facing services, and within change management where applicable.
• CRFR: at least twice a year, or after any major or critical change.
• CST CRF: set by the provider; the text gives once every three months for sensitive information assets as an example.

Is a vulnerability scan enough instead of a penetration test?

No. The controls treat them separately: in the ECC, vulnerability assessment sits under vulnerability management (2-10) and penetration testing under 2-11, and the CSCC and CCC set separate intervals for each. A scan finds known vulnerabilities; a penetration test tries to exploit them and chain them together to prove the real impact.

Does SAMA require a penetration test before any system goes live?

The Cyber Security Framework does not say so. What it does say is annual testing of customer- and internet-facing services, and security testing within change management that includes penetration testing where applicable. The text that ties penetration testing to the period before go-live is the Regulatory Sandbox operational readiness criteria, and the CRFR asks for a test after any major or critical change.

Is a red team exercise a substitute for a penetration test?

No. FEER states plainly that red teaming is not a penetration test. A penetration test assesses specific assets for vulnerabilities, while a red team simulates a realistic attack on the whole organisation to measure how well it detects and responds.

How DataSec helps

We provide penetration testing of web applications, APIs, mobile apps, external and internal networks and cloud environments, with a written scope and signed rules of engagement. You receive an executive report and a technical report with exploitation evidence and remediation steps, and a matrix that maps findings to ECC and SAMA CSF controls, and we then retest the findings you have remediated once, within an agreed period. If you need continuous tracking of vulnerabilities between tests, see vulnerability management.

To scope a test that fits the regulator you answer to, request a quote.

This article summarises the official texts as published up to 11 October 2026 and is not legal advice. Check the version of each text in force before relying on it.