- Cloud VAPT tests the control plane (IAM, storage permissions, network configuration) as well as the workloads running on it, not just the network layer
- Public or over-permissioned object storage, S3 buckets, Azure Blob containers, Google Cloud Storage, remains the single most common finding across cloud assessments generally, not a one-off incident
- Cloud providers restrict what you can test without prior authorisation; scoping a cloud VAPT wrong can breach the provider's acceptable use terms before you find a single vulnerability
- Assessors reviewing UAE entities increasingly want cloud-specific evidence: an IAM access review, a public-access audit of storage, and a report scoped explicitly to the cloud environment, not a generic network pentest report with a cloud logo on the cover
What Cloud VAPT Actually Covers
Traditional VAPT assumes a perimeter: a firewall, a DMZ, a set of externally routable IPs to scan. Cloud infrastructure does not have that shape. Under the shared responsibility model, the provider secures the physical infrastructure and the hypervisor; the organisation secures everything it configures on top, identity policies, storage permissions, network rules, and the workloads it deploys. A cloud VAPT has to test both layers.
The control plane layer covers IAM roles and trust relationships, storage bucket and container permissions, security group rules, exposed management interfaces and APIs, serverless function permissions, and logging coverage. The workload layer covers the operating systems, applications, and services running on compute instances and containers, closer to a conventional VAPT scope once you are inside the environment.
Missing either layer produces a misleading result. A workload-only scan can report a clean instance while an IAM role attached to it can assume administrator access across the account. A control-plane-only review can flag a correctly configured bucket while an unpatched application behind it has a remote code execution flaw.
Why Storage Buckets Keep Showing Up
Public or over-permissioned object storage is consistently the highest-frequency finding across AWS S3, Azure Blob, and Google Cloud Storage alike. The patterns repeat:
- Bucket policies and access control lists are configured separately, and a permissive ACL can override an otherwise sensible bucket policy without anyone noticing
- Account-level "block public access" settings get overridden on individual buckets for a specific integration and never get reverted
- Presigned URLs are issued with expiry windows measured in days rather than minutes, so a leaked link stays exploitable long after the task it was created for
- Third-party SaaS tools are pointed at a bucket with broad read or write access instead of a scoped, object-prefix policy
- Versioning and access logging are left disabled, so even after a bucket is locked down there is no record of what was accessed while it was open
Authorisation Before Anything Else
Cloud providers set explicit rules on what can be tested and how. AWS permits most testing against your own resources without pre-approval but still restricts DNS zone walking and denial-of-service simulation. Azure and Google Cloud each publish their own rules of engagement. Before any tooling runs, the scope needs to name which accounts, subscriptions, and resource ranges are in play, the testing window, and which shared services are out of scope because the underlying infrastructure belongs to the provider, not the customer.
Multi-Tenancy Limits What You Can Test
You cannot test the hypervisor, the physical network, or another tenant's workloads, and no legitimate engagement attempts to. That is a real constraint on scope, not a gap in method, and a cloud VAPT report should say plainly what layer was and was not tested rather than implying full-stack coverage it did not have.
Tooling: Control Plane and Workload Layer Need Different Tools
Configuration and posture issues, IAM, storage permissions, network rules, are found with cloud security posture management tools, either the provider's native services or third-party scanners built for multi-cloud environments. Workload-layer vulnerabilities need authenticated scanning against the actual instances and containers, the same category of tooling used in a structured vulnerability management programme on-premises, Nessus among them. Exploitation of confirmed findings uses conventional penetration testing tooling once the target is identified. Continuous validation between full assessments matters here more than on-premises, since cloud configuration drifts between annual test cycles far faster than a segmented network does.
What Assessors Actually Ask For
For UAE entities working against NESA, DESC, CBUAE expectations, or ISO 27001, assessors reviewing a cloud environment expect evidence, not assurances. That means a cloud asset inventory that reconciles against the billing account, an IAM access review with named owners and review dates, a public-access audit of every storage bucket, and a VAPT report stating explicitly which accounts, regions, and layers were in scope and when testing occurred. A clean external port scan does not answer any of that on its own.
Remediation Order That Actually Reduces Risk
Findings rarely need fixing in report order. Public or externally writable storage comes first, it is the fastest for an outsider to find and the most damaging when it holds customer data. Over-permissioned IAM roles come next, particularly any role trusted by more than one service, since a compromised credential pivots further in a cloud account than on a segmented network. Exposed management ports open to any source follow. Logging gaps come last on urgency but matter most for the next incident, since they decide whether anyone can reconstruct what happened.
Run a cloud VAPT as a recurring exercise tied to your cloud security posture rather than a one-time deliverable, and check every new bucket, role, or exposed endpoint before it goes live, not after an assessor asks about it.
