Most organisations that have pentested their web application have not pentested their cloud environment. The two share an attack surface at the edges, where server-side request forgery vulnerabilities can reach cloud metadata services, and where exposed storage buckets sit behind an application's API. But cloud infrastructure has vulnerabilities that a web application penetration test scope does not touch: IAM privilege escalation, metadata service credential theft, inter-service trust abuse, storage bucket exposure across all authenticated accounts, and lateral movement across cloud-native services. If your production workload runs on AWS, Azure, or GCP, a web application test has not tested it.
The second distinction is between a cloud security posture management tool and a penetration test. Running a CSPM tool such as Wiz, Prisma Cloud, or Orca against your cloud account and generating a findings report is not a penetration test. Those tools find known misconfiguration patterns at scale. They do not test exploitability, do not chain findings into realistic attack paths, and do not find the organisation-specific privilege escalation paths that exist in the combination of IAM policies your environment has accumulated.
For AU financial services organisations and regulated entities, CSPM output does not satisfy the penetration testing evidence requirement under APRA CPS 234 or the testing expectations at Essential Eight Maturity Level 2 and above.
What the Shared Responsibility Model Means for Scope
With on-premises systems the organisation owns the whole stack. In the cloud, the customer is responsible for securing its configuration, identities, and data, while the provider secures the underlying platform. That division determines what a cloud penetration test can and should scope.
The shared responsibility model draws the line: you may test your configuration and your workloads, never the provider's control plane or another tenant. A traditional network test aimed at cloud IP addresses will miss identity, storage permissions, secrets handling, and metadata-service abuse, which are the cloud-specific risks.
This is the failure mode that wastes the most money in AU cloud testing engagements: commissioning a traditional external network test against cloud IP addresses. That test enumerates open ports and checks for unpatched services. It does not examine the IAM configuration that represents the real attack surface in cloud environments. The attack surface in cloud is configuration and identity, not open ports.
AWS: Where the Highest-Impact Findings Live
In AWS, IAM and privilege escalation is the highest-impact finding category. Testing evaluates whether any IAM role, user, or service account can be used to escalate to administrator-level access through permission combinations, trust relationships, or policy misconfigurations. Common paths include iam:PassRole abuse, sts:AssumeRole without sufficient conditions, Lambda execution roles with excessive permissions, and EC2 instance profiles granting broader access than the instance needs.
S3 bucket misconfigurations represent a separate high-impact category: public read or write access, missing encryption, overly broad bucket policies. EC2 metadata service exploitation chains SSRF vulnerabilities with IMDSv1 to steal instance credentials. Enforcing IMDSv2 across EC2 instances is a specific remediation that closes the metadata service attack path. A penetration test confirms whether IMDSv2 enforcement is consistent across the environment, not just configured on newly launched instances.
AWS allows customer-initiated testing without prior approval for most services, restricting DNS zone walking, port flooding, and request flooding. Documented authorisation from the account owner is required, not from AWS.
Azure: Identity Is the Attack Surface
Azure penetration testing must account for the close relationship between Azure resources and Microsoft identity services. Important areas include Microsoft Entra ID, subscriptions, resource groups, RBAC assignments, managed identities, service principals, Azure Storage, Key Vault, App Services, Azure Functions, AKS, and Microsoft Defender for Cloud.
In Azure, the primary target is Entra ID and misconfigured resource groups. Attackers target privilege escalation by exploiting user accounts with elevated roles like Global Administrator. Managed identities assigned broader permissions than their workload requires, application registrations with excessive API permissions, and conditional access policies with geography-based bypass conditions are the categories where the highest-severity findings consistently appear.
Azure has a customer penetration testing notification process. AU testers conducting Azure assessments should complete this notification before engagement. The process does not restrict what can be tested within the customer's tenant.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
GCP: Service Accounts and Project Hierarchy
GCP penetration testing should reflect Google Cloud's resource hierarchy and service account model. Common areas include organisations, folders, projects, IAM roles, service accounts, Cloud Storage buckets, Compute Engine instances, Cloud Functions, Cloud Run, GKE clusters, Cloud SQL, organisation policies, and audit logging. Overly broad IAM roles, exposed service account keys, or weak separation between projects can create paths for privilege escalation or unauthorised access to cloud resources.
GCP allows penetration testing of customer-owned resources without prior approval. Testing GKE clusters for RBAC misconfigurations, pod security policy gaps, and container escape paths is a specific GCP workload that requires cloud-native expertise distinct from traditional Kubernetes testing knowledge.
AU Compliance Context: APRA, Essential Eight, and IRAP
APRA CPS 234 requires regulated entities to test information security controls regularly. Cloud penetration testing demonstrates that cloud-hosted controls are effective. Financial services organisations increasingly include cloud testing as a mandatory component of their annual assurance programme, particularly as workloads migrate from on-premises to cloud environments.
For IRAP-assessed environments and government entities using ASD-listed cloud services, the penetration testing scope must align with the authorised usage and the controls documented in the System Security Plan. Cloud penetration testing evidence supports the ISM technical controls section of the assessment documentation.
For how cloud penetration test evidence connects to the broader compliance evidence programme that APRA and ISO 27001 auditors expect, the guide to continuous penetration testing for SOC 2 and ISO 27001 compliance covers how each engagement builds the evidence trail that regulators check.
The remediation and re-testing cycle that converts cloud penetration test findings into confirmed compliance evidence is covered in the guide to what happens after a penetration test. A confirmed IAM remediation requires a re-test confirming the specific privilege escalation path no longer succeeds, not just confirmation that the IAM policy was updated.
Book a scoping consultation to confirm cloud penetration test scope, provider authorisation requirements, and AU compliance framework mapping.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
What is the difference between a CSPM tool and a cloud penetration test in Australia?
A cloud security posture management tool (CSPM) such as Wiz, Prisma Cloud, or Orca scans cloud environments against known misconfiguration patterns and compliance benchmarks at scale. It identifies what appears to be misconfigured, not what is actually exploitable. A cloud penetration test uses manual testing to chain findings into realistic attack paths, test whether IAM privilege escalation paths succeed, and identify organisation-specific vulnerabilities that CSPM tools cannot generate test cases for. CSPM output does not satisfy APRA CPS 234 penetration testing evidence requirements or Essential Eight Maturity Level 2 testing expectations.
Does APRA CPS 234 require cloud penetration testing for Australian financial institutions?
APRA CPS 234 requires regulated entities to test information security controls regularly, calibrated to threat exposure. As financial services workloads migrate to cloud environments, cloud penetration testing is increasingly treated as a mandatory component of the annual assurance programme. APRA supervisors expect that cloud-hosted controls are tested with the same rigour as on-premises controls, meaning a web application test that does not examine the cloud IAM configuration and storage security does not satisfy the cloud control testing expectation.
What does a cloud penetration test cover on AWS?
An AWS cloud penetration test covers: IAM role and policy analysis for privilege escalation paths (iam:PassRole abuse, sts:AssumeRole conditions, EC2 instance profile permissions), S3 bucket configuration (public access, bucket policies, ACLs), EC2 metadata service exploitation (IMDSv1 vs IMDSv2 enforcement), Lambda execution roles, cross-account trust relationships, exposed secrets in environment variables and parameter stores, and network controls including security group rules and VPC configuration. AWS does not require prior approval for most customer-initiated penetration testing but restricts DNS zone walking, port flooding, and request flooding.
What are the penetration testing rules for AWS, Azure, and GCP?
AWS allows customer-initiated testing without prior provider approval for most services, restricting specific attack types (DNS zone walking, port flooding, request flooding). Testers require documented authorisation from the AWS account owner. Azure has a customer penetration testing notification process that AU testers should complete before engaging, but it does not restrict what can be tested within the customer's Azure tenant. GCP allows penetration testing of customer-owned resources without prior approval from Google. All three providers require that testing is limited to resources the customer owns or has explicit written authorisation to test.
How is cloud penetration testing different from a web application penetration test?
A web application penetration test tests what a user of the application can do: authentication, access controls, input handling, API authorisation, and business logic. A cloud penetration test tests what an attacker who has compromised a single service, instance, or credential can do within the cloud environment and how far they can move from that starting position. The attack paths are entirely different. IAM privilege escalation, metadata credential theft, cross-account access abuse, and storage bucket exposure are invisible in a web application test scope and require a separate cloud penetration test engagement.
