Best Cloud Penetration Testing Companies for AWS and SOC 2 (2026)

Cloud penetration testing is the fastest-growing modality in the penetration testing market, advancing at a 16.63 percent compound annual growth rate through 2031, according to Mordor Intelligence, which puts the overall market at US$2.72 billion in 2026 on the way to US$5.54 billion by 2031. The demand is not coming from curiosity. It is coming from audit committees and enterprise procurement teams who have worked out that a cloud provider's own compliance package proves nothing about the account you actually run.

Quick answer: For a mid-market or enterprise SaaS or fintech company on AWS that needs cloud penetration testing evidence for SOC 2 Type II, ISO 27001 and customer security reviews, the strongest 2026 shortlists pair a cloud-specialist provider with named, certified penetration testers, explicit IAM and Kubernetes coverage, a retest included in the fee, and a letter of attestation your auditor and your customers will accept. Stingrai leads this list for North American buyers on that combination; NCC Group, Praetorian, NetSPI and Rhino Security Labs are the strongest alternatives depending on scale, cloud depth and procurement constraints.

What a cloud penetration test covers, and what it is not

Three artefacts get called "cloud security testing" in procurement conversations, and they are not interchangeable. Confusing them is the most common reason an auditor sends a package back.

A cloud security posture management report, produced by a CSPM or CNAPP tool, continuously compares your account configuration against a benchmark such as the CIS AWS Foundations Benchmark and flags drift. It tells you that a security group allows 0.0.0.0/0 on port 22. It cannot tell you whether anything behind that port matters.

A cloud configuration review is a human reading the same configuration with more judgement: a consultant walks your IAM policies, bucket policies, VPC design and logging setup and writes up what looks wrong. Better than the tool, still an opinion about settings rather than a demonstration of consequence.

A cloud penetration test is an authorised, objective-driven engagement in which penetration testers attempt to reach a defined impact. The deliverable is a chain: this build server's instance profile could be reached from the application, that role could assume a second role in the production account, and that second role could read the customer data store. Each link is evidenced, reproducible and rated on the impact it actually enables.

The distinction has a direct audit consequence. A posture report is good evidence that a monitoring control operates, and weak evidence of a separate evaluation, because nothing independent was proven. We covered this in why your cloud provider's compliance report is not your cloud pentest evidence: every cloud provider's own report contains a complementary user entity controls section that hands configuration, identity and data access back to you, and that handed-back layer is exactly what a cloud penetration test evaluates.

The practical answer for most SOC 2 programmes is both. Run CSPM continuously for coverage and drift, and a penetration test periodically, or on a continuous programme cadence, for proof.

What AWS actually permits you to test

Buyers routinely delay engagements waiting for an AWS approval that is not required. AWS publishes a customer support policy for penetration testing that draws three clear boundaries, and the whole policy applies only to resources in your own account.

Permitted with no prior approval. AWS customers may perform security assessments against a named list of services without requesting authorisation. As of the September 2026 policy page, that list covers Amazon EC2 instances, WAF, NAT gateways and Elastic Load Balancers; RDS; CloudFront; Aurora; API Gateway; AWS AppSync; Lambda and Lambda@Edge; Lightsail; Elastic Beanstalk; Elastic Container Service; Fargate; OpenSearch Service; FSx; Transit Gateway; Bedrock AgentCore; and Global Accelerator. For a typical SaaS architecture, that covers essentially the entire application and data tier.

Permitted only after submitting the Simulated Events form. AWS requires advance authorisation through its Simulated Events process for red, blue and purple team engagements involving covert adversarial simulation or command and control infrastructure hosted on AWS, simulated phishing campaigns, malware testing, iPerf testing, and other simulated events. If your plan includes an objective-based red team on top of the cloud penetration test, this form is a scheduling dependency. Build it into the timeline, not the week before.

Prohibited outright. The AWS policy names these as forbidden: DNS zone walking via Amazon Route 53 hosted zones, DNS hijacking via Route 53, DNS pharming via Route 53, denial of service and distributed denial of service, simulated DoS and simulated DDoS, port flooding, protocol flooding, request flooding including login and API request flooding, S3 bucket takeover, and subdomain takeover. Note that "simulated DoS" is prohibited: availability testing is not a gap in your provider's methodology, it is a boundary AWS sets. Customers who need it route through the separate AWS DDoS Simulation Testing policy and the EC2 stress test policy, which are distinct processes.

Two procurement implications follow. A provider who says they must file paperwork with AWS before a standard application and infrastructure test is either padding the timeline or does not test AWS often. And a provider who offers to "load test your login endpoint to prove rate limiting" is proposing something AWS prohibits; rate limiting is verified by logic and observation, not by flooding.

Azure and Google Cloud are looser still. Microsoft has not required notification for testing customer-owned Azure resources since 2017, and Google does not require customers to contact it before testing their own projects. Our cloud penetration testing services guide covers the multi-cloud picture.

How to scope an AWS penetration test for a SOC 2 Type II

SOC 2 never literally requires a penetration test. The AICPA Trust Services Criteria do not contain the phrase as a named control. Auditors read CC4.1, the monitoring and separate evaluations criterion, as the natural home for one. In practice a penetration test is expected, and a weak one gets challenged.

Five decisions determine whether the test you buy is the test your auditor accepts. The full treatment is in our cloud pentest scope guide for SOC 2 Type II on AWS; here is the procurement-level version.

1. Match the test boundary to the system description boundary. If your SOC 2 system description includes the production AWS accounts, the multi-tenant application and the identity provider, a test scoped only to the public web application leaves a visible gap. Write the account IDs, application domains, API surface and identity sources into the statement of work.

2. Test the identity plane, not just the perimeter. On AWS the interesting compromise is almost never a remote code execution on an internet-facing host. It is a credential in a build artefact, an over-permissive instance profile, a role trust policy with a wildcard principal, or a PassRole combination that lets a low-privilege identity hand a high-privilege role to a service it controls. Ask directly whether the methodology includes IAM privilege escalation path analysis and cross-account trust abuse. If the answer is vague, the test will be a network scan with a cloud label.

3. Prove tenant isolation. For a multi-tenant SaaS, the question every enterprise security reviewer asks is whether one customer can reach another customer's data. That is an authorisation question at the application layer and a segmentation question at the infrastructure layer. Both belong in scope.

4. Run the test inside the observation window. A Type II report tests operating effectiveness across a period, commonly three to twelve months. A test completed two weeks before the window opened is a Type I artefact wearing a Type II jacket. Schedule inside the window, with enough runway to remediate and retest before the window closes.

5. Specify the deliverables in the contract. At minimum: a scoped technical report with reproduction steps and severity ratings tied to a published scale, remediation tracking, a retest of every high and critical finding, and a letter of attestation naming scope, dates, methodology and remediation status. That letter is what you hand to auditors and to enterprise customers who will not receive the full technical report. If a provider charges extra for the retest, price it in from the start.

Cloud penetration testing companies at a glance (2026)

Every column was checked against each provider's own website in September 2026. "Contract-dependent" means the provider does not publish a standing retest commitment, so it is a negotiation point rather than a default, and you should get it in writing.

How this list was ranked

Nine criteria, weighted for one buyer: a mid-market or enterprise SaaS or fintech security, platform or compliance lead in the US or Canada, running primarily on AWS, who needs evidence that survives a SOC 2 Type II audit and an enterprise customer security review.

• Cloud depth. Does the provider productise cloud penetration testing, or bolt a configuration review onto a network test?

• Identity coverage. IAM privilege escalation, role assumption and cross-account trust named in the methodology.

• Container and Kubernetes coverage. RBAC abuse, control plane exposure, container breakout.

• Evidence quality. Report structure, severity scale, reproduction detail, letter of attestation.

• Retest. Included in the fee, or a change order.

• Tester transparency. Named and certified people, or an anonymous pool.

• North American delivery. Time zones, data residency and contracting entity.

• Cadence flexibility. Both one-time annual engagements and continuous programmes.

• Price transparency. Published figures, or a discovery call before a number exists.

Providers were excluded when their primary product is an adjacent category rather than cloud penetration testing: external attack surface management, vulnerability management, automated scanning and bug bounty platforms were filtered out.

1. Stingrai

Best for: North American SaaS and fintech companies that need human-led, CREST-accredited cloud penetration testing evidence for SOC 2 Type II and ISO 27001, on either an annual or a continuous cadence.

Stingrai is a Canadian offensive security company founded in 2021, headquartered in Toronto with a London office. It holds a firm-level CREST accreditation as a Penetration Testing service provider, its team carries OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP, CRTO, GCPN, CRTE and eWPTX certifications, its penetration testers have published 18 CVEs and present research at DEF CON and BSides, and it holds 5.0 out of 5.0 across 19 Clutch reviews.

Cloud coverage. Human-led penetration testing of AWS, Azure and GCP, covering the external perimeter, the authenticated application and API, IAM and identity attack paths including privilege escalation and cross-account trust abuse, segmentation between environments, Kubernetes and container workloads, serverless and managed services, and data stores and secrets. The testers work the control plane directly rather than reading a posture report back to you.

Where Snipe fits, precisely. Snipe is Stingrai's autonomous AI agent for web application penetration testing. It hunts the complex classes generic AI tools miss, including IDOR, business logic flaws and broken authorisation, performs both black-box dynamic testing and white-box source review, generates AutoFix pull requests, and can gate pull requests before vulnerable code merges. Snipe covers web applications and their APIs; it does not test cloud infrastructure. On a cloud engagement the infrastructure and identity work is done by senior penetration testers, and Snipe covers the applications running on top when they are in scope. The testers and Snipe work the engagement at the same time, with the testers directing where Snipe focuses and extending the attack paths it surfaces.

Cadence. Both models are first-class: a one-time annual cloud penetration test for a single audit cycle, or a continuous programme that tests across the whole SOC 2 Type II observation window. Buyers regularly start annual and move to continuous as their release cadence tightens.

Evidence. Human-validated technical report, remediation tracking through a PTaaS portal with Jira and Slack integration, retest included, and a letter of attestation naming scope, dates, methodology and remediation status. Stingrai's penetration testing supports SOC 2, ISO 27001, HIPAA, PCI DSS 4.0, NIST SP 800-53 and 800-171, DORA and NIS2 programmes.

Pricing. Published on stingrai.io/pricing, which is unusual in this category. Autonomous Pentest is US$3,000 per assessment for one web application and its APIs and Hybrid Pentest with certified penetration testers is US$6,800 for the same scope, both one-time or continuous. Enterprise, which is where full cloud, network, social engineering and physical scope lives, is quoted per environment.

Trade-offs, honestly. Stingrai is a specialist firm, not a global consultancy. If procurement requires offices on four continents, a Big Four relationship or an existing FedRAMP 3PAO engagement, a larger provider on this list fits better. The published per-assessment prices cover one web application and its APIs; a multi-account AWS environment is scoped and quoted, not list-priced.

2. NCC Group

Best for: Large enterprises that need a single global consultancy across cloud, hardware, cryptography and application security, with UK and North American delivery under one contract.

NCC Group is a publicly listed cyber security consultancy with substantial US and Canadian delivery capacity. Its cloud security assessment work spans AWS, Azure and GCP across IaaS, PaaS and SaaS, container and orchestration platforms including Docker and Kubernetes, and serverless environments, combining automated configuration assessment against cloud provider benchmarks with manual exploitation. It is a CREST member and a UK NCSC CHECK provider, and it publishes well-regarded public research.

Trade-offs. Consultancy scheduling, not on-demand. Retest terms and attestation letter format vary by statement of work, so negotiate both explicitly. No published pricing, and a slower sales motion than a specialist firm's.

3. Praetorian

Best for: Engineering-led organisations that want objective-based cloud testing continuously tied to an attack surface platform.

Praetorian, headquartered in Austin, runs cloud penetration testing across network, infrastructure and web application paths, with cloud service provider configuration analysis and Kubernetes cluster configuration analysis available as components, and an explicit focus on access chaining in cloud environments. Engagements are underpinned by its Chariot platform, and it publishes open-source multi-cloud security tooling.

Trade-offs. Chariot is central to the offering, so decide whether you want the tool relationship alongside the testing relationship. Kubernetes and CSP configuration analysis are optional components rather than defaults, so confirm they are in your statement of work. No published pricing and no standing retest commitment.

4. NetSPI

Best for: Enterprises that want cloud penetration testing delivered through a mature platform with a continuous option and strong programme management.

NetSPI tests AWS, Azure and GCP with platform-specialist testers, covering IAM policies, cloud misconfigurations, excessive permissions and exposed services, from both anonymous and authenticated perspectives. Work is delivered through the NetSPI Platform, which supports real-time collaboration with the testers and visibility into cloud exposures, and there is a continuous cloud penetration testing option that surfaces issues as they emerge rather than on an annual cycle.

Trade-offs. Enterprise pricing with no published figures, and the platform's value depends on whether your team will actually work inside it. Mid-market buyers sometimes find the programme overhead heavier than the scope requires.

5. Rhino Security Labs

Best for: Buyers who want a boutique firm with genuine, demonstrable AWS research depth.

Rhino Security Labs is a Seattle-based consultancy offering dedicated AWS, Azure and GCP penetration testing. Its credibility here is not marketing: it maintains CloudGoat, the widely used deliberately vulnerable AWS environment that cloud penetration testers train on, with scenarios covering AWS Glue privilege escalation, detection evasion and vulnerable Lambda functions. It also publishes original vulnerability research.

Trade-offs. Small team, so availability is the constraint and lead times can be long in Q4 audit season. Kubernetes work is best confirmed in scoping rather than assumed. No published pricing.

6. Coalfire

Best for: Organisations whose cloud programme is entangled with FedRAMP or US federal requirements.

Coalfire runs large multi-cloud offensive security programmes and is deeply established in the US federal and FedRAMP ecosystem, which matters if you sell to government or to prime contractors. For a commercial SaaS running a SOC 2 Type II on AWS, that federal weight is a reason to pick them only when federal requirements are genuinely present.

Trade-offs. Coalfire operates advisory and assessment lines alongside penetration testing, so independence between the party testing your controls and the party advising on them needs deliberate management. Programme pricing, no published figures, and a heavier engagement structure than a mid-market scope usually warrants.

7. Synack

Best for: Enterprises comfortable with a vetted researcher marketplace and a platform-managed workflow.

Synack delivers testing through a vetted researcher network coordinated by its platform, with continuous coverage, a managed triage layer and structured reporting suitable for compliance evidence. For organisations that want breadth of perspective across many researchers rather than a fixed named team, the model works well.

Trade-offs. You do not get a named, fixed team on your production cloud environment, which is a real objection for regulated buyers. Cloud infrastructure depth, particularly IAM chaining and Kubernetes, is less consistently evidenced than at the consultancy-led firms above. Enterprise pricing only.

8. Cobalt

Best for: Mid-market teams that want fast scheduling and a familiar PTaaS workflow.

Cobalt runs a marketplace with a community of several hundred vetted penetration testers, tests AWS, Azure and GCP, begins engagements with an automated review against standards such as the CIS Benchmarks before manual work, and can start a test within roughly a day of scoping. It publishes pricing, which is rare, and its platform workflow, retest flow and attestation letter are well established.

Trade-offs. The methodology leans toward configuration review plus application testing rather than deep control-plane exploitation, so for a complex multi-account estate with heavy IAM federation, confirm the depth you are buying. Tester assignment is pool-based rather than a named team.

9. Bishop Fox

Best for: Organisations that want a research-driven offensive security firm with a continuous attack surface platform alongside project work.

Bishop Fox is a well-known offensive security consultancy with multi-cloud penetration testing, strong public research output and the Cosmos platform for continuous attack surface testing.

Trade-offs. Premium positioning and premium pricing, with no published figures. Retest terms and attestation letter format are statement-of-work items rather than defaults. The continuous platform and the project consultancy are separate commercial motions, so be clear which you are buying.

10. TrustedSec

Best for: Buyers who want senior consultant-led testing with a strong assumed-breach perspective.

TrustedSec names Azure and AWS on its cloud testing page and works from an assumed access model, which reveals what an attacker reaches after compromising a user credential, an application or the underlying application stack. TrustedSec reports more than 7,400 custom security engagements completed and maintains widely used open-source security tooling.

Trade-offs. Google Cloud is not named on the cloud testing page, so confirm GCP coverage if you are multi-cloud. Consultant-led scheduling and no published pricing. The assumed-access framing usually needs pairing with external testing for full SOC 2 coverage.

Procurement due diligence checklist

Run this list in the scoping call, before a statement of work exists. The answers separate a real cloud penetration test from a network test with a cloud label.

Scope and methodology

1. Which AWS accounts, organisational units and regions are in scope, by ID?

2. Does the methodology include IAM privilege escalation path analysis, role assumption abuse and cross-account trust abuse? Ask for a redacted example finding.

3. Is Kubernetes or container testing included, and does it cover RBAC, control plane exposure and container breakout, or only benchmark drift?

4. Is tenant isolation tested, and how is it proven?

5. Is the engagement black box, grey box or assumed breach, and which parts are automated rather than performed by a person?

People

1. Who will test the environment, by name, and what certifications do they hold?

2. Are testers employees, contractors or a marketplace pool, and where are they located?

3. Where will engagement data be stored and processed?

Evidence and audit fit

1. Will we receive a letter of attestation naming scope, dates, methodology and remediation status?

2. Is a retest of high and critical findings included in the fee, and does it expire?

3. What severity scale is used, and is it adjusted to our environment rather than a tool default?

4. Have your reports been accepted by SOC 2 and ISO 27001 auditors, and can you provide a reference?

5. Can you deliver a customer-facing summary suitable for enterprise security reviews?

Commercial and legal

1. What is the contracting entity, and can it contract under US or Canadian law?

2. What is the lead time from signature to test start, and to final report?

3. Does the engagement require an AWS Simulated Events submission, and who files it?

4. What insurance, liability cap and confidentiality terms apply to testing production?

5. What is the total cost including retest and the attestation letter, not just the base fee?

What cloud penetration testing costs in 2026

Cloud engagements price on environment complexity rather than on a URL count, which is why quotes for what sounds like the same job land far apart. The variables that move the number most are the count of AWS accounts, the number of identity sources and federation paths, whether Kubernetes is in scope, and whether the test is authenticated across multiple tenant roles.

These are planning bands, not quotes, and Canadian figures are converted at approximate 2026 rates and cross-checked against published Canadian market ranges. Big Four firms typically price three to five times above these bands for comparable scope. For the underlying day-rate evidence, including 30 published public-sector rate cards, see our penetration testing price index. Stingrai's own published package prices are on the pricing page.

Three budget lines buyers routinely forget: the retest, the attestation letter if it is charged separately, and the internal engineering hours to remediate before the audit window closes. The third is usually the largest and never appears in a vendor quote.

Frequently Asked Questions

Which cloud penetration testing company is best for AWS and SOC 2 in 2026?

For a mid-market or enterprise SaaS or fintech company in the US or Canada running on AWS, Stingrai leads this list on the combination that SOC 2 Type II buyers actually need: human-led testing by named, certified penetration testers under a firm-level CREST accreditation, explicit IAM and Kubernetes coverage, a retest included, a letter of attestation, published pricing, and both annual and continuous cadences. NCC Group is the strongest choice for global enterprises needing one consultancy across many disciplines, Praetorian and NetSPI for platform-integrated continuous programmes, and Rhino Security Labs for boutique AWS research depth.

Does SOC 2 require a cloud penetration test?

Not by name. The AICPA Trust Services Criteria never use the phrase "penetration test" as a required control. Auditors read CC4.1, the monitoring and separate evaluations criterion, as the place a penetration test lands, and in practice most auditors and nearly all enterprise customers expect one. Treat it as expected evidence rather than an optional extra.

Do I need AWS approval before a penetration test?

For most testing, no. AWS permits security assessments against a published list of services in your own account with no prior approval, including EC2, RDS, Aurora, CloudFront, API Gateway, AppSync, Lambda, Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch, FSx, Transit Gateway, Bedrock AgentCore and Global Accelerator. You must submit the Simulated Events form before red, blue or purple team simulations, command and control hosting, simulated phishing, malware testing and iPerf testing. Denial of service, simulated DoS, request flooding, S3 bucket takeover and subdomain takeover are prohibited under the penetration testing policy.

Is a CSPM report enough for a SOC 2 auditor?

It is useful, and not sufficient on its own. A CSPM report shows that a configuration-monitoring control operates. It does not demonstrate an independent evaluation of whether the environment can be compromised, and it rates findings on vendor defaults rather than on reachable impact in your architecture. Most mature programmes run CSPM continuously for coverage and a penetration test periodically for proof.

How much does an AWS penetration test cost?

In 2026, a single-account AWS configuration and identity review commonly runs US$8,000 to US$15,000, a cloud penetration test covering one production account plus the application runs US$15,000 to US$30,000, and a multi-account estate with Kubernetes runs US$30,000 to US$60,000. Canadian equivalents run roughly C$11,000 to C$80,000 across the same tiers. Always confirm whether the retest and the attestation letter are inside the quoted fee.

Should the test be annual or continuous?

Both are legitimate. An annual engagement is sufficient when your AWS architecture and release cadence are stable, and it is the common starting point for a first SOC 2 Type II. A continuous programme fits when you ship weekly, when infrastructure changes constantly, or when you want evidence distributed across the whole Type II observation window rather than concentrated in one month. Stingrai delivers both, and the move from annual to continuous is a contract change rather than a vendor change.

What evidence should I get at the end of the engagement?

A scoped technical report with reproduction steps and severity ratings on a published scale, remediation tracking, a documented retest of every high and critical finding, a letter of attestation naming scope, dates, methodology and remediation status, and a customer-facing summary you can share in enterprise security reviews without releasing the technical detail.

Does a cloud penetration test cover Kubernetes?

Only if you scope it in. Many providers treat Kubernetes as an optional component, or cover it as benchmark drift rather than exploitation. If you run EKS, ask specifically about RBAC over-permissioning, control plane exposure, network policy gaps, secrets handling and container breakout, and confirm each in the statement of work.

Related reading

• Cloud pentest scope for SOC 2 Type II on AWS

• Your cloud provider's compliance report is not your cloud pentest evidence

• Cloud penetration testing services 2026: AWS, Azure and GCP buyer's guide

• SOC 2 penetration testing in 2026

• Best penetration testing companies in the USA 2026

• Top penetration testing companies in Canada 2026, ranked

• Penetration testing price index 2026