Penetration Testing
Cloud Penetration Testing Services
Cloud penetration testing is a manual security test of your AWS, Azure, GCP or Microsoft 365 environment that combines a configuration review with hands-on attacks on identity, storage and exposed services. It covers your side of the shared responsibility model, and as a PCI SSC-approved QSA company we report it as PCI DSS and ISO 27001 evidence.
Prefer to talk? Call +44 161 523 5276
- AWS, Azure, GCP and Microsoft 365
- Configuration review plus hands-on testing
- Aligned to CIS Benchmarks
Trusted by banks, payment providers and global brands
On this page
- Cloud security testing services: what's included
- Cloud security assessment by platform
- Cloud penetration test vs cloud security assessment
- What can you test without your cloud provider's permission?
- Lateral movement between cloud and on-premises
- Containers and Kubernetes (EKS, AKS, GKE)
- How testing maps to the NCSC cloud security principles
- How much does cloud penetration testing cost?
- What should you look for in a cloud penetration testing provider?
- How is a cloud penetration test carried out?
- Why choose Sovereign Secure for cloud penetration testing services?
- Frequently asked questions
Overview
What is cloud penetration testing?
The short answer
Cloud penetration testing is a manual security test of your AWS, Azure, Google Cloud or Microsoft 365 environment. It combines a configuration review against CIS Benchmarks with hands-on attacks on identity, storage and exposed services, covering your side of the shared responsibility model, and the report can serve as PCI DSS and ISO 27001 evidence.
Cloud penetration testing assesses the security of your cloud infrastructure and services. In the cloud, the provider secures the underlying platform and you secure what you build on it. Testing focuses on your side of that shared responsibility model: identity and access, configuration, exposed services and the data you store.
We combine two things. A cloud security assessment compares your environment against provider guidance and CIS Benchmarks to find misconfigurations at scale. Hands-on testing then confirms which of those are genuinely exploitable, following identity attack paths the way an intruder with one stolen key would, and looks for the issues a review alone would miss.
Most UK clients run more than one platform, so our cloud security testing services cover AWS, Azure, Google Cloud and the Microsoft 365 and Entra ID tenant that usually sits alongside them. We check each provider’s current testing rules at scoping and stay within them.
Cloud testing complements API penetration testing and external penetration testing of your internet-facing cloud edge. Where cloud systems are in your cardholder data environment, the report stands as PCI DSS penetration testing evidence, and it supports ISO 27001 penetration testing requirements under Annex A 8.8. New to testing? Our guides to what penetration testing is and the types of penetration testing show where this test fits.
What's included
Cloud security testing services: what's included
A cloud engagement blends configuration review with hands-on testing.
- 01
Identity and access review
Assessment of IAM roles, policies and permissions for excessive privilege and least-privilege enforcement.
- 02
Configuration benchmarking
Your environment compared against provider guidance and CIS Benchmarks to surface misconfigurations at scale.
- 03
Exposed service testing
Internet-facing compute, storage and databases tested for weak protection and exploitable exposure.
- 04
Storage and data checks
Object storage, buckets and databases reviewed for public access, weak permissions and unencrypted data.
- 05
Microsoft 365 and identity tenant review
Review of M365 and Entra ID configuration, conditional access, privileged roles and email security controls.
- 06
Secrets and pipeline checks
Testing for exposed credentials and secrets across cloud-connected code and CI/CD pipelines.
- 07
Manual verification
Findings confirmed by hand, so you act on real risk rather than raw benchmark output.
- 08
Retest
A retest of remediated findings, scoped in your fixed-price proposal, with the report updated to show them closed.
What we test for
Cloud security assessment by platform
Coverage spans the parts of each cloud that fall under your responsibility. For the full scope on a single platform, see AWS penetration testing services, Azure penetration testing and our Microsoft 365 security assessment.
Amazon Web Services (AWS)
Identity, storage and network controls across your Amazon Web Services accounts.
- IAM policies, roles and cross-account trust
- S3 bucket policies and public access settings
- Security groups and exposed EC2, RDS and Lambda endpoints
- Instance metadata exposure (IMDSv1)
- CloudTrail and logging coverage
Microsoft Azure
Subscriptions, resources and the Entra ID tenant behind them.
- Azure RBAC and management group permissions
- Storage account keys and SAS tokens
- Network security groups and public endpoints
- Key Vault access and secrets handling
- Managed identities and service principals
Google Cloud (GCP) penetration testing
Projects, service accounts and exposed services in Google Cloud, tested within Google’s rules for customers testing their own projects.
- IAM bindings and over-broad basic roles
- Service account keys and impersonation paths
- Cloud Storage bucket permissions
- Firewall rules and public Compute Engine instances
- Audit logging coverage
Microsoft 365 and Entra ID tenant
Configuration weaknesses in Microsoft 365 and the Entra ID identity platform.
- Weak conditional access policies
- Excessive privileged and admin roles
- Insecure external sharing settings
- Missing email authentication (SPF, DKIM, DMARC)
- Legacy authentication left enabled
Identity and access management
Excessive permissions and weak identity controls, a leading cause of cloud breaches.
- Wildcard and over-broad policies
- Missing least-privilege enforcement
- Over-privileged service accounts
- Privilege-escalation paths between roles
- Weak or absent multi-factor authentication on privileged accounts
Storage, secrets and pipelines
Data left exposed and credentials leaked across cloud-connected code and delivery pipelines.
- Publicly accessible buckets and blobs
- Unencrypted data at rest
- API keys and secrets in code or history
- Insecure secret handling in CI/CD
- Insecure serverless and container configurations
Cloud penetration test vs cloud security assessment
A cloud security assessment checks how your cloud is configured; a cloud penetration test proves what an attacker could do with it. Each catches things the other misses, which is why we deliver them together.
| Aspect | Cloud security assessment | Cloud penetration test |
|---|---|---|
| Question it answers | Is the environment configured to provider guidance and CIS Benchmarks? | What could an attacker actually reach or change? |
| How it works | A read-only review of settings across accounts, subscriptions or projects | Hands-on attacks with scoped credentials, following identity and network paths |
| Typical findings | Public storage, missing logging, weak MFA policies and over-broad network rules | Privilege escalation between roles, exposed secrets used to move further, exploitable services |
| Strength | Breadth: every resource checked against a benchmark | Depth: real risk confirmed and weaknesses chained together |
| Limit | Cannot show which issues are exploitable or how they combine | Covers the paths tested rather than every setting |
What can you test without your cloud provider's permission?
Your own resources, within each provider’s published rules. AWS allows testing of a published list of services without pre-approval, and Microsoft Azure and Google Cloud do not require notice before you test what you own; all three prohibit denial-of-service testing and any testing of other customers or of the provider’s own infrastructure. Our guide to AWS, Azure and Google Cloud penetration testing rules sets out what each provider permits and prohibits.
Lateral movement between cloud and on-premises
In a hybrid estate, attackers often cross between cloud and on-premises, usually through identity. An Active Directory account that synchronises to Microsoft Entra ID, a VPN or private link into the cloud network, or a management agent that lets cloud administrators run commands on local servers can each turn a foothold on one side into control of the other.
Where both sides are in scope, we follow those paths in both directions: from a compromised laptop or server towards cloud administrator roles, and from a cloud identity or workload back into the internal network. That work combines this service with an internal penetration test, and our Azure penetration testing page covers Entra ID and hybrid identity in more detail.
Containers and Kubernetes (EKS, AKS, GKE)
With managed Kubernetes, the provider runs the control plane and you own everything you deploy and configure on it. Testing looks at who can reach the cluster API and dashboards, role-based access control and service account permissions, pod security settings that allow escape to the node, secrets stored in the cluster, network policies between workloads, and the cloud roles mapped to pods through workload identity features such as IAM roles for service accounts on EKS, Microsoft Entra Workload ID on AKS and Workload Identity Federation on GKE. Container images are checked for known vulnerabilities and embedded secrets.
How testing maps to the NCSC cloud security principles
The NCSC’s 14 cloud security principles describe what a secure cloud service looks like. Some cover the provider’s own operations, which you judge from the provider’s published assurance rather than by testing. The rest depend on how you configure and use the service, and that is where a cloud penetration test produces evidence.
| NCSC principle | What a cloud penetration test checks |
|---|---|
| 1. Data in transit protection | TLS on exposed endpoints, private links and VPNs, and services that still accept unencrypted traffic |
| 2. Asset protection and resilience | Encryption at rest, public snapshots and backups, deletion protection and where data is stored |
| 3. Separation between customers | Your side only: shared resources, cross-account trust and anything exposed to other tenants |
| 4. Governance framework | Provider responsibility; findings are reported in a form your own governance can track |
| 5. Operational security | Logging coverage, patch levels of your workloads and how configuration changes are controlled |
| 6. Personnel security | Provider responsibility; review the provider’s published assurance |
| 7. Secure development | Secrets in code and pipelines, and the security of the CI/CD that deploys to the cloud |
| 8. Supply chain security | Third-party integrations, marketplace images and cross-account access granted to suppliers |
| 9. Secure user management | Admin roles, guest users, external sharing and joiner and leaver handling in the tenant |
| 10. Identity and authentication | MFA on privileged accounts, conditional access, access keys and service principal credentials |
| 11. External interface protection | Internet-facing services, management ports, storage endpoints and APIs |
| 12. Secure service administration | How administrators reach the management plane, from which devices and with what privilege |
| 13. Audit information and alerting for customers | Whether audit logs are enabled and retained, and whether the testing raised alerts |
| 14. Secure use of the service | Overall configuration against provider guidance and CIS Benchmarks |
How much does cloud penetration testing cost?
Cloud penetration testing is priced in tester-days. The published UK prices we reviewed in September 2026 did not include a fixed price for cloud tests, because cloud scopes vary too much from one client to the next. These drivers set the number of days.
| Cost driver | Why it changes the price |
|---|---|
| Accounts, subscriptions or projects | Each one needs its own configuration review and identity mapping |
| Services in use | Compute, storage, databases, serverless and Kubernetes each add test cases |
| Configuration review or attack testing | A benchmark review alone takes fewer days than hands-on testing of identity paths |
| Microsoft 365 and Entra ID | Adding the tenant adds identity, sharing and email security checks |
| Hybrid paths | Testing movement between cloud and on-premises adds internal testing time |
| Compliance reporting | PCI DSS segmentation testing or mapped evidence adds scope |
Our penetration testing cost guide explains how tester-days turn into a price, and the cloud penetration testing quote form collects the accounts, services and platforms we need to scope yours.
What should you look for in a cloud penetration testing provider?
When you compare cloud penetration testing services, look for hands-on testing of identity attack paths rather than a benchmark scan alone, work that stays within each cloud provider’s testing rules, and a report written for the standard you need to satisfy. These checks separate a real cloud penetration test from a relabelled configuration scan.
| What to check | Why it matters | What to ask |
|---|---|---|
| Cloud provider rules | AWS, Azure and Google Cloud each publish what customers may test, and breaking those rules can breach your agreement with the provider | How do you confirm the current rules for our platforms before testing starts? |
| Shared responsibility scope | Testing should cover everything on your side of the model and nothing on the provider’s | Which accounts, subscriptions, projects and services are in scope, and which are excluded? |
| Identity attack paths | The most serious cloud findings usually come from chaining roles, keys and trust relationships, which a benchmark scan does not attempt | Will a tester try to escalate from a low-privilege identity, and from a leaked access key? |
| Manual verification | Raw benchmark output contains false positives and does not show how issues combine | Is every finding confirmed by hand before it goes in the report? |
| Report mapping | Auditors want findings tied to the standard they assess against | Can the report map to PCI DSS 11.4, ISO 27001 Annex A 8.8, CIS Benchmarks or the NCSC cloud security principles? |
| Hybrid and Microsoft 365 coverage | Attackers move between the cloud, the Microsoft 365 tenant and the internal network | Can one engagement cover Entra ID, Microsoft 365 and the routes back on premises? |
A sample report is the quickest check of all: it shows whether you will receive confirmed attack paths or an export of failed benchmark checks. Our guide on how to choose a penetration testing company covers the wider questions to ask.
How it works
How is a cloud penetration test carried out?
- 1
Scoping
We agree the accounts, subscriptions, services and level of access, and confirm the provider’s testing rules, then fix the price. Our checklist on how to prepare for a penetration test covers your side.
- 2
Configuration review
We review your environment against provider and CIS benchmarks to surface misconfigurations across the estate.
- 3
Testing
Hands-on testing of identity, exposed services and data to confirm which issues are exploitable.
- 4
Reporting
An executive summary and technical report with findings, CVSS ratings and prioritised remediation advice.
- 5
Debrief
A walkthrough with your team covering the findings, the risk and the fixes.
- 6
Retest
Once remediated, we retest and reissue the report showing findings closed.
Every test follows the five stages of penetration testing: planning and reconnaissance, scanning, gaining access, maintaining access, and analysis and reporting.
Why Sovereign Secure
Why choose Sovereign Secure for cloud penetration testing services?
Established in 2012, we deliver PCI, ISO and Cyber Essentials work for banks, payment processors, card manufacturers and fast-growing companies.
Read client testimonials →- Configuration review and hands-on testing combined, so you get scale and confirmed risk.
- Coverage of the platforms most UK organisations actually run: AWS, Azure, GCP and Microsoft 365.
- Reporting written for your PCI DSS and ISO 27001 evidence by a QSA company.
- Fixed scope and price, with any retest and its window agreed in your proposal.
FAQ
Frequently asked questions
Can't find your answer? Call us on +44 161 523 5276 or send us a message.
Can you test our AWS environment?
Yes, within AWS policy: a published list of services, only on resources you own, with no denial-of-service or flooding. Our guide to AWS and Azure penetration testing rules covers the policy, and our AWS testing service sets out what we test.
Can you penetration test Azure and Google Cloud?
Yes. Microsoft and Google both let customers test their own resources within their rules of engagement, which rule out denial-of-service and attacks on other tenants; our Azure testing service covers the Azure scope in detail.
What is the difference between a cloud security assessment and a cloud penetration test?
A cloud security assessment reviews your configuration against benchmarks to find misconfigurations at scale. A penetration test then confirms which of those are exploitable and hunts for issues a review alone misses, such as privilege-escalation paths between roles. We deliver both together, because each catches things the other does not.
Does cloud testing cover the provider’s infrastructure?
No. Under the shared responsibility model, the provider secures the underlying platform and you secure what you build on it. Testing focuses on your configuration, identity, applications and data, which is the part you are responsible for and auditors expect you to test.
Do you test Microsoft 365?
Yes, through a review of your Microsoft 365 tenant, which can run alongside testing of AWS, Azure or Google Cloud.
What access do you need?
Typically a read-only role for the configuration review and scoped credentials for hands-on testing. We agree the exact access and any provider notification steps during scoping.
How long does a cloud penetration test take?
A single AWS account or Azure subscription running a typical set of services usually takes about a week of testing, including the configuration review, with the report following. Estates with several accounts, subscriptions or projects, Kubernetes clusters or a Microsoft 365 tenant take longer, and we confirm the timeline during scoping.
How much does cloud penetration testing cost?
The price depends on how many accounts, subscriptions or projects are in scope, how many services you run, and whether Microsoft 365 is included. Our penetration testing cost guide explains the drivers, and our cloud penetration testing quote form returns a fixed price.
Does cloud penetration testing support PCI DSS and ISO 27001?
Yes. Cloud-hosted systems in your cardholder data environment fall under PCI DSS 11.4, and cloud testing supports ISO 27001:2022 Annex A 8.8. We write the report so it serves as evidence. For card data hosted on Amazon, our guide to AWS PCI compliance explains what AWS covers and what stays with you.
Last reviewed October 2026 by the Sovereign Secure assessment team.
Related services
- Network & infrastructure testingNetwork penetration testing for UK firms: external perimeter, internal network and Active Directory attack paths, plus PCI DSS segmentation tests. Get a quote.
- External Penetration TestingExternal penetration testing of your internet-facing perimeter by a PCI QSA company: VPN, email, web and cloud, mapped to PCI DSS 11.4.3. Get a fixed quote.
- API penetration testingAPI penetration testing services for REST, GraphQL and SOAP web services, tested against the OWASP API Security Top 10 by a PCI QSA company. Get a quote.
- ISO 27001 penetration testingISO 27001 penetration testing mapped to Annex A 8.8 and 8.29: what auditors ask for, how often to test and an audit-ready evidence pack. Get a fixed quote.
- Penetration testing costPen test cost in the UK for 2026: published day rates and penetration testing price ranges by test type, what drives cost, and how to get a fixed quote.
- Penetration testing quoteScope your test types and asset counts and get a fixed-price penetration testing proposal.
Free consultation
Talk to an assessor
We aim to reply within one working day, and send a fixed quote once your scope is confirmed.
- PCI SSC-approved QSA, QPA, CPSA, P2PE and 3DS assessors
- IASME-licensed Cyber Essentials certification body
- Clients across the UK, US, Europe, Middle East and Asia since 2012
“The Cyber Security Services were delivered on time and price was competitive.”
Call +44 161 523 5276
Email [email protected]