VAPT for Azure cloud security tests whether the controls a bank actually configured, not the controls Microsoft ships by default, hold up against a real attacker. It combines a control-plane configuration review (identity, network, key management) with manual exploitation of what those controls expose, scoped strictly to the layer the customer owns under Azure's shared responsibility model.
- Azure VAPT lives mostly in configuration, not code: identity, network segmentation, storage access, and key management drive most findings.
- Microsoft's Unified Rules of Engagement let you test most Azure services without pre-approval, but a short list of activities still needs a request filed first.
- Annual, point-in-time testing misses the drift that Infrastructure as Code and self-service subscriptions introduce between assessments.
- Assessors want scope documents, rules of engagement sign-off, and retest evidence, not just a findings PDF.
What VAPT on Azure actually tests
Vulnerability assessment and penetration testing on Azure is not the same exercise as testing an on-premises network, and treating it that way is the first mistake. There is no operating system to patch on most of what a bank actually deploys: PaaS services such as Azure SQL, App Service, Key Vault, and Storage Accounts are patched by Microsoft. What is left to test is configuration: who can reach a resource, what identity can act on it, and what happens when a credential or token leaks.
A vulnerability assessment on Azure means pulling the control plane apart: Azure Policy assignments, Network Security Group and Application Security Group rules, RBAC role assignments against least privilege, Key Vault access policies versus the newer RBAC model, and Entra ID conditional access coverage. A penetration test proves that a gap in one of those areas is exploitable: an over-scoped managed identity reading secrets it should never see, a storage account with anonymous blob access serving up something sensitive, or a service principal with a stale client secret still active months after the project that created it ended.
Where the shared responsibility line falls
The line moves with the service model. On IaaS (a virtual machine), the customer owns the guest OS, the application, and the network configuration around it, so classic OS and web application testing still applies. On PaaS (App Service, Azure Functions, Cosmos DB), the customer owns identity, access configuration, and application code, but not the runtime underneath. On SaaS layered on Azure (Dynamics, Power Platform), the customer is mostly down to configuration and data governance. A scope document that does not name the service model for every asset leaves the tester guessing what they are actually allowed, and expected, to test.
The findings that keep showing up
Across GCC Azure estates the same handful of issues account for most of the real risk, in roughly this order of frequency:
- Storage accounts with public blob or container access left on, usually set during a proof of concept and never revisited before production.
- Network Security Groups broader than the application needs, most often an inbound rule for RDP or SSH scoped to "Any" instead of a jump host or Azure Bastion.
- Managed identities and service principals granted Owner or Contributor at the subscription level when the workload only ever touches one resource group.
- Key Vault access policies that predate the RBAC model and were never migrated, so access is granted per secret with no audit trail worth trusting.
- Entra ID conditional access that covers primary admin accounts but not break-glass accounts, guest users, or legacy authentication protocols that bypass MFA entirely.
- Diagnostic logging turned off or routed nowhere, so an assessor asking to see the sign-in logs for an incident gets silence instead.
Microsoft's rules of engagement
A detail that trips up teams new to cloud testing: you do not need Microsoft's advance permission to run a penetration test against your own Azure tenant for most activities. Microsoft's Unified Rules of Engagement, published for Azure, Dynamics 365, and Power Platform, permit testing of your own resources without prior notification for the large majority of attack techniques. What still requires a request through Microsoft's support channel is a short, explicit list: DDoS simulation, testing that could affect other tenants on shared infrastructure, and a handful of other named categories. Read that document before scoping anything. Assuming sign-off is needed for a standard configuration review adds weeks to a project that does not require it; assuming it is not needed for an activity that does risks a suspended subscription.
Why annual testing keeps failing banks
A VAPT report is a photograph. Azure environments do not hold still. A resource group spun up by a development team, a Terraform module reused from a public repository with a permissive default, a service principal created for a proof of concept and never decommissioned: any of these shift the attack surface between one assessment and the next, and a bank running a single VAPT cycle a year has no visibility into what happened in between.
The fix is not necessarily more penetration tests. It is continuous configuration monitoring alongside periodic manual testing: Microsoft Defender for Cloud's secure score and regulatory compliance dashboards catch drift as it happens, and a manual test twice a year validates what Defender for Cloud cannot see: business logic, chained privilege escalation, actual exploitability. Treating VAPT as an annual compliance checkbox while treating posture management as a separate tool is how banks end up with a passing audit report and an exploitable subscription at the same time.
Automation versus manual testing
Automated tooling has a real, bounded job here: enumerating role assignments across a tenant, flagging public storage endpoints, mapping Entra ID group nesting, and building the attack graph a human would take days to construct by hand. ScoutSuite for multi-cloud configuration review, Stormspotter and AzureHound for Entra ID attack path mapping, and PowerZure for exploiting common Azure misconfigurations belong in most engagements.
What automation does not do well is judge intent. A service principal with Contributor rights on one resource group might be correct for its job, or a leftover from a migration nobody cleaned up. Automated output tells you the permission exists; only someone who understands the application can tell you whether it is a finding. An unfiltered scanner export, with no manual validation of exploitability or business impact, is the most common reason VAPT reports get rejected by auditors and by the banks that commissioned them.
What assessors actually want to see
When CBUAE examiners, internal audit, or a third-party assessor review a bank's VAPT programme, the artifact they ask for first is rarely the findings report. It is the scope document and rules of engagement sign-off that preceded it: what was in scope, what was explicitly excluded, who authorised the test, and what dates it ran. Second is evidence of remediation tracking with CVSS scoring and target dates, not just a list of findings with no closure trail. Third is proof of retesting: a finding marked remediated with no retest evidence behind it does not satisfy a competent reviewer. Build the programme around producing those three artifacts and the report itself becomes the easy part.
A decision rule for scoping the next assessment
If a workload processes customer data, sits in a production subscription, or exposes an internet-facing endpoint, it belongs in the annual manual test scope, no exceptions. Everything else can sit under continuous posture monitoring with a lighter review. Before signing off any Azure VAPT statement of work, confirm three things: the scope document names the service model for every asset, the rules of engagement have been checked against Microsoft's current published list, and the deliverable includes a retest cycle rather than just a findings PDF. An engagement that skips any of the three is a compliance exercise wearing a security engagement's clothes.
For the identity and posture side of this, Microsoft Entra ID conditional access and Microsoft Defender for Cloud cover the continuous half; VAPT covers the periodic, adversarial half. For how the testing programme itself is typically structured, see this overview of penetration testing and vulnerability assessment services, and for the broader pattern of misconfiguration across UAE Azure deployments, this look at where Azure security in the UAE goes wrong covers ground this post does not.
