Penetration testing in Saudi Arabia: scope to report

A good penetration test ends with three things on your desk: a list of the weaknesses an attacker could actually use, proof for each one, and a retest showing they are closed. This guide covers how to scope a penetration test in Saudi Arabia, the phases and how long they take, what the report must contain, and the questions that separate a real test from a scan with a cover page.

Why Saudi organisations test

For many Saudi entities, penetration testing is a regulatory requirement, not a nice-to-have.

• NCA Essential Cybersecurity Controls. Subdomain 2-11 of ECC-2:2024 requires the entity to define, implement and periodically review its penetration testing requirements. The minimum scope is every service the entity provides externally over the internet, with its technical components: infrastructure, websites, web applications, smartphone and tablet applications, email and remote access. Tests must be run periodically. ECC applies to government agencies and their affiliated companies, and to private entities that own, operate or host critical national infrastructure, according to the scope section of the same NCA document.
• NCA controls for other private companies. The Non-CNI Private Sector Entities Cybersecurity Controls, NCNICC-1:2025 (Arabic text) carry an equivalent penetration testing control, 2-11. It is mandatory for large entities in Category A and recommended for small and medium entities in Category B.
• SAMA Cyber Security Framework. For banks, insurers, finance companies and the other member organisations it covers, the SAMA Cyber Security Framework states that customer-facing and internet-facing services should be subject to annual review and penetration tests (3.2.4). It also lists penetration testing as part of security testing within change management (3.3.7).
• SAMA Cyber Resilience Fundamental Requirements. The CRFR apply to entities seeking to enter the SAMA Regulatory Sandbox or to obtain a licence. Control 3.2.6 sets penetration testing twice a year as a minimum, or after a major or critical change.

The practical reading: if you are regulated, the question is not whether to test. It is how well.

Penetration test or vulnerability assessment?

ECC treats them as separate subdomains: 2-10 for vulnerability management, 2-11 for penetration testing. A vulnerability assessment is broad and largely automated. It finds known weaknesses and ranks them. A penetration test spends a skilled tester's time chaining weaknesses together, proving impact, and finding what automated checks miss: broken authorisation between roles, business-logic flaws in a payment flow, a mobile app that trusts whatever the device tells it.

You need both. Periodic assessment keeps the list of known issues short. A penetration test tells you what an attacker would do with what remains.

Scope: the decision that sets the value

Most weak tests fail at scoping, not at testing. Settle these points before anyone signs.

What is in scope

Start from the ECC minimum: everything reachable from the internet. Then add what matters to your business. For a financial services firm that usually means:

• The customer portal or internet banking, and the APIs behind it
• Mobile apps on both major platforms
• The external network perimeter, including remote access gateways and email
• The internal network, tested the way an insider or a compromised laptop would see it
• The cloud configuration of the environment that holds customer data

How much the tester knows

• Black box. No information, like an outside attacker. Realistic, but slow, and it leaves whole areas untested.
• Grey box. Test accounts for each role, plus API documentation. The usual choice for applications, because most serious findings sit behind the login.
• White box. Source code and architecture. Worth it for high-value releases.

Rules of engagement

Put these in writing:

• A signed authorisation from someone who owns the systems
• Testing windows that avoid month-end close and salary-run peaks
• Production or staging, and whether staging truly matches production
• Named emergency contacts on both sides
• What happens on a critical finding mid-test: the tester stops and calls, rather than waiting for the report
• Where test data and evidence are stored, and when they are destroyed

Timeline: five phases

Phase	What happens	Owner
1. Scoping and authorisation	Asset list, test accounts, rules of engagement, signed approval	Client and tester
2. Reconnaissance and mapping	Enumerate hosts, endpoints, roles and data flows	Tester
3. Testing and exploitation	Manual testing against the agreed methodology, with proof of impact	Tester
4. Reporting and read-out	Draft report, technical walkthrough, executive briefing	Tester
5. Remediation and retest	Your team fixes, the tester verifies each finding	Both

For planning, a single web application and its API usually needs one to two weeks of testing effort. A mobile app adds its own block of time. Scoping often takes longer than testing when test accounts and approvals are slow, so start that first. Book the retest date at kickoff, so findings do not sit open until next year's cycle.

Methodology should be named, not implied. NIST SP 800-115 describes the planning, discovery, attack and reporting phases of technical security testing. For applications, the OWASP Web Security Testing Guide, the OWASP Mobile Application Security Testing Guide and the OWASP API Security Top 10 are the common references. Ask which ones the tester follows and how coverage is recorded.

What the report must contain

The report is the product you are paying for. It has two readers: the executive who accepts the risk, and the engineer who fixes it.

1. Executive summary. One page. Overall risk, the few findings that matter most, and what to fix first.
2. Scope and dates. Exactly what was tested, from where, with which accounts, and what was excluded. An auditor will check this against the ECC requirement to cover every externally provided service.
3. Methodology. The standards followed and the test cases covered.
4. Findings. For each one: title, affected asset, severity with a stated scoring method such as CVSS, evidence in the form of requests, responses and screenshots, steps to reproduce, business impact in plain words, and a specific fix.
5. Attack narrative. How individual findings chained into a real compromise path. This is where a test proves its value over a scan.
6. Control mapping. Each finding linked to the ECC, NCNICC or SAMA control it relates to, so compliance and IT work from one list.
7. Retest results. The status of every finding after remediation: closed, partly fixed, or open with an accepted risk and a named owner.

If the sample report you are shown is mostly pasted scanner output, the test will be too.

What changes in financial services

For banks, finance companies and fintechs, one annual test is rarely enough. The SAMA framework ties security testing to change management, so a significant change to a customer-facing application should pass security testing, which can include penetration testing, before it goes live. Plan the test calendar around the release calendar, not the financial year, and make the latest results part of the release approval. If you are in the Regulatory Sandbox or working towards a licence, plan for at least two cycles a year from the start, as the CRFR require.

Data handling during the test

Testers see real data. Under the Personal Data Protection Law, customer records exposed during a test are still personal data, and anyone who touches them is processing it. Agree in advance that the tester proves access with the minimum data needed, stores evidence on systems you approve, and destroys it on a fixed date after the retest.

Questions to ask before you sign

• Who tests, and will the same people run the retest?
• Can we see a redacted sample report?
• Is the retest included, and within what window?
• What do you do if you find a critical issue during testing?
• Where are our evidence and credentials stored, and how are they destroyed?
• Which methodology do you follow for web, mobile and API testing?
• How will findings map to the ECC or SAMA controls we report against?

How TQN runs a test

TQN's cybersecurity practice covers penetration testing for web, mobile, API and network, vulnerability assessment, application security testing built into release pipelines, cloud configuration review, and retesting after remediation. The work is designed to support PDPL and NCA requirements, and every report maps findings to the controls your auditors use. For banks, insurers and fintechs, see how we work with financial services. If you are still working out which NCA control set applies to you, read NCA ECC explained for mid-sized companies.

Start with a Security Posture Review

Give us 30 minutes and the list of systems you believe are in scope. We come back with a recommended test scope, the order to test in, and the controls each part supports. It is free. Book a Security Posture Review.