VAPT for cloud workloads means vulnerability assessment and penetration testing scoped to what an organisation actually controls under the cloud shared responsibility model: identity, storage and network exposure, workload logic, and the pipelines that deploy all of it. Get the scope wrong and the test comes back clean while the real exposure goes untested.
- Cloud breaches usually start with a misconfigured identity or storage control, not a software vulnerability, so scope the test around configuration and access paths first.
- Automated scanners catch known misconfigurations fast across large estates but do not trace privilege escalation chains or business logic flaws.
- Passing a compliance audit and surviving a real attack path are different tests. Treat the audit as the minimum, not the target.
- Choosing internal capability versus an external tester comes down to testing frequency and whether anyone in-house can test the platform without a conflict of interest.
Why a cloud VAPT is a different exercise from a data centre one
A traditional penetration test has a fixed target: a network range, a set of servers, an application with a login page. Cloud workloads do not sit still. Auto-scaling groups spin instances up and down, infrastructure gets redefined through code on every deployment, and a service account created for a one-off migration script can outlive the project by years. A test scoped like a data centre engagement, a list of IP addresses and a start date, misses most of what causes real cloud breaches.
The shared responsibility model is the reason. The cloud provider secures the physical infrastructure and the hypervisor. Everything above that line, identity policy, storage permissions, security group rules, container configuration, application logic, and the code that provisions it, belongs to the tenant. Most cloud incidents trace back to a mistake on the tenant side of that line: a bucket left with public read access, a role trusted by too many accounts, an API deployed without authentication though meant to stay internal. None of that shows up in a test built around scanning IP ranges for open ports, and the pattern holds across the wider GCC as well as the UAE.
What the scope actually needs to cover
A cloud VAPT worth the invoice covers, at minimum:
- Identity and access: role definitions, cross-account trust, service accounts with standing privileges they no longer need.
- Storage: bucket permissions, default encryption, and whether anything meant to be private is reachable without authentication.
- Network exposure: security group rules, management interfaces reachable from the internet, load balancers routing to services that assume they are internal.
- APIs: authentication on every route, rate limiting, and authorisation checks that enforce tenant or user boundaries rather than trusting a client-supplied identifier.
- Serverless functions: secrets sitting in plaintext environment variables, and execution roles broader than the function needs.
- Containers and registries: base images with known vulnerabilities, and registries that do not require authentication to pull.
- The deployment pipeline: hardcoded credentials in repositories, and infrastructure-as-code changes that reach production without review.
Identity is the perimeter that matters most
Of that list, identity deserves the most attention, because privilege escalation in cloud environments rarely needs a software exploit. It needs a chain: a low-privilege role that can modify a policy, a policy that can be attached to a more privileged role, and a more privileged role that can read secrets or assume an administrative identity. Each step looks harmless alone. A tester who only checks whether individual permissions are excessive misses the chain, which is what separates a serious cloud tester from a scanner run with a report template attached.
Where automated scanning stops and manual testing takes over
Automated tools are useful and worth running continuously, not just at test time. They flag exposed management ports, default credentials, missing encryption, and known CVEs, across far more assets than a team could cover by hand. What they do not do well is anything that requires understanding what the application is supposed to do. Broken access control between tenants, a payment flow that trusts a client-supplied price parameter, a password reset flow that leaks a token somewhere a scanner would not think to look: these need someone tracing the logic by hand and testing a hypothesis. A clean automated scan is evidence of an absence of known signatures, not evidence of security.
Vendor choice for the scanning layer matters less than assumed. Whether the programme runs on Nessus or another scanner, the tool finds roughly the same class of known issues. The differentiator is what happens after the scan: which findings chain into an actual attack path, and which get triaged as noise.
Compliance testing and security testing are not the same question
Regulatory frameworks relevant to UAE and wider GCC organisations, NESA, CBUAE, SAMA, ISO 27001, generally expect evidence of periodic penetration testing scoped to internet-facing and cloud assets, a remediation process, and retesting of anything rated critical. That is a real bar, and also a floor rather than a ceiling. An assessor reviewing a report showing a test ran and common issues were checked will accept it, whether or not the test modelled how an attacker with a foothold would move through the environment. Treating a compliance-driven test and a security-driven test as interchangeable is how organisations end up compliant and still exposed.
Internal team or external tester
Building an internal offensive capability makes sense when testing needs to happen often, for example after every significant deployment, and the team has genuine depth across the cloud providers in use. It does not make sense as a substitute for independent testing of that same team's own deployments, because whoever built the environment is the worst-positioned person to find their own blind spots. Most organisations land on a mix: continuous automated scanning run internally, plus a scoped external engagement on a fixed cadence and after material architecture changes. Ask an external tester specifically how they handle multi-account environments, cross-account IAM trust, and serverless workloads, since generic, on-premises-oriented testers tend to be weakest there. A properly scoped VAPT engagement should say upfront which of these it covers.
What separates a useful report from a checkbox exercise
The report is where most of the value shows up or gets lost. A useful one prioritises findings by exploitability and by what each finding actually reaches, not by CVSS score alone, since a high-CVSS finding on an isolated asset can matter less than a medium-severity misconfiguration that opens a path to customer data. It documents attack paths, not a flat list, so an engineer can see how three unrelated-looking findings combine into a real route to compromise, and it includes evidence a technical reviewer can act on directly. A report that stops at a severity table and a generic remediation line is not doing the job.
Before scoping the next test
Test again after material changes, not on a fixed calendar alone, since a new IAM role or a newly exposed API can open a critical path between scheduled tests. Prioritise remediation by what an attacker could actually reach. Fold findings into the ongoing vulnerability management programme rather than treating each report as a standalone project, and check the next SOW against the scoping mistakes covered in why most enterprises get VAPT wrong in the UAE. A test that never gets acted on is not a security control. It is a record of a decision not to fix something.
