CREST-Certified Cloud Penetration Testing for AWS, Azure and GCP
We test the cloud the way attackers approach it: from leaked credentials in CI to over-permissive federation roles that move sideways between accounts and providers. Scoped per estate, fixed quote in 24 hours, manual exploitation by CREST-registered testers.
“Practical and effective remediation advice, aligned with industry best practices.”
– IT Director, International Property Group
CSPM is not enough
Misconfiguration tools tell you what looks wrong. A pen test tells you what is actually exploitable.
Most cloud teams already run a posture-management scanner. It produces thousands of findings. The question that matters is which of those findings an attacker can chain together to read data, escalate privilege, or pivot to a connected provider.
Tells you a thousand things are misconfigured
CSPM and CNAPP tools surface CIS-benchmark deviations, public-resource alerts, and policy drift. Useful as a continuous monitor, but they do not distinguish a finding that is exploitable today from one that is theoretical. They cannot follow an attack chain across services or across clouds.
Tells you the three or four that lead to a breach
We model the real attacker path. Leaked CI token, federation misuse, over-permissive role, public bucket, lateral movement to a connected provider. Findings come with exploited evidence, not theoretical scoring. You receive a hardening plan that is scoped to your estate.
Per-cloud deep tests
Each cloud has its own attack surface. We test all three in depth.
If your estate is single-cloud, jump to the relevant deep page below. If you run two or three providers, the cross-cloud section further down is where most exploitable risk lives.
AWS Penetration Testing
- IAM, IMDS, and SSO federation
- S3, KMS, and Secrets Manager
- EKS, Lambda, API Gateway
- CIS AWS Foundations Benchmark
Azure Penetration Testing
- Entra ID, RBAC, conditional access
- Blob storage, Key Vault, Functions
- AKS and managed identities
- CIS Azure Foundations Benchmark
GCP Penetration Testing
- IAM, service accounts, Workload Identity
- Cloud Storage, Secret Manager, KMS
- GKE, Cloud Run, Cloud Functions
- CIS GCP Foundations Benchmark
How we test
Four phases, applied identically to each cloud in scope.
The cadence matches CREST OVS and our per-cloud pages. In multi-cloud engagements, phases two and three run in parallel across providers, with phase three culminating in the cross-cloud attack chains specific to your estate.
Estate discovery
Read-only enumeration of accounts, subscriptions, projects, identity providers and federation paths. We map what exists before we touch what is exposed.
Benchmark audit
CIS Foundations for each cloud, mapped to your framework targets (Cyber Essentials Plus, ISO 27001, SOC 2). This is the floor, not the ceiling.
Manual exploitation
The work that scanners cannot do. We chain identity, storage, secrets and compute findings into demonstrable attack paths, including cross-cloud federation paths.
Report and hardening
Executive plus technical report, framework mapping, 30 / 60 / 90-day hardening plan, walkthrough call, letter of attestation, free retest of fixed findings.
Top cross-cloud findings
Five attack chains we see in almost every multi-cloud estate we test.
Each one is exploitable today on default settings. Single-provider scanners cannot see them because the trust path crosses a boundary their telemetry does not cover.
Federation that grants more than it should
An Entra ID app registration vends a SAML assertion into AWS via AssumeRoleWithSAML. The trust policy accepts any user from the tenant. Once an attacker has any low-privilege Azure account, they have an AWS foothold.
CI/CD OIDC trust without claim filters
A GitHub Actions workflow assumes an AWS or GCP role via OIDC, but the trust policy does not constrain the sub claim to a specific repo. Any repo in the organisation can assume the role.
Public storage across all three providers
Public S3, public Blob containers, and public Cloud Storage buckets coexisting in the same estate. The same data is duplicated in three places, and a single-provider CSPM scanner often catches only the cloud it is licensed for.
Secrets leaked into CI variables and images
Long-lived AWS access keys or GCP service-account JSON pasted into CI environment variables, then echoed into container images. We extract them and prove read access to production storage.
Cross-cloud audit logging gaps
CloudTrail, Azure Activity Log and Cloud Audit Logs ship to three different sinks with three different retention policies. We demonstrate an attack chain that is fully reconstructable in one provider and almost invisible in another.
Verified credentials
Accreditations that auditors, regulators and insurers accept.
When to commission
The four triggers that actually bring teams to us.
Pre-audit
Cyber Essentials Plus, ISO 27001 surveillance, SOC 2 Type II evidence, or a customer-driven security questionnaire. A pen test produces the independent assurance that an internal scanner cannot.
Pre-launch
A new production workload is about to go live across one or more clouds. We test the new exposed surface and the connections it inherits.
Post-incident
Something happened. The remediation might be solid, but assurance that no adjacent variant remains needs an external test. We replicate the attack path, then probe nearby weaknesses.
Annual cadence
A board, an insurer, or a major customer wants once-a-year independent assurance. We run the same scope each cycle so year-on-year posture changes are measurable.
Pricing
Transparent cloud penetration testing pricing.
All tiers include the same depth of testing. Price varies by estate complexity, which means account or subscription count, service breadth, resource volume, and how many providers are in scope. Multi-cloud engagements typically sit in Growth or Enterprise.
Single cloud, single account or subscription or project, ≤10 services in use, ≤50 resources, basic IAM. Typically 4-5 day engagement.
Single cloud at organisation scale (3-10 accounts, subscriptions or projects) or two clouds with simple federation. 10-20 services, 50-200 resources, EKS, AKS, GKE, or serverless. CI/CD via OIDC. Typically 7-10 day engagement.
Landing zone, full organisation, or two-to-three cloud estate. 10+ accounts or projects, 20+ services, 200+ resources, multi-region, regulated workloads, complex federation. Typically 10-15 day engagement.
Per-cloud deep tests sit in the same tiers. See full pricing →
See a real cloud penetration test report
A redacted sample of the executive, technical, and management report you receive at engagement close. Includes framework mapping, exploit chains with reproduction steps, and the 30 / 60 / 90-day hardening plan.
See a sample reportFAQ
Questions teams ask us before they commission.
What is cloud penetration testing?
Cloud penetration testing is an authorised, time-boxed engagement in which CREST-registered testers attempt to compromise the confidentiality, integrity or availability of a cloud estate. Unlike automated posture scanning, it produces exploited attack chains with reproducible evidence, plus a hardening plan scoped to the estate.
How does multi-cloud differ from single-cloud testing?
Multi-cloud adds the connections between providers, which is where most modern breaches happen. Federation paths, CI/CD with OIDC across clouds, replicated data, and split audit logging. A scanner licensed for one provider cannot see the trust path that crosses into another. We map the cross-cloud attack chains specific to your estate.
How long does a cloud pen test take?
A single-cloud SMB estate is typically 4-5 days. A growth-stage estate or simple two-cloud setup is 7-10 days. A full enterprise landing zone or a three-cloud estate is 10-15 days. The 24-hour scope-to-quote includes a sizing call so you know the duration before you commit.
How much does a cloud pen test cost?
SMB engagements start at £6,000. Growth and mid-market engagements are £10,000 to £18,000. Enterprise and multi-cloud engagements are £18,000 to £28,000. All tiers include free retests, executive and technical reports, a letter of attestation, and a walkthrough call.
How often should we run a cloud pen test?
Annually is the baseline that most audit, insurance and customer-due-diligence drivers expect. We also recommend a test before any significant architectural change, before a new production workload goes live, after an incident, and on entry to a new compliance regime.
Do we need to notify AWS, Azure or Google before testing?
All three providers permit penetration testing of customer-owned resources without prior notification, subject to their published rules of engagement (no denial-of-service testing, no testing of other tenants, certain services excluded). We confirm scope against the latest provider policies as part of the kick-off.
Is CREST registration relevant for cloud pen testing?
CREST registration is the most widely recognised UK assurance that the testers, the methodology and the company have been independently verified. Many UK regulated firms, insurers and government buyers require it. Our cloud testers are CREST-registered and the company is a CREST member.
Will testing impact production workloads?
We separate read-only enumeration from active exploitation and agree the rules of engagement up front. Active testing is scheduled into maintenance windows where appropriate. Storage and database actions are non-destructive by default. Every step is logged and reversible.
Ready to see what is actually exploitable in your cloud?
A CREST-certified cloud security specialist will contact you within one business day with a fixed quote, a date for kick-off, and a one-page scope you can route through procurement.
20+ CREST-certified testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
