- Scanning finds known signatures. Penetration testing proves exploitability and chains findings that a scanner treats as unrelated.
- OSCP is not the only credential worth trusting, but its exam format, a proctored, timed compromise of live machines with no multiple choice, makes it a reasonable filter for whether a tester can exploit systems rather than just run tools against them.
- Neither NESA nor NCA ECC names OSCP, or any specific certification, as mandatory. What assessors actually check is whether testing was manual, correctly scoped, and followed by a retest.
- The two failure modes that show up most often in UAE VAPT programmes are a scope that quietly excludes the systems that matter, and a single annual test with no retest cycle behind it.
What a scan tells you, and what a penetration test proves
Vulnerability scanners match software versions and configurations against a database of known issues. They are fast, cheap to run across a large estate, and genuinely useful for tracking patch coverage over time. What they do not do is prove exploitability. A scanner flags an outdated service version; it does not tell you whether that service is reachable from outside the network, whether the underlying flaw was actually patched despite an unchanged version banner, or whether chaining it with a misconfigured permission gets an attacker to domain admin. That gap between "this looks vulnerable" and "this is exploitable in this environment, right now" is the reason penetration testing exists as a separate discipline rather than a rebrand of scanning.
Treating VAPT as a single line item misses this distinction entirely, and it is the most common mistake procurement teams make when they build a scope of work around a fixed number of IP addresses rather than a fixed set of business risks. A properly run vulnerability management programme handles the scanning cadence, ticket routing and patch SLAs; VAPT sits on top of it as a periodic, deeper check on the assets where a missed vulnerability would actually hurt.
Why OSCP specifically, and why it is not the whole answer
OSCP (Offensive Security Certified Professional) is a hands-on credential: candidates get remote access to a set of machines and a fixed window to compromise as many as possible, then submit a professional report documenting how. There is no multiple choice, no open-book lookup of "the answer", and no partial credit for running a tool without understanding what it found. That format makes it a reasonable, if imperfect, signal that a tester can move from "I found a vulnerability" to "I used it to get somewhere I should not be."
It is not the only credential that proves this. OSWE, OSEP, CRTO and CREST-aligned certifications test similar or adjacent skills, and plenty of capable testers hold none of them and prove competence through work history instead. What OSCP is good for, when evaluating a provider, is a floor: if nobody on the delivery team holds it or an equivalent hands-on credential, ask directly how they validate manual exploitation skill, because "years of experience with security tools" is not the same claim.
What the exam actually requires
The current OSCP exam runs as a single proctored session against a mix of standalone and networked targets, with a written report due afterward that has to stand up to review. Passing requires escalating privileges on multiple machines under time pressure, which is a reasonable proxy for the same pressure a real engagement puts on a tester: a fixed testing window, a production environment you cannot break, and a client who wants evidence, not a screenshot of a tool's default output. It is a certification about doing, not about knowing terminology, and that is exactly the gap that separates a useful VAPT report from a padded one.
What separates a real penetration test from a report-generation exercise
A report built purely from automated tooling reads like a list of CVEs sorted by CVSS score. A report built from manual testing reads like a narrative: here is the entry point, here is how it chains into the next system, here is what an attacker gets at the end of the path, and here is the exact remediation that closes it. The difference matters because business risk rarely lives in a single critical finding. It lives in three or four medium-severity issues, an exposed test endpoint, a service account with more access than it needs, and a change control process that would not catch any of it, chained together into a path a scanner has no way to represent.
Automated platforms have narrowed part of this gap. Continuous, agent-based tools like the ones behind automated penetration testing platforms such as Pentera run real attack chains on a schedule rather than a point in time, which is useful for catching regressions between manual engagements. They still do not replace a skilled human tester on novel business logic or a target-specific chain; they replace some of the routine re-testing that would otherwise eat a human tester's time.
Manual testing is also the only reliable way to catch business logic flaws: a discount code that can be reused past its limit, an API that trusts a client-supplied user ID instead of the authenticated session, a password reset flow that leaks whether an email address exists. None of these trip a signature-based scanner because none of them are a known CVE. They are design mistakes, and finding them takes someone reading the application the way an attacker would, not someone running a tool against it.
Scoping decides the outcome before testing starts
The single biggest lever on whether a VAPT engagement finds anything real is the scope agreed before testing begins. A scope limited to a handful of internet-facing IP addresses, tested once a year, with no credentialed access to internal systems, will produce a clean report almost by construction, not because the environment is secure. A scope that includes the actual crown jewels, customer data stores, the identity provider, the systems that process payments or hold regulated data, tested with both external and authenticated internal perspectives, is what actually tells you something. If a provider's proposed scope looks easy to pass, that is worth questioning before signing, not after the report comes back clean.
What NESA and NCA ECC assessors actually check
Regional frameworks like NESA's UAE Information Assurance standard and Saudi Arabia's NCA Essential Cybersecurity Controls both call for periodic vulnerability assessment and penetration testing, but neither one prescribes a specific tester certification by name. What an assessor is actually looking for during evidence review is whether the testing was methodology-driven rather than scanner output relabelled, whether the scope covered the systems in the regulated boundary rather than a convenient subset, and whether findings were tracked to closure and retested, not just logged and left open. A OSCP-holding tester on the delivery team is a reasonable thing to show an assessor as evidence of capability. It is not, by itself, the compliance requirement.
Why so many UAE VAPT programmes underperform
Budget is part of it: leadership approves a VAPT line item as a one-time cost tied to an audit deadline rather than a recurring control, so testing happens once a year at most, right before the certificate renewal, on a scope narrow enough to finish quickly. That timing is backwards. The point of testing is to catch drift between audits, not to produce a document for the auditor.
Tool operators are not penetration testers
The other half of the problem is staffing. There is a real shortage of people who can do manual exploitation well, and it is cheaper to hire someone who can operate a vulnerability scanner and format its output into a PDF than to hire or contract someone who can chain findings into an actual attack path. Both roles get called "penetration tester" on a CV and in a proposal, and the buyer often has no easy way to tell them apart until the report lands and it turns out to be a re-skinned scan.
Getting VAPT right: a short list
Before signing off on a provider or a scope, it is worth checking a few things directly rather than taking the proposal at face value:
- Ask who on the delivery team holds a hands-on offensive credential (OSCP, OSEP, CRTO or equivalent), not just how many tools the firm licenses.
- Insist the scope covers the systems that would actually hurt if compromised, not just what is easiest to test in the available window.
- Require both external, unauthenticated testing and internal, credentialed testing where the environment allows it. Attackers rarely start and finish from the same vantage point.
- Treat findings as a retest obligation, not a closed ticket. A vulnerability marked remediated without a retest is an assumption, not a fact.
- Budget for testing more than once a year on anything internet-facing or holding regulated data. A single annual test only ever shows you the state of the environment on one day.
