Assessment and Testing Are Not the Same Service
A vulnerability assessment runs an automated scanner such as Nessus, Qualys or Rapid7 InsightVM against a target range and produces a list of findings ranked by CVSS score. It is fast, repeatable, and cheap per asset. It is also blind to anything that requires chaining two low-severity issues together, abusing legitimate application logic, or pivoting from one compromised host to a domain controller.
A penetration test starts where the scan stops. A tester takes the finding list, tries to actually get in, and then tries to get further: escalate privileges, move laterally, reach data that matters. The deliverable is not a severity table. It is a narrative of what an attacker could do, step by step, with the exact commands and evidence to reproduce each step.
Vendors selling both under one banner have an incentive to blur this line, because manual testing costs far more per hour than scanning. Read the statement of work line by line. If the only line item is "vulnerability scan of X IPs" with a fixed low day rate, you are buying an assessment, not a test, regardless of what the cover page says.
Why the Same Findings Reappear Every Year
The most common pattern in UAE enterprises that have run VAPT for several cycles without improving their exposure is this: the same scanner finds the same class of issue every year because remediation was never independently verified. A patch gets applied, the ticket gets closed, and nobody retests the specific exploit path to confirm it actually closed. Configuration drift and new deployments then quietly reopen it before the next annual cycle.
A second pattern is scope creep in the wrong direction. The test gets scoped to whatever is easiest to schedule, usually a handful of internet-facing IPs, while the internal network, the SaaS admin consoles, and the newer cloud workloads never make it into any statement of work. An attacker who gets a foothold through phishing does not care that your annual pentest only covers the DMZ.
A third is treating VAPT as a compliance artefact rather than a risk exercise. The report gets filed to satisfy an auditor's checkbox, findings get triaged by severity label rather than by actual exploitability in your environment, and the fixes that get prioritised are the ones that are cheapest to close rather than the ones that matter most.
Scoping Decisions That Actually Determine the Outcome
Three choices decide whether a VAPT engagement produces something useful, and all three get made before a single packet is sent.
Testing method. Black box testing gives the tester no credentials and no internal knowledge, which approximates an external attacker but burns most of the engagement time on reconnaissance. Grey box gives limited credentials, usually a standard user account, and mirrors the far more common real-world starting point of a phished employee or a compromised third-party account. White box gives full access and source code where relevant, and is the only realistic way to test complex web applications thoroughly within a fixed number of days. Most enterprises default to black box because it sounds more rigorous, then wonder why the report comes back thin.
Scope boundary. Internal, external, web application, mobile application, cloud configuration, and Active Directory are different disciplines with different tooling and different tester skill sets. A generalist who is strong at network pentesting is not automatically qualified to assess an API authorisation model or a multi-tenant SaaS deployment. Ask the provider directly which of these disciplines the assigned tester has actually delivered before, not which the company as a whole claims to offer.
Time and depth. A five-day engagement against fifty internal hosts produces a different quality of result than the same five days against five hosts. Providers under time pressure default to running tools and reporting whatever the tools surface, because there is no time left for manual verification or exploitation chaining. If the day count looks too low for the asset count, it usually is.
What a Retest Should Actually Prove
A retest is not rerunning the scanner against the same IP range and checking whether the finding count dropped. A proper retest targets the specific exploit path documented in the original report and confirms it no longer works, using the same technique the original finding was proven with. If the original finding was a SQL injection in a login parameter, the retest attempts that exact injection again; it does not just confirm the web application firewall now blocks the generic payload the scanner used.
This distinction matters for anyone answering to a regulator or an internal audit function. NESA, CBUAE, and ISO 27001 assessors generally expect evidence that remediation was independently verified, not just that a ticket was marked closed. Keep retest evidence, including screenshots or command output showing the specific exploit failing post-fix, as part of your audit trail rather than relying on the vendor's summary paragraph.
Where Automated Tooling Fits
Continuous or automated penetration testing platforms have a real place in a mature programme: they can rerun known exploit techniques against your environment on a schedule far tighter than an annual manual engagement allows, which catches drift and new exposure between the big assessments. They do not replace manual testing for complex logic flaws, business logic abuse, or novel chaining that a human tester spots by understanding what the application is actually for. Treat continuous validation as the thing that runs between manual engagements, not the thing that replaces them.
What to Ask a VAPT Provider Before You Sign
Ask who is actually doing the testing and what certifications and prior engagement history that specific person has, not the company's marketing page. Ask for a sample report with the client name redacted so you can judge whether findings come with reproduction steps and business impact, or just a CVSS number and a paragraph copied from a CVE description. Ask how retesting is scoped and priced, and whether it is included or billed separately, because a provider that treats retesting as an afterthought is telling you how they treat verification generally. Ask which specific scope disciplines, web, mobile, cloud, AD, they have delivered in the past twelve months, not which they list on their capabilities page.
Deciding If Your Programme Is Actually Working
Answer these honestly. Has a finding from last year's report ever reappeared this year under a different CVE number but the same root cause? Does your scope include the systems that would actually get hit first in a phishing-led compromise, or only the systems that were easiest to schedule? Do you have independent evidence that remediated findings were retested against the original exploit technique, not just closed in a ticketing system?
If any answer is uncomfortable, the fix is rarely more testing. It is better scoping, a tester with the right specialism for what you actually run, and a retest process that proves something instead of assuming it. Programmes built around a documented vulnerability management programme tend to close this gap because remediation and verification become tracked steps rather than a report nobody rereads. For the assessment side itself, pair periodic manual testing from a VAPT engagement scoped to your actual attack surface with continuous validation from a platform like Pentera to catch drift between cycles.
