- Scope written for a compliance letter, not for attack surface, is the single biggest reason VAPT reports miss real risk.
- Cloud workloads need a different playbook than the classic network-and-web-app test: shared responsibility, provider rules of engagement, and identity misconfiguration matter more than open ports.
- An annual point-in-time test cannot cover a bank whose external footprint changes weekly; continuous or automated validation closes that gap between engagements.
- Assessors care less about the pass/fail letter than about evidence of a working remediation loop.
What separates a real penetration test from a scored scan
A vulnerability scanner such as Nessus, Qualys or InsightVM matches software versions and configuration against a signature database and returns a severity score. That is valuable and cheap to run often, but it is pattern matching, not attack simulation. Penetration testing, often marketed as ethical hacking, means a tester authorised to act like an intruder actually tries to get in, not just list what looks weak. A penetration test takes the scanner's output as a starting point and tries to prove impact: can this outdated component actually be exploited from where the attacker sits, does that low-severity misconfiguration combine with another one to reach a privileged account, does the web application's business logic let a normal customer act as an administrator. A statement of work that lists "vulnerability assessment and penetration testing" but prices for scanner time only will produce a report full of CVSS scores and no exploitation narrative. That gap is the most common complaint banks raise about their VAPT vendor, and it usually traces back to a scope and budget that never accounted for manual testing hours.
Why the scope line in the statement of work decides the outcome
The pattern that satisfies a compliance checkbox but not a real attacker
The recurring failure mode in GCC bank VAPT is a narrowly scoped, time-boxed test against a handful of production IP ranges, run once a year to produce evidence for an audit cycle. The tester finds what the scanner finds, writes it up against a fixed-fee budget that leaves no room for manual exploitation, and the bank files the PDF. Nothing in that process finds a chained privilege escalation path, a business logic flaw in the internet banking application, or a segmentation gap between the card payment network and the corporate LAN, because none of those show up in an automated scan. The report satisfies whoever asked for "a VAPT report" without testing whether the bank would actually survive a targeted attack.
This exact pattern shows up in UAE penetration testing engagements, and it is sharpest in Dubai's banking and fintech cluster, where new digital products ship faster than an annual test cycle can cover. A bank there can hold a folder of clean-looking reports and still have never had a tester move from one compromised workstation to the core banking network, because nobody asked for that in the statement of work.
What a scope built for attack surface looks like instead
A scope that produces useful findings starts from the bank's actual exposure, not from a list of IP addresses someone had lying around: internet-facing applications and APIs, VPN and remote access infrastructure, the segmentation boundary between cardholder data environment and everything else, identity infrastructure (Active Directory, Entra ID, any federation), and any cloud accounts that host customer data or payment processing. It allocates manual testing time proportional to complexity, not headcount of assets. It includes an internal test from an assumed-breach starting point, because external-only testing tells you nothing about lateral movement once a phishing email succeeds. And it commits to a retest window, because a report with no retest is a to-do list, not a security outcome.
Cloud workloads need a different playbook than the network-and-web-app test
Cloud infrastructure breaks the assumptions the classic VAPT methodology was built on. There is no fixed IP range to scan when infrastructure is defined in Terraform and torn down and rebuilt weekly. Ownership of the stack is split under the shared responsibility model, so a tester probing an AWS or Azure account is not looking for unpatched kernels, they are looking for identity and configuration mistakes: overly permissive IAM roles, publicly readable storage buckets, exposed management APIs, misconfigured security groups, and server-side request forgery that reaches the cloud metadata service to steal a temporary credential. None of that shows up on a traditional network scan, and a tester who only knows how to run Nmap and Nessus against an IP list will miss most of it.
What providers will and will not let you test
Cloud providers also restrict what a tester can legally do against their infrastructure. AWS, Azure and GCP each publish rules of engagement: testing the customer's own workloads is fine without prior notice in most cases, but denial-of-service testing, testing shared infrastructure, and testing another tenant's resources are not permitted. A vendor unfamiliar with cloud VAPT will either skip the cloud estate entirely and call the network test complete, or run tests that violate the provider's acceptable use policy and put the bank's account at risk. Confirming the tester holds current cloud-specific certification and has read the relevant provider's penetration testing policy before the engagement starts is a five-minute check that avoids both outcomes.
The gap between an annual test and a footprint that changes weekly
A single test, however well scoped, only proves the bank was secure on the day of the test. A new external service gets stood up, a certificate expires and gets replaced with a weaker configuration, a developer opens a debug endpoint and forgets to close it, and none of that is caught until next year's engagement. This is the argument for continuous or automated validation platforms rather than pure point-in-time testing. Autonomous penetration testing tools such as those from Pentera run attack simulations against the live environment on a schedule rather than once a year, which catches configuration drift between the big annual engagements. That does not replace a manual test led by an experienced tester who can chain findings the way a real adversary would, and it does not remove the need for a documented vulnerability management programme that tracks remediation SLAs by severity. It closes the gap between engagements, and for a bank whose attack surface changes every sprint, that gap is where most real incidents originate.
What assessors are actually looking for
Regulators in the region, including NESA and the UAE's Cybersecurity Law, don't spell out a specific VAPT methodology, but assessors expect evidence of regular security testing and a documented process for remediating what it finds. What assessors ask for in practice is rarely the raw pentest report itself. They want to see a defined testing cadence tied to risk (annual is a floor, not a target, for internet-facing and payment systems), a remediation tracker with owners and dates against each finding by severity, evidence that critical and high findings were actually closed rather than accepted and forgotten, and a retest confirming the fix worked. A bank that can produce that trail passes review more easily than one holding only a clean-looking report, because the trail demonstrates a working control, not a one-time exercise. Compliance should follow from that discipline rather than substitute for it: a programme built only to generate an annual report for the regulator will keep failing the same findings year after year even while staying technically compliant.
A scoping checklist before the next VAPT statement of work goes out
Before signing off on a VAPT vendor or renewing one, check the statement of work against these points:
- Manual testing hours are itemised separately from automated scanning, not bundled into one line.
- Scope explicitly includes cloud accounts and identity infrastructure, not just the on-premises network and public-facing web applications.
- The vendor states which cloud provider rules of engagement apply and confirms compliance with them.
- An internal, assumed-breach test is included, not external-only testing.
- A retest is included in the price, with a defined window after remediation.
- The report format separates exploited findings with proven business impact from scanner output with a CVSS score and nothing else.
- Someone owns tracking remediation against the report after delivery, with dates and severity-based SLAs, because common questions about pentesting scope and cadence come up again at renewal time and a documented answer speeds that conversation up.
