Compliance-Driven Penetration Testing
Most penetration tests are bought because something requires one. The framework decides the scope, the frequency and - the part people underestimate - the evidence you have to be able to produce afterwards. This page compares the regimes I test against, so you can work out which one you're actually answering to.
The frameworks, compared
Each of these mandates or effectively requires independent security testing. The differences that matter are who it binds, how often, and what you have to be able to show afterwards.
Saudi Arabia
- NCA Essential Cybersecurity Controls - the national baseline for government entities, their contractors and critical infrastructure. Control 2-11 covers penetration testing: defined, documented, approved and implemented, with scope covering internet-facing services and the technical infrastructure behind them. Periodic.
- NCA Critical Systems Cybersecurity Controls - where systems are classified critical, testing moves to at least every six months. The frequency change is what usually breaks the budget assumption.
- SAMA Cyber Security Framework - banks, insurers, finance companies and payment providers supervised by the Saudi Central Bank. Independent external testing at minimum annually, covering internet-facing systems, web applications and network infrastructure.
United Arab Emirates
- NESA / UAE Information Assurance Standards - federal entities and designated critical information infrastructure. Vulnerability assessment and penetration testing performed and tracked, annually in practice, with documented remediation and retest evidence for critical and high findings inside a defined window. Assessors review the tester's credentials.
- Dubai ISR (DESC) - Dubai government entities and their suppliers. Runs in parallel with NESA; one engagement can evidence both.
- CBUAE, DFSA and ADGM - onshore banks and finance companies, DIFC firms, ADGM firms. Regular independent testing expected across all three.
- VARA - Dubai virtual-asset service providers. Independent penetration testing at least annually under the Technology and Information Rulebook, with intelligence-led testing where VARA considers it proportionate.
- ADHICS - Abu Dhabi healthcare providers and their technology suppliers.
International
- PCI DSS - anyone storing, processing or transmitting cardholder data. Requirement 11.4 mandates internal and external penetration testing at least annually and after significant change, plus segmentation testing where segmentation is used to reduce scope.
- SOC 2 - not a prescriptive mandate, but penetration testing is the evidence most auditors expect against CC4.1 and CC7.1, and enterprise customers increasingly require it in the report.
- ISO 27001 - technical vulnerability management under Annex A, where testing is the practical way to demonstrate the control operates.
What assessors actually ask for
The report is necessary and not sufficient. Four artefacts make up a complete evidence package, and most organisations arrive with only the second:
- A scope document - what was tested, what wasn't, and why that scope was appropriate to the control. A test that excluded the systems the control cares about fails regardless of how good the testing was.
- The report - findings, severities, reproduction detail, and mapping to the controls in question.
- Documented remediation - what you fixed, when, and what you accepted as a risk with a stated reason. Accepting a risk is allowed; failing to record the decision isn't.
- Retest evidence - confirmation that the critical and high findings are actually closed, inside the window your framework specifies. NESA's 90-day expectation is the one that catches people, because a test done in month eleven leaves no room to retest before the annual cycle closes.
An attestation letter - who tested, what scope, which dates - ties the package together and is usually what gets filed or forwarded to a client. Every engagement here includes one.
Independence is the requirement people misread
Several of these frameworks use the word independent, and it has a specific meaning: the testing cannot be performed by the people who built or operate the system under test. An internal security team testing their own organisation's infrastructure satisfies some frameworks and not others; the team that wrote the application testing that application satisfies none of them.
This is a large part of why external consultants exist in this market, and it's worth checking against your specific obligation before assuming your in-house capability covers it. Getting this wrong is expensive, because you find out at assessment rather than at scoping.
How I scope a compliance engagement
The first conversation is about the obligation, not the technology: which framework, which control, what deadline, and whether anything has changed materially since the last test. From that I can usually tell you within a call whether one engagement covers everything you're subject to, and what the scope has to include to produce evidence that survives assessment.
What you get: a fixed price before anything starts, testing by the person you spoke to, immediate notification of anything critical rather than a surprise in the final document, a report written for both the board and the engineers, remediation support while you fix things, a retest, and the attestation letter. There's a sample report if you want the format first, and pricing for the general shape of the numbers.
By region
If you're in the Gulf, the regional pages go into more depth on which regimes apply and how they interact: penetration testing in Saudi Arabia and penetration testing in the UAE. For everyone else, the service pages cover the testing itself, and getting in touch is the fastest route to a straight answer about what you need.
Compliance testing questions
Usually yes, and it is much cheaper than the alternative. The technical scope overlaps heavily - external surface, web applications and APIs, internal network, Active Directory, cloud - so what differs between frameworks is the mapping and the reporting rather than the testing itself. The condition is that it must be scoped that way from the start: a test scoped only for PCI will not produce the evidence NESA wants, even though the underlying work is nearly identical. Tell me every regime you're subject to at scoping and the report maps findings to each of them.
No, and this is the most common reason evidence gets rejected. A scan runs known signatures against known versions and produces a list; a penetration test chains findings together to show what someone could actually do with them. Frameworks increasingly say so explicitly, and assessors have become good at spotting a scan report with a penetration test cover page - the tell is that every finding is a CVE and none of them connect to each other. The difference in detail is here.
Four things, and most organisations only keep the second. A scope document showing what was tested and why that scope was appropriate. The report itself, with findings, severity ratings and reproduction detail. Documented remediation of the critical and high findings. And evidence of a retest confirming the fixes worked, inside whatever window your framework specifies - 90 days is common. An attestation letter stating who performed the test, against what scope and on what dates ties it together, and is usually the single page that gets filed.
Annually is the common baseline - SAMA, NESA, VARA and PCI DSS all land there. Two things shorten it: a critical-systems classification under Saudi CSCC, which requires testing at least every six months, and significant change. Nearly every framework requires a retest after material changes to the environment regardless of when the last annual test happened, so a major migration or a new internet-facing application resets the clock in practice.
Usually, and the reasons are predictable: the scope was too narrow to cover what the control required, the testing was done by the team that built the system so it wasn't independent, no retest evidence was produced, or a scan was submitted as a penetration test. All four are fixable, and the fix is normally one correctly scoped engagement rather than a programme. Send me the assessor's finding and the previous report and I'll tell you which of the four it was before you spend anything.
Not sure which framework applies to you?
A short call usually settles it - and tells you whether one test can cover all of them.