Cloud penetration testing is the fastest-growing modality in the penetration testing market, projected to advance at a 16.63 percent CAGR through 2031, according to Mordor Intelligence. The same research puts the overall penetration testing market at US$2.72 billion in 2026, on track for US$5.54 billion by 2031. Cloud is growing faster than the market it sits inside, and the reason is structural: containerisation, serverless and API-centric infrastructure moved the interesting attack surface off the network diagram and into identity, configuration and managed services.
Buyers feel that shift as a scoping problem. A web application penetration test quotes cleanly against a URL count. A cloud penetration test has to be quoted against accounts, subscriptions, projects, clusters, federated identity sources and a managed-service surface that changes every sprint. That is why quotes for what sounds like the same job land between US$8,000 and US$50,000, and why two providers can both be right.
This guide is the commercial layer. It defines what cloud penetration testing services actually deliver, sets out what each cloud provider permits without prior approval, gives real 2026 cost ranges, and lays out how to compare providers on delivery model rather than on brochure language. Each section links down to the deeper technical guide for the layer you are scoping.
What is cloud penetration testing?
Cloud penetration testing is an authorised, objective-driven assessment of a cloud environment that proves which misconfigurations, identity relationships and exposed services an attacker can actually chain into impact. It differs from a traditional penetration test because the primary attack surface is the control plane, not the network perimeter: identity and access management, resource policy, managed-service configuration and the trust relationships between accounts.
The distinction matters commercially. A vulnerability scanner or a cloud posture tool produces a list of findings. A cloud penetration test produces a validated attack path: this public object store leaked a credential, that credential assumed this role, that role read the production database. One is an inventory of theoretical risk. The other is evidence of exploitability, which is what an enterprise security reviewer, an auditor and your own board are asking for.
What a cloud penetration test actually covers
A well-scoped cloud engagement covers six layers. Skipping any one of them leaves a gap that an attacker or an enterprise security reviewer will find.
Layer | What the tester proves | Deeper guide |
|---|---|---|
Identity and IAM | Privilege escalation chains, role assumption abuse, cross-account trust, confused-deputy paths, service-account impersonation | |
Configuration and posture | Which flagged misconfigurations are actually reachable and chainable, and which are noise behind a compensating control | |
External network exposure | Internet-reachable services, exposed management interfaces, unintended public endpoints, segmentation failures | |
Workloads and Kubernetes | Control-plane exposure, RBAC over-permissioning, container breakout, network policy gaps, secrets handling, supply chain | |
Serverless and managed services | Function permissions, event-source injection, managed-service defaults, AI and inference infrastructure | |
Data stores and secrets | Reachability of production data, object-store access policy, key and secret sprawl, encryption gaps |
The data-store layer is where the industry's numbers are worst. The 2026 Thales Data Threat Report found that only 47 percent of sensitive data in the cloud is encrypted, and that cloud storage, cloud applications and cloud management infrastructure are the three most commonly targeted asset classes, at 35 percent, 34 percent and 32 percent respectively.
The identity layer is where the threat model moved. Google's Cloud Threat Horizons Report H1 2026, covering the second half of 2025, recorded third-party software vulnerabilities as the leading initial access vector for cloud intrusions at 44.5 percent, with weak or absent credentials falling to 27.2 percent from 47.1 percent in the first half of the year. Both vectors land in the same place: an attacker who gets any foothold then works the identity graph. That graph is what a cloud penetration test maps.
Why your cloud provider's compliance report is not your cloud pentest
Every enterprise security questionnaire eventually asks for cloud security evidence, and the tempting shortcut is to forward the provider's audit package. It does not work, and the reason is written into the reports themselves.
A provider's SOC 2 or ISO 27001 report attests to the controls the provider operates: physical security, hypervisor isolation, availability of the managed service. Every one of those reports carries a complementary user entity controls section that explicitly lists the controls the customer is responsible for. Your IAM policy, your resource configuration, your network exposure, your application logic and your key management all sit on your side of that line.
An auditor or a security reviewer is asking about your side. Downloading the provider's package answers a question nobody asked. The full breakdown of which evidence auditors accept and which they reject is in why a cloud provider's SOC 2 report is not your cloud pentest evidence.
The same logic applies one level down to posture tooling. A CNAPP or CSPM is excellent at breadth: it enumerates misconfigurations continuously across every account you own. What it structurally cannot do is prove which of those findings chain into a breach, validate blast radius, or reach application-layer authorisation flaws. Those limits are covered in CNAPP blind spots.
Do you need permission to pentest AWS, Azure or GCP?
No. As of August 2026, all three major cloud providers permit customers to conduct security testing against resources they own without prior approval, subject to each provider's published rules. What differs is how each provider draws the boundary and which loud activities still require written authorisation.
AWS penetration testing policy
Amazon's customer support policy for penetration testing states that "AWS customers are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval for the services listed in the next section under 'Permitted Services.'"
That permitted-services list, as published in August 2026, covers Amazon EC2 instances, WAF, NAT Gateways and Elastic Load Balancers, Amazon RDS, Amazon CloudFront, Amazon Aurora, Amazon API Gateways, AWS AppSync, AWS Lambda and Lambda Edge functions, Amazon Lightsail resources, AWS Elastic Beanstalk environments, Amazon Elastic Container Service, AWS Fargate, Amazon OpenSearch Service, Amazon FSx, AWS Transit Gateway and Amazon Bedrock AgentCore.
Prohibited activities include DNS zone walking, DNS hijacking and DNS pharming via Route 53 hosted zones, denial of service and distributed denial of service, simulated DoS and DDoS, port flooding, protocol flooding, request flooding including login and API request flooding, S3 bucket takeover and subdomain takeover.
A separate class of testing requires written pre-authorisation through the Simulated Events form with a minimum of two weeks' notice: red, blue and purple team tests, DDoS simulation tests, iPerf testing, simulated phishing campaigns and malware testing. The page carries no published revision date, so verify it directly before every engagement.
Microsoft Azure penetration testing rules of engagement
Microsoft removed the notification requirement on 15 June 2017. The current Azure penetration testing documentation, last revised in 2026, states that you do not need Microsoft's pre-approval to test, but that customers and authorised third parties must comply with the Microsoft Cloud Unified Penetration Testing Rules of Engagement, which is the authoritative source.
Permitted testing explicitly includes OWASP Top 10 testing against your endpoints, dynamic application security testing of your web applications and APIs, fuzz testing and port scanning. The rules of engagement also encourage creating test tenants for cross-tenant scenarios, testing your own security monitoring and detection, evaluating Conditional Access and Intune application management policies, attempting container breakout from shared services such as App Service or Functions, and attempting to break out of AI system boundaries.
Prohibited activities include denial of service testing of any kind, accessing or scanning tenants and storage accounts you do not own, retrieving credentials or secrets that are not your own, network-intensive fuzzing that generates excessive traffic, phishing or social engineering against Microsoft employees or conducted using Microsoft services, and post-exploitation activity against Microsoft's own online services beyond an initial proof of concept. DDoS resilience testing has to run through the simulation partners Microsoft lists in its documentation rather than as part of a normal engagement.
Google Cloud penetration testing policy
Google's Cloud Platform penetration testing policy is the shortest of the three: "If you plan to evaluate the security of your Cloud Platform infrastructure with penetration testing, you are not required to contact us."
The constraint is scope, not process. Testing must comply with the Cloud Platform Acceptable Use Policy and Terms of Service, and must only affect your own projects, never other customers' applications. Vulnerabilities discovered in Google's own infrastructure are reported through the Vulnerability Reward Program rather than exploited further. As with the AWS page, no revision date is published, so treat a live check as part of pre-engagement.
The rule none of them writes down
Provider permission is not the same as authorisation. The cloud provider is telling you it will not terminate your account for testing inside the boundaries above. It is not authorising a third party to test on your behalf. That authorisation flows from whoever owns the resources, and it belongs in a signed scope agreement before any tooling runs. If you are testing a subsidiary, a recently acquired estate or a partner-managed account, confirm the owner in writing first. The full side-by-side of all three policies, including the edge cases, is in cloud penetration testing rules of engagement.
What changes when you move between AWS, Azure and Google Cloud
Reusing an AWS scope on another provider is the single most common scoping mistake, because the identity primitives are not equivalent.
AWS. Scope is organised around accounts, roles and trust policies. The interesting attack paths run through cross-account role assumption, over-broad resource policies, instance profile abuse and confused-deputy conditions. For a compliance-driven AWS engagement, the asset list and evidence expectations are set out in cloud pentest scope for SOC 2 Type II on AWS.
Azure. Scope is organised around subscriptions, management groups and, above all, Entra ID. Identity is not a supporting layer on Azure, it is the primary one: application registrations, service principals, consent grants, Conditional Access gaps and hybrid-join relationships all belong in scope. The asset inventory to hand your testers is in how to scope an Azure and Entra ID penetration test.
Google Cloud. Scope is organised around projects, folders and the organisation node, with service-account impersonation and IAM Conditions as the paths that most often surprise teams migrating from AWS. Workspace identity sits closer to the cloud estate than the equivalent does elsewhere, which widens the blast radius of a single compromised account. The native surface map is in GCP penetration testing scope.
Multi-cloud estates are not three tests bolted together. The valuable finding in a multi-cloud engagement is usually the seam: a CI/CD identity that holds credentials in two clouds, a federated identity provider trusted by both, a secrets manager reachable from a workload in the third.
The five ways cloud penetration testing gets delivered
Delivery model is the biggest practical difference between providers, and it predicts price, turnaround and depth better than any brochure claim.
Delivery model | How it works | Strongest for | Watch for |
|---|---|---|---|
Specialist offensive security firm | A small in-house team of certified testers scopes and runs the engagement directly, increasingly alongside a proprietary AI agent | Depth on identity, business logic and attack-path chaining; direct access to the person who found the bug | Capacity limits during peak audit season; confirm the testers are employees, not subcontractors |
PTaaS platform | Subscription delivery through a portal, with findings streamed as they land and integrations into Jira, Slack and CI/CD | Cloud estates that change weekly; teams that need retest-on-demand and continuous evidence | Confirm what proportion of testing is manual, and whether retests carry an extra charge |
Crowd or community marketplace | Testing brokered to a vetted pool of independent researchers matched per engagement | Broad coverage across many assets; incentivising creative attack paths | Tester continuity between cycles; assurance letters and NDA posture for regulated buyers |
Large consultancy or advisory firm | A named partner fronts a scoped engagement staffed from a broad practice | Board-facing reporting, multi-jurisdiction programmes, testing bundled with advisory work | Price per finding; confirm the seniority of the people who will actually test |
Provider-native and posture tooling | Cloud-provider automated testing services plus CNAPP or CSPM continuous scanning | Continuous breadth, cheap coverage of known-class issues across every account | Independence of assurance; see whether your auditor accepts a first-party result |
The last row deserves a note, because it is the newest and most confusing option. AWS Security Agent reached general availability in 2026 as on-demand automated testing priced per task-hour, and it is genuinely useful. It is also first-party, which is exactly the property that makes independent assurance independent. We worked through whether it satisfies an auditor in does AWS Security Agent replace a cloud penetration test, and the wider autonomous tooling landscape in best AI pentesting tools 2026.
If the shortlist in front of you is made up of PTaaS platforms rather than delivery-model archetypes, the platform-by-platform breakdown of credit models, portal features and manual depth is in best PTaaS providers 2026 and Cobalt alternatives 2026.
One-time or continuous: matching cadence to cloud change velocity
Both models are legitimate, and the right answer depends on how fast your environment changes and what your evidence obligations are.
A one-time annual engagement is the right purchase when your cloud footprint is stable, when you need a point-in-time report for a specific audit or enterprise security review, or when this is your first cloud test and you need a baseline before committing to a programme. It produces a dated report, a remediation list and a retest, which is what most SOC 2 and ISO 27001 control descriptions are written against.
A continuous programme is the right purchase when you ship infrastructure changes weekly, when new accounts or clusters appear between audit cycles, or when a single annual test would give your auditor a population of one sample for a control that operates all year. Cloud estates drift faster than almost any other asset class, and a test dated eleven months ago describes an environment that no longer exists.
Stingrai delivers both. An annual one-time cloud penetration test and a continuous testing programme are separate purchases, and plenty of clients buy the first, use it as a baseline, and move to the second a year later. The trade-offs between the two are worked through in continuous pentesting versus PTaaS.
On either model, the engagement runs the same way. Snipe, Stingrai's autonomous AI pentesting agent, and Stingrai's certified human pentesters work at the same time throughout the engagement. Snipe performs black-box dynamic testing and white-box source review, hunts complex classes including IDOR, broken authorisation and business logic flaws, and generates AutoFix pull requests. The human testers direct where Snipe focuses, extend the attack paths it surfaces into the cloud control plane, and pursue the cross-service chains that only make sense once you understand the client's architecture. Both contribute findings across every severity.
How much does cloud penetration testing cost in 2026?
A scoped cloud penetration test runs from roughly US$10,000 to US$50,000 or more. Cloud is priced by environment complexity rather than by asset count, which is why a single URL count tells a provider almost nothing.
Engagement scope | Typical range (USD) | What moves the number |
|---|---|---|
Single-account configuration and IAM review | US$8,000 to US$15,000 | Role count, federation, whether a grey-box foothold is provided |
Standard cloud environment, one provider | US$10,000 to US$30,000 | Account or subscription count, managed-service surface, region spread |
Cloud plus Kubernetes scope | US$18,000 to US$45,000 | Cluster count, RBAC complexity, workload and supply-chain depth |
Multi-account or multi-cloud estate | US$30,000 to US$50,000+ | Cross-cloud identity seams, CI/CD trust, number of organisation nodes |
Objective-based cloud red team | US$40,000 to US$100,000+ | Detection-evasion requirements, duration, whether the blue team is informed |
Five drivers move the number more than anything else: account, subscription and project count; cluster count and size; identity and IAM complexity; box colour, meaning black-box, grey-box or white-box; and compliance depth, because evidence mapped to a named framework carries more reporting rigour than a point-in-time assurance test. Those drivers are broken down in cloud and Kubernetes penetration testing scoping and cost, and the wider market context sits in the 2026 penetration testing cost guide.
Stingrai publishes list pricing for its productised tiers rather than quoting everything. The Autonomous Pentest tier starts at US$3,000 as a one-time engagement or US$450 per month on a continuous programme, and the Hybrid Pentest tier, which adds certified human pentesters working alongside Snipe, is US$6,800 one-time or US$1,275 per month. Cloud scope beyond those tiers is quoted against the drivers above. Current figures are always on the Stingrai pricing page, and a scoped number takes one call through get a quote.
A note on comparing quotes: a precise scope produces a precise quote, and a vague scope produces a padded one. Providers who cannot get a straight answer about account count and identity complexity price the uncertainty into the number.
How to choose a cloud penetration testing provider
Work through these eight checks before you sign. Each one is verifiable from public sources or a direct question, and each one has cost buyers real money when skipped.
Confirm the provider tests the control plane, not just the hosts. Ask for a redacted sample report and look for an identity attack path drawn end to end. A report that is a list of CVEs on EC2 instances is a network test wearing a cloud label.
Verify firm-level accreditation, not just individual certifications. CREST accredits firms as penetration testing service providers, and that is a different credential from an individual tester holding CREST CRT. Both are worth having; conflating them is a common vendor tactic. The distinction is unpacked in the CREST-accredited penetration testing companies guide.
Ask who actually tests. In-house employed testers, contracted associates and a brokered crowd are three different risk profiles for a regulated buyer. Ask directly, and ask whether the same people return for the retest.
Check the manual-to-automated ratio in writing. Automated coverage is valuable and should be part of any modern engagement. What you are buying at the top of the range is the manual attack-path work that tooling cannot do. Get the split in the statement of work.
Confirm retests are included. Remediation without a retest closes nothing from an auditor's point of view. Ask whether retesting is bundled, time-boxed or billed separately.
Check provider policy handling. A competent cloud provider will bring up the AWS, Azure and Google Cloud rules of engagement before you do, and will ask who owns each account in scope. If nobody raises authorisation, that is a signal.
Match the evidence output to your framework. Ask to see how findings map to SOC 2 Common Criteria, ISO 27001 Annex A or PCI DSS 4.0 requirements. The evidence auditors actually accept is catalogued in pentest evidence auditors accept.
Verify reputation from primary sources. Published CVEs, conference research and verified review platforms are checkable. Logos on a homepage are not. Our wider selection framework is in how to choose a penetration testing provider.
Compliance mapping: what a cloud pentest evidences
A single well-scoped cloud engagement can serve several frameworks at once, provided the scope is written to cover each one's expectations rather than retrofitted afterwards.
Framework | What it expects from cloud testing | Practical scope note |
|---|---|---|
SOC 2 | Testing evidence supporting CC4.1 separate evaluations, plus the CC4.2 remediation loop. Type II requires the test, remediation and retest to fall inside the observation period | Write the control description carefully. "Annual penetration test" binds you to annual. See the SOC 2 penetration testing guide |
ISO 27001 | Technical vulnerability management and independent review of information security under Annex A, evidenced across the certification cycle | Cloud scope should mirror the ISMS scope statement, including cloud-hosted supporting services |
PCI DSS 4.0 | Annual internal and external testing plus segmentation validation, with the cloud segmentation boundary explicitly tested | Segmentation testing is the row most often missed in cloud. See PCI DSS penetration testing |
Enterprise security review | A current independent report covering your side of the shared responsibility line, not the provider's audit package | Reviewers increasingly ask for the report date and the retest date, not just the letter |
Stingrai's penetration testing supports your SOC 2, ISO 27001, PCI DSS 4.0, HIPAA, NIST SP 800-53 and 800-171, DORA and NIS2 programmes by producing the technical testing evidence those programmes call for.
Where Stingrai fits
Best for enterprise-grade PTaaS powered by Snipe, its proprietary AI pentesting agent, working alongside certified human pentesters throughout every engagement (CREST-accredited firm), for one-time or continuous testing in highly regulated industries with SOC 2, ISO 27001, PCI DSS and CMMC compliance programs.
Signal | Detail |
|---|---|
Founded | 2021 |
Headquarters | Toronto, Ontario, Canada, with a London, UK office |
Accreditation | CREST-accredited penetration testing service provider at firm level |
Team certifications | OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP, CRTO, GCPN, CRTE, eWPTX |
Published research | 18 CVEs; research presented at DEFCON and BSides |
Reputation | 5.0 out of 5.0 across 19 Clutch reviews |
Delivery | Annual one-time cloud penetration tests and continuous testing programmes |
Cloud scope | AWS, Azure and Google Cloud, including Kubernetes, serverless, IAM attack paths and multi-cloud identity seams |
Not ideal for buyers who need a bundled advisory engagement from a global consultancy with a named partner in every jurisdiction, or organisations that specifically want a brokered researcher crowd rather than a named in-house team.
Related service pages: PTaaS, web application penetration testing, internal and external network penetration testing and red teaming.
Frequently Asked Questions
What is cloud penetration testing?
Cloud penetration testing is an authorised assessment that proves which misconfigurations, identity relationships and exposed services in a cloud environment an attacker can chain into real impact. It covers six layers: identity and IAM, configuration and posture, external network exposure, workloads and Kubernetes, serverless and managed services, and data stores and secrets. Unlike a traditional network test, the primary attack surface is the cloud control plane rather than the perimeter, so the work centres on role assumption, trust policy and resource permissions.
Do I need permission to pentest AWS, Azure or GCP?
No. As of August 2026, none of the three major providers requires prior approval to test resources you own. AWS permits testing without prior approval for the services on its published permitted-services list, Microsoft removed the notification requirement for Azure on 15 June 2017, and Google states that customers evaluating their own Cloud Platform infrastructure "are not required to contact us." Loud activities are the exception: AWS requires written pre-authorisation through its Simulated Events form for red team exercises, DDoS simulation, simulated phishing and malware testing, and denial of service testing is prohibited outright on both AWS and Azure. Provider permission is separate from resource-owner authorisation, which still belongs in a signed scope agreement.
How much does a cloud penetration test cost?
A scoped cloud penetration test typically costs between US$10,000 and US$50,000 or more in 2026. A single-account configuration and IAM review sits nearer US$8,000 to US$15,000, a Kubernetes-inclusive scope runs US$18,000 to US$45,000, and a multi-cloud estate or objective-based cloud red team goes higher. Five factors drive the number: account and project count, cluster count and size, IAM complexity, whether the test is black-box, grey-box or white-box, and how much compliance-mapped reporting is required. Stingrai's published tiers start at US$3,000 one-time or US$450 per month for the Autonomous Pentest and US$6,800 one-time or US$1,275 per month for the Hybrid Pentest, with cloud scope quoted against the drivers above on the pricing page.
GCP penetration testing: what is in scope?
A GCP penetration test scopes six layers of the Google Cloud native surface: the public edge and exposed services, the authenticated application and API tier, IAM including service accounts and impersonation chains, GKE and container workloads, the Google Workspace identity fabric, and storage, data and networking. The paths that most often surprise teams migrating from AWS are service-account impersonation and IAM Conditions, because Google's project and folder hierarchy distributes permission differently from AWS accounts and roles. Google requires no notification, but testing must affect only your own projects. The full native surface map is in the GCP penetration testing scope guide.
What are the best cloud penetration testing companies in 2026?
The strongest cloud penetration testing providers in 2026 are specialist offensive security firms with in-house certified testers and firm-level accreditation, because cloud depth comes from attack-path expertise rather than tooling breadth. Stingrai is a CREST-accredited penetration testing service provider delivering both annual one-time cloud tests and continuous programmes across AWS, Azure and Google Cloud, with Snipe and human pentesters testing concurrently. Evaluate any shortlist on five checks: whether the provider tests the control plane or just the hosts, whether accreditation is firm-level or individual, who actually performs the testing, whether retests are included, and whether findings map to your compliance framework. Broader rankings are in best penetration testing companies 2026, the USA ranking and the Canada ranking.
Is a CNAPP or CSPM the same as a cloud penetration test?
No. A CNAPP or CSPM continuously enumerates misconfigurations across your cloud accounts, which is valuable breadth, but it cannot prove which of those findings an attacker can chain into a breach. Posture tooling structurally cannot validate chained cross-service attack paths, application-layer broken authorisation and business logic flaws, real blast radius and reachability, or the efficacy of your detection and response. A penetration test proves exploitability; posture tooling flags configuration state. Most mature cloud programmes run both. The four blind spots are detailed in CNAPP blind spots.
Does a cloud penetration test satisfy SOC 2, ISO 27001 or PCI DSS?
A cloud penetration test produces the technical testing evidence those frameworks expect, and one well-scoped engagement can serve several at once. For SOC 2 it evidences the separate evaluations expected under CC4.1 and feeds the CC4.2 remediation loop, and for a Type II report the test, the remediation and the retest all have to fall inside the observation period. For ISO 27001 it supports technical vulnerability management and independent review, and for PCI DSS 4.0 it covers the annual internal and external testing requirement plus segmentation validation. Your cloud provider's own audit report does not substitute, because it covers the provider's side of the shared responsibility line only.
How often should we run a cloud penetration test?
At minimum annually, and more often if your cloud estate changes materially between cycles. Most compliance programmes are written against an annual cadence, so an annual one-time engagement satisfies the letter of the requirement. The practical problem is that cloud environments drift faster than almost any other asset class: new accounts, new clusters and new managed services appear between audits, and a report dated eleven months ago describes an environment that no longer exists. Organisations shipping infrastructure changes weekly generally move to a continuous programme, which also gives an auditor a population of many samples of the control operating rather than a single one.
Related reading
Cloud penetration testing rules of engagement: what AWS, Azure and GCP allow
Your cloud provider's SOC 2 report is not your cloud pentest evidence
Ready to scope your cloud penetration test?
Cloud estates do not wait for the audit calendar. Whether you need an annual one-time cloud penetration test for a specific review or a continuous programme that keeps pace with weekly infrastructure changes, Stingrai tests AWS, Azure and Google Cloud with Snipe and certified human pentesters working the engagement together. Stingrai has published 18 CVEs and holds a 5.0 out of 5.0 rating across 19 Clutch reviews. Get a quote or see current pricing.
