Cloud penetration testing has become a priority for UK organisations as sensitive workloads, customer data and critical applications move to public cloud platforms. But testing in the cloud is fundamentally different from testing on-premises environments. Testers must work within provider-specific rules of engagement, understand which layers they can and cannot touch, and scope engagements around a shared responsibility model that splits security obligations between provider and customer.

This guide is for security managers, IT leads and platform engineers planning a cloud penetration test. It covers practical differences across AWS, Azure and GCP, common identity and configuration risks, scoping pitfalls, reporting expectations, retesting, and what to look for when comparing providers.

How Cloud Penetration Testing Differs from Traditional Testing

In a conventional penetration test, the organisation typically owns every layer of the stack, from physical hardware and network infrastructure through to the operating system and application code. The tester has a relatively clear boundary: everything inside the network perimeter is fair game, subject to agreed rules.

Cloud environments change this picture. You do not own the infrastructure. The cloud provider owns and manages the physical hosts, hypervisors and much of the networking, and testing those components is prohibited. Assets are dynamic: auto-scaling groups, ephemeral containers and serverless functions mean the attack surface can shift mid-engagement. Identity replaces the traditional network boundary, making IAM policies, API keys and service account credentials primary attack vectors. And each Cloud Service Provider publishes specific policies governing what testing is permitted on their platform. Violating those rules can get your account suspended.

A cloud penetration test therefore demands specialist knowledge not just of offensive security techniques, but of the specific platform's architecture, services and policy constraints.

Provider Rules of Engagement: AWS, Azure and GCP

Before any testing begins, the engagement team must confirm what is permitted under the target provider's policies. The rules differ across the three major platforms.

AWS

AWS allows customers to perform security assessments against many of its services without prior approval. This includes testing against EC2 instances, Lambda functions, API Gateway endpoints, RDS databases and several other customer-managed resources.

AWS explicitly prohibits DoS/DDoS simulation, DNS zone walking via Route 53 hosted zones, port or protocol or request flooding, and testing AWS-managed infrastructure or services outside the customer's control. If AWS detects traffic patterns resembling a DoS attack, it may throttle or suspend the account.

Microsoft Azure

Since 2017, Microsoft has not required pre-approval for penetration tests on Azure resources. Testers must comply with the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Testing must target only resources owned by the tester's organisation. DDoS simulation requires engagement with a Microsoft-approved partner through the Azure DDoS Protection service. Attacks against other tenants, Microsoft-managed infrastructure or shared services are prohibited.

Google Cloud Platform

GCP does not require customers to notify Google before testing their own projects and resources. Testing is governed by the Acceptable Use Policy. It must be confined to resources within the customer's own GCP projects, and provider-managed infrastructure outside the project boundary is off-limits. Aggressive scanning may trigger abuse reports, so teams should be ready to respond.

Across all three platforms, the principle is the same: you may test what you manage, but you must not test what the provider manages. Document the specific provider policy version reviewed during scoping and keep a record for your audit trail.

The Shared Responsibility Model and Scoping Implications

The shared responsibility model is the foundation of cloud security and the starting point for any cloud penetration test scope. The provider is responsible for the security of the cloud; the customer is responsible for security in the cloud.

What this means in practice depends on the service model. With IaaS (virtual machines, for example), the customer manages the operating system, applications, data and network controls, while the provider manages the physical host, hypervisor and underlying network. With PaaS (managed databases, container orchestration), the provider takes on more responsibility for the runtime and platform, but the customer still manages data, access controls and application configuration. With SaaS (Office 365, Salesforce), the provider manages nearly everything; the customer handles user access, data classification and integration security.

What Is Typically In Scope

• IAM policies, roles and permissions
• Virtual machines, containers and serverless functions
• Storage resources (S3 buckets, Azure Blob Storage, GCS buckets)
• Network security groups, firewalls and VPC configurations
• API endpoints and web applications hosted on cloud infrastructure
• CI/CD pipelines and deployment configurations
• Logging and monitoring configurations (CloudTrail, Azure Monitor, etc.)

What Is Typically Out of Scope

• The underlying hypervisor and physical infrastructure
• Provider-managed control planes and shared services
• Other tenants' resources
• Services explicitly excluded by the provider's rules of engagement

Getting this boundary wrong is one of the most common and most consequential scoping errors in cloud penetration testing.

Common Identity and Configuration Risks

Cloud security incidents are rarely caused by a failure in the provider's infrastructure. The vast majority stem from customer-side misconfigurations and identity management weaknesses. A thorough cloud penetration test should focus on the following areas.

Identity and Access Management

IAM is often the single most critical attack surface in a cloud environment. Overly permissive policies, where roles or users are granted broad permissions like AdministratorAccess when least-privilege would suffice, are common. So are long-lived static API keys that never get rotated and end up exposed in code repositories. Service accounts frequently have permissions far beyond what the workload actually requires. Missing MFA on privileged or root accounts remains widespread. And cross-account trust relationships sometimes inadvertently grant access to unintended principals.

Storage and Data Exposure

Publicly accessible storage buckets containing sensitive data are a recurring finding. Misconfigured ACLs or bucket policies and unencrypted data at rest or in transit round out the usual issues.

Network and Compute Misconfigurations

Overly permissive security group rules (allowing SSH or RDP from 0.0.0.0/0, for instance), exposed cloud metadata endpoints that leak temporary credentials, and unpatched virtual machines or container images with known vulnerabilities all feature regularly.

API and Supply Chain Risks

Weak or missing authentication on API endpoints, insecure CI/CD pipelines that leak secrets or allow code injection, and third-party integrations with excessive permissions are increasingly common findings.

A skilled cloud penetration tester will chain findings across these categories. For example, they might use an exposed metadata endpoint to obtain temporary credentials, then leverage overly permissive IAM policies to move laterally across the environment.

Scoping Pitfalls and a Practical Checklist

Poor scoping is the most common reason cloud penetration tests underdeliver. The dynamic, multi-account nature of cloud environments creates problems that don't arise in traditional testing.

Ambiguous asset ownership is a frequent issue in large organisations where cloud accounts and projects span multiple teams. Without clear ownership, testers may miss critical assets or accidentally test resources outside the agreed scope. Scoping documents that fail to delineate customer-managed from provider-managed components risk policy violations. Lambda functions, Azure Functions, Cloud Run and managed Kubernetes clusters are often overlooked but represent significant attack surface. A scope defined by IP address alone will miss auto-scaled or ephemeral resources; cloud scoping should reference account IDs, project IDs and resource identifiers instead. And organisations using more than one CSP, or maintaining hybrid environments, need scoping that covers the boundaries between them.

Scoping Checklist

Use this as a starting point when defining the engagement scope:

1. List all cloud accounts, subscription IDs, project IDs and tenant IDs in scope.
2. Specify exact resource identifiers: ARNs, Azure Resource IDs or GCP resource paths.
3. Confirm the service model for each component (IaaS, PaaS, SaaS) and map responsibilities accordingly.
4. Review and document the relevant provider's current penetration testing policy.
5. Define permitted techniques explicitly (e.g., no DoS, no social engineering of provider support).
6. Identify sensitive or production workloads that require additional care or restricted testing windows.
7. Establish emergency contacts and communication channels for the duration of the test.
8. Agree how credentials or test accounts will be provisioned and decommissioned.
9. Confirm whether the test includes application-layer testing for workloads running on cloud infrastructure.
10. Document any compliance or regulatory drivers (ISO 27001 audit, PCI DSS requirement, etc.) that shape evidence requirements.

Evidence Requirements and Reporting

The value of a cloud penetration test depends heavily on the quality of its output. A credible report should go well beyond automated scanner output and provide clear, actionable findings.

What Good Evidence Looks Like

Findings should be supported by cloud-native logs such as CloudTrail, Azure Activity Log or GCP Cloud Audit Logs. Screenshots and configuration exports should provide visual evidence of misconfigurations. API and application-layer findings need full HTTP request/response pairs that allow reproduction. And every finding should include step-by-step proof-of-concept instructions so the customer's team can verify it independently.

Reporting Structure

A well-structured report typically includes an executive summary suitable for senior leadership, a methodology section covering approach, tools and limitations, and technical findings with clear descriptions, evidence, risk ratings (usually CVSS or similar) and specific remediation guidance. Where relevant, findings should be mapped to applicable frameworks like ISO 27001, UK GDPR or PCI DSS. Broader observations about security architecture, processes or governance that don't map to a single vulnerability belong in a strategic recommendations section.

Avoid providers whose reports consist primarily of raw tool output with little context or remediation advice. The report is the primary deliverable. It should be thorough enough to drive remediation and robust enough to satisfy auditors.

Retesting: Closing the Loop

Retesting is essential but frequently neglected. Its purpose is to verify that remediations are effective and haven't introduced new issues.

Define retesting upfront. The scope, timeline and cost should be agreed in the initial Statement of Work, not negotiated after findings are delivered. Allow adequate remediation time; a retest conducted too soon may find that teams haven't yet implemented fixes. Two to four weeks is a common window, though this varies by finding severity. Not every finding requires a formal retest. Prioritise critical and high-severity issues, particularly those involving data exposure or privilege escalation. Many UK organisations need a formal attestation that specific findings have been remediated, so confirm your provider offers a retest letter or certificate.

Market Trends: PTaaS and Continuous Testing

The traditional model of annual point-in-time penetration testing is increasingly being supplemented or replaced by Penetration Testing as a Service (PTaaS). These platforms typically combine automated scanning and continuous monitoring with periodic manual testing by qualified consultants.

For cloud environments, this model fits well. New resources, configuration changes and deployments happen continuously, and a test conducted in January may bear little resemblance to the environment in June.

PTaaS often overlaps with Cloud Security Posture Management (CSPM) and Cloud-Native Application Protection Platform (CNAPP) tooling, which provides automated, continuous visibility into misconfigurations and policy violations. These tools are valuable, but they do not replace the judgement and creativity of a skilled human tester, particularly for complex attack chains involving IAM, application logic and cross-service exploitation.

When evaluating PTaaS offerings, ask how the provider balances automated detection with manual testing, how frequently manual assessments are conducted, and how findings are triaged and communicated.

Buyer's Guide: Comparing UK Cloud Penetration Testing Providers

Selecting the right provider requires more than comparing day rates.

Accreditations and Qualifications

CREST membership is the most widely recognised accreditation for penetration testing firms in the UK. CREST-member companies employ testers who have passed rigorous practical examinations.

CHECK certification, administered by the NCSC, is typically required for UK public sector engagements. For individual testers, look for credentials like OSCP, OSWE, CRT or CCT, which indicate hands-on technical competence.

Platform-Specific Expertise

Not all penetration testing firms have deep cloud experience. Ask potential providers how many cloud-specific engagements they've completed in the past 12 months, whether they hold cloud-specific certifications (AWS Security Specialty, AZ-500, Google Professional Cloud Security Engineer), and whether they can demonstrate experience with the specific services in your environment, be that Kubernetes, serverless or managed databases.

Reporting and Communication

Request a sample report before engaging. Assess whether findings are clearly explained, evidence is thorough, and remediation advice is specific. Ask how findings are communicated during the test. Good providers flag critical issues immediately rather than waiting for the final report. Confirm whether the report includes compliance mapping relevant to your obligations.

Commercial and Practical Considerations

Find out whether a retest is included in the price or charged separately, and what the retest window looks like. Ask whether the provider helps you define the scope or expects a fully formed brief. Confirm they hold adequate professional indemnity and public liability insurance. Understand where test data and reports will be stored, who has access, and how data is disposed of after the engagement, which matters particularly if you handle personal data under UK GDPR. For engagements requiring close collaboration, a provider operating in UK time zones with UK-based testers can reduce friction.

Questions to Ask During Procurement

• What is your methodology for cloud penetration testing, and how does it differ from traditional infrastructure testing?
• How do you handle provider-specific rules of engagement?
• Can you test across multi-cloud or hybrid environments?
• What tools and frameworks do you use for cloud-specific assessments?
• How do you ensure testing does not disrupt production workloads?
• What is your process if you discover a critical vulnerability during the engagement?

Choosing a cloud penetration testing provider is a decision that directly affects your organisation's security posture. Take the time to evaluate technical depth, reporting quality and practical experience, not just price and availability.