PTaaS in Saudi Arabia: Why Continuous Pentesting Fits ECC-2 Better Than Annual Tests How it maps to NCA controls, by Sumrite.

Many Saudi entities treat penetration testing as a once-a-year event booked to satisfy an assessor. That approach is defensible on paper, but it leaves eleven months in which new features, new APIs and new hostnames go live untested. This post explains what ECC-2:2024 actually says about testing frequency, how continuous testing maps to it, and when an annual test is still the right call.

What is PTaaS (continuous penetration testing)?

PTaaS, or penetration testing as a service, is expert-led penetration testing delivered continuously through a platform, with testers checking releases as they ship and findings published live as they are verified. It replaces one PDF a year with a rolling programme of full tests, release tests and retests.

A real PTaaS service is not an automated scanner with a dashboard. Automation covers the routine baseline, but every finding is tested by hand, and the focus stays on the broken access control, business-logic and chained issues that scanners cannot see. Our explainer on what PTaaS is covers the model in detail, and PTaaS vs traditional penetration testing compares cost, coverage and reporting side by side.

What does ECC-2:2024 say about penetration testing frequency?

ECC-2:2024 says penetration tests must be conducted periodically (ECC 2-11-3-2) and does not set a fixed interval such as “annually”. The entity decides the interval, writes it into its approved policy under ECC 2-11-1, and has the implementation reviewed periodically under ECC 2-11-4.

The official ECC-2:2024 text sets the scope just as clearly: all internet-facing services and their technical components, including infrastructure, websites, web applications, mobile apps, email and remote access (ECC 2-11-3-1). Nowhere in the ECC-2:2024 document does NCA specify a numeric interval for either vulnerability assessment or penetration testing.

NCA’s own guidance documents fill some of the gap. The Penetration Testing Standard template, published in NCA’s cybersecurity toolkits, states that:

• internet-facing systems are tested on a “scheduled and regular basis”;
• technical components and services of critical systems are tested every 6 months;
• remote work systems are tested at least once per year.

These templates are aligned with the earlier ECC-1:2018 and the Critical Systems Cybersecurity Controls, and they are templates rather than mandatory controls. They still show the direction of travel: NCA thinks in terms of regular, risk-based testing, not a single annual date. Our deep dive on NCA ECC penetration testing requirements covers control 2-11 line by line.

Why does an annual penetration test leave gaps under ECC-2?

An annual penetration test leaves gaps under ECC-2 because ECC 2-11 scope covers every internet-facing service, and services launched or changed after the test date stay untested until the next cycle. The test is accurate on the day it runs and drifts out of date with every release.

Three gaps show up repeatedly in Saudi assessments:

• Scope drift. The asset inventory under ECC 2-1 grows during the year: a new e-service, a marketing microsite, a partner API. An annual test scoped in January does not cover what went live in June.
• Change without testing. ECC 1-6 asks for cybersecurity requirements across the project and change lifecycle, including security review and compliance testing before applications go live. A single yearly test cannot sit in front of every launch.
• Slow remediation proof. Findings from an annual test are often retested months later, if at all, leaving the remediation tracker open long after fixes ship.

None of this makes an annual test non-compliant. It makes it harder to defend the word “periodically” when an assessor asks what happened to the services that launched mid-year.

How does continuous pentesting map to ECC-2 controls?

Continuous pentesting maps to ECC-2 controls by producing rolling evidence for ECC 2-11 (penetration testing), ECC 2-10 (vulnerabilities management), ECC 1-6 (secure development and change) and ECC 2-15 (web application security). One programme feeds several control areas at once.

ECC-2:2024 control	Annual test	Continuous pentesting (PTaaS)
ECC 2-11-3-1 scope: all internet-facing services	Scope fixed on one date	Scope updated as assets are added to the inventory
ECC 2-11-3-2 periodic testing	One cycle a year	Full tests plus release tests throughout the year
ECC 2-11-4 periodic review	Reviewed once, after the report	Review backed by live metrics on findings and fix times
ECC 2-10 vulnerabilities management	Severity-rated findings, often retested late	Findings tracked to closure with per-finding retests
ECC 1-6 project and change management	Rarely aligned with go-live dates	Release tests before or shortly after launch
ECC 2-15 web application security	Point-in-time check of WAF, TLS and authentication	Re-checked whenever the application changes

Continuous pentesting does not replace vulnerability scanning under ECC 2-10. NCA’s Vulnerabilities Management Standard template suggests monthly vulnerability assessment for internet-facing critical systems and quarterly for internal critical systems. Scanning gives breadth; pentesting gives depth. Our post on vulnerability assessment vs penetration testing under NCA ECC explains why you need both.

Does continuous pentesting also satisfy SAMA requirements?

Continuous pentesting satisfies SAMA requirements when the programme includes at least one full annual test of all customer and internet facing services, as SAMA Cyber Security Framework section 3.2.4 requires. For sandbox entrants and new licensees, a continuous programme also meets the twice-yearly minimum in the Cyber Resilience Fundamental Requirements.

The SAMA rulebook sets out both:

SAMA CSF 3.2.4

Customer and internet facing services should be subject to annual review and penetration tests.

SAMA CSF 3.3.7

Change management lists security testing, including penetration testing where applicable, as part of the change process.

SAMA CRFR 3.2.6

Penetration testing twice a year as a minimum, or after a major or critical change, for entities entering the sandbox or seeking a licence.

The phrase “after a major or critical change” is where continuous testing earns its place. A fintech shipping a new payment flow every month would otherwise need a separate project for each change. Read SAMA penetration testing requirements for banks for the full SAMA view, and mobile app and API penetration testing for Saudi fintechs if your exposure is mainly apps and APIs.

When is an annual penetration test still enough?

An annual penetration test is still enough when the internet-facing estate is small, changes rarely, and is not classified as a critical system, provided the test covers every service in ECC 2-11-3-1 and includes a retest. Continuous testing is a better fit, not a mandatory upgrade.

Our guide on how often to run a penetration test offers a general framework, and the penetration testing guide for Saudi Arabia covers each test type in the Saudi context.

How do you set up a PTaaS programme for ECC evidence?

To set up a PTaaS programme for ECC evidence, write the continuous model into your approved penetration testing policy, tie scope to the asset inventory, schedule a full baseline test, add release tests, and export dated reports for each cycle. The policy wording is what turns a delivery model into compliance evidence.

How Sumrite helps

Sumrite’s continuous pentesting (PTaaS) service is expert-led: testers verify every finding by hand, findings appear live with evidence and fix guidance, they can be sent to Jira or GitHub, and every fix is retested before it is closed. For Saudi organisations, we run the programme end to end with our verified NCA-registered partner firm and map each cycle’s report to ECC 2-11, ECC 2-10 and SAMA CSF 3.2.4. If you would rather start with a single test, the Sumrite VAPT report for Saudi reviews is delivered in 48 hours through our Saudi Arabia service.