Cloud Penetration Testing: Scope, Rules, Identity Paths

A cloud penetration test that is scoped like a data centre test misses the control plane, breaks provider rules or tests systems the customer does not own. In the cloud the attack surface is as much IAM roles, federation, workload identities and management APIs as it is virtual machines and open ports, and the provider sets its own rules on what customers may test. This guide is for buyers, asset owners and security managers who commission and govern a cloud penetration test on AWS, Microsoft Azure or Google Cloud. It covers scope under shared responsibility, each provider's testing policy, authorisation and contracts, identity paths as a scope area, safety and stop conditions, and how to handle findings and the credentials given to testers. It does not describe testing methods or tools. For the general programme see the Penetration Testing Guide; for the scoping worksheet see the Penetration Test Scoping Checklist.

Key takeaways

Scope what you control, not what the provider runs. Your accounts, subscriptions, projects, IAM configuration, workloads and data are in scope; the provider's hypervisors, shared services and other tenants never are.
Each provider has its own rules. AWS, Microsoft and Google Cloud do not require notice for ordinary testing of your own resources, but all three prohibit denial of service, and AWS requires a form at least two weeks ahead for red team, phishing, malware and command and control simulations.
Identity is the main cloud attack path. Ask testers to assess role assumption, cross-account trust, workload and service account permissions, federation and CI/CD credentials, and to report complete paths from a starting identity to sensitive data.
Authorisation must name exact resources. Written authorisation from the resource owner should list account IDs, subscription IDs, tenant IDs and project IDs, dates, source addresses and named contacts; a provider cannot authorise testing on your behalf.
Test credentials and reports are sensitive assets. Issue dedicated, short-lived, labelled identities to testers, revoke them at close, rotate anything exposed, and protect the report like the secrets it may contain.

What a cloud penetration test covers under shared responsibility

AWS describes shared responsibility as security "of" the cloud (provider) and "in" the cloud (customer); test scope follows the customer's share. The Cloud Security Alliance Cloud Penetration Testing Playbook makes the same point: customer-controlled systems such as a virtual machine in IaaS are in scope, while the hypervisor beneath it is not.

Layer	Customer controls (can be in scope)	Provider controls (out of scope)	Scope question for the asset owner
Identity and control plane	IAM users, roles, policies, service accounts, service principals, federation trusts, organisation policies	The IAM service itself, its APIs and infrastructure	Which identities and permission boundaries should testers start from?
IaaS compute and network	Guest OS, installed software, security groups, network security groups, firewall rules, load balancers you configure	Hypervisor, physical network, host hardware	Which VPCs, VNets and subnets, and which instances are production?
Containers and serverless	Cluster configuration, workload identities, function code and its execution role	Managed control plane hosts, shared runtime	Which clusters and functions, and with which roles attached?
Managed data services	Data, access policies, encryption settings, key permissions, public access settings	Storage and database service internals	Which buckets, databases and key vaults hold regulated data?
SaaS built on the cloud	Your tenant configuration, users, integrations and OAuth grants	The SaaS application and its infrastructure	Does the SaaS vendor allow customer testing at all, and under which terms?

Two scope decisions matter most. First, external versus assumed breach: an external test starts with no access and shows what the internet sees; an assumed-breach test starts from a given identity (a developer, a CI runner, a compromised workload) and shows how far that identity reaches. Second, configuration review versus penetration test: a configuration review checks settings against a benchmark; a penetration test shows whether weaknesses chain into real impact. Say in the statement of work which you are buying.

Provider testing policies at a glance

Service lists change: re-read each page before every engagement. Summary as read on 24 October 2026.

Topic	AWS	Microsoft Azure	Google Cloud
Notice for ordinary testing of your resources	Not required for listed services (including EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, ECS, Fargate, Elastic Beanstalk, Lightsail, OpenSearch, FSx, Transit Gateway, WAF, NAT gateways, ELB, AppSync, Global Accelerator, Bedrock AgentCore)	Not required since 15 June 2017; the Microsoft Cloud Unified Penetration Testing Rules of Engagement are authoritative	Not required; follow the Acceptable Use Policy and Terms of Service
Explicitly prohibited	DoS and DDoS (including simulated), port, protocol and request flooding (including login and API flooding), Route 53 zone walking, DNS hijacking and pharming, S3 bucket and subdomain takeover, assessments of AWS infrastructure or AWS services themselves, outbound testing from API Gateway and Bedrock AgentCore	DoS of any kind, network-intensive fuzzing, using credentials that are not yours (including leaked ones), touching storage outside your subscription, phishing Microsoft employees, post-exploitation against Microsoft services beyond proof of concept	Anything that affects other customers' projects or breaches the Acceptable Use Policy
Needs advance approval	Simulated events form at least two weeks ahead for red, blue and purple team exercises, any command and control, simulated phishing, malware testing and iPerf; AWS aims to respond within two business days; China regions use a separate form	DDoS resilience testing only through Microsoft-approved simulation partners	Not stated beyond the general policy
Reporting provider vulnerabilities	Vulnerabilities caused directly by AWS tools or services to AWS Security within 24 hours of completing testing	To MSRC promptly under coordinated vulnerability disclosure	Through the Google Vulnerability Reward Program
Other conditions	Customer liable for damage to AWS or other customers; any tool with DoS capability must have it disabled; resellers answer for their customers' tests	Label test accounts and tenants with "MSOBB" where possible; Microsoft may interrupt any attack in progress and may suspend accounts that break the rules	Report through the VRP rather than probing Google infrastructure

Bandwidth and rate limits: AWS limits testing to the agreed services, bandwidth, requests per minute and instance types. Put the agreed rate in the rules of engagement.
Accidental access to provider data: Microsoft's rules say stop, notify MSRC, delete the data and record it in the report. Write the same rule into your contract for any provider or third-party data.
Microsoft 365 and other services: the Azure no-notice statement covers Azure; the unified rules of engagement cover Microsoft online services more broadly.

Authorisation, contracts and rules of engagement

Microsoft states that third parties such as consultancies and red teams need explicit written authorisation from the resource owner, documented in the service agreement before testing begins, and that Microsoft does not grant authorisation on the customer's behalf.

Confirm ownership: list every in-scope AWS account ID, Azure subscription and tenant ID, and Google Cloud project and organisation ID, and confirm each is owned by the commissioning entity. Exclude accounts owned by partners or vendors unless they sign too.
Write the authorisation letter: signed by someone with authority over the accounts, naming the testing firm, individual testers, start and end dates and times with time zone, source IP addresses, in-scope and out-of-scope resources.
Agree the rules of engagement: testing windows, rate limits, production restrictions, data handling, stop conditions, communication channels and the out-of-hours escalation contact.
Cover legal terms in the contract: liability and insurance, confidentiality, data protection terms if personal data may be seen (a processor agreement under UK or EU GDPR Article 28 where relevant), retention and destruction of test data and evidence, and subcontracting restrictions.
File provider approvals: submit the AWS simulated events form where it applies and keep the approval reference with the authorisation.
Tell the right internal people: the SOC, cloud platform team and incident response lead should know a test is running, unless the test is deliberately unannounced, in which case a named "white cell" contact confirms it within minutes.

Choosing the firm is a separate decision covered in the Penetration Testing Provider Buyer's Guide. For cloud work, ask for redacted identity path findings and the named testers' provider experience.

Identity and IAM paths as a scope area

In cloud breaches the decisive step is usually an identity that can do more than intended. Ask testers to assess these paths and to report each finding as a chain from a starting identity to an impact. The table lists what to request (what to assess, not how), with the ATT&CK technique defenders will recognise.

Scope item to request	Why it matters	ATT&CK reference for defenders	Evidence to expect in the report
Permissions of starting identities (developer, CI runner, workload)	Shows the real reach of a compromised everyday identity	T1078.004 Cloud Accounts	Effective permissions and the resources they reach
Privilege escalation through IAM changes	Rights to create keys or attach roles turn a low identity into an administrator	T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles	Which permission enabled the escalation and the policy that grants it
Role passing and service account impersonation	AWS iam:PassRole and Google iam.serviceAccounts.getAccessToken let one identity act with another's rights	T1548.005 Temporary Elevated Cloud Access	The pair of identities and the binding or policy linking them
Instance and workload metadata exposure	Applications that can be made to fetch internal URLs may expose role credentials	T1552.005 Cloud Instance Metadata API	Whether metadata protections (such as AWS IMDSv2) are enforced
Cross-account, cross-tenant and federation trusts	Trusts with partners, old accounts or external identity providers bypass local controls	T1078.004 Cloud Accounts	List of trusts, their conditions and which are unused
Data store access from discovered identities	Confirms whether paths end at regulated data	T1530 Data from Cloud Storage	Proof of access (metadata or a marker file), not bulk data
Visibility of the estate to a low-privilege identity	Broad read rights make the rest of an attack easier	T1580 Cloud Infrastructure Discovery, T1526 Cloud Service Discovery, T1069.003 Cloud Groups	What a reader-level identity could enumerate

Secrets in pipelines and code: include CI/CD variables, infrastructure-as-code state files and container images in scope where they hold cloud credentials. See the Secrets Management Guide.
Use your own analysis first: AWS IAM Access Analyzer (external, internal and unused access analysers) and equivalent tools in Azure and Google Cloud find many issues before a tester is paid to find them. Share the output with testers. See the Cloud IAM Review Checklist.
Per-provider depth: the AWS IAM Policies and Roles Guide, Azure RBAC and Service Principals Guide and Google Cloud IAM and Service Accounts Guide explain the permission models testers will assess.

Safety and stop conditions

Write stop conditions into the rules of engagement so both sides can act on them at any hour.

Stop on unexpected data: if testers reach personal, payment or health data, another tenant's data or provider data, they stop, record the path without copying the data, and notify the named contact.
Stop on instability: errors, latency spikes, autoscaling events or cost alerts linked to testing pause the test until the asset owner agrees to resume.
No destructive changes: testers demonstrate the ability to modify or delete with a harmless marker (a tagged test object) rather than changing production resources.
Stop on real compromise indicators: signs of a genuine intruder go straight to incident response. See the Cloud Incident Response Guide.
Kill switch for test identities: the platform team can disable every tester identity in one action, and has rehearsed it.

Where identity fits: credentials given to testers

An assumed-breach test needs the organisation to hand over access, and those credentials become a real attack path if they leak or outlive the test. The Red Hat Consulting GitLab breach exposed tokens and connection strings held in customer engagement reports.

Stage	Control	Owner
Issue	Dedicated identities per tester, never shared or personal accounts; names tagged as test accounts (Microsoft recommends "MSOBB" in test account or tenant names); MFA on human access; expiry set to the test end date	Cloud platform team
Scope	Permissions matching the agreed starting position, plus a permissions boundary or service control policy that blocks out-of-scope accounts and destructive actions	Cloud platform team with asset owner
Use	Source IP restriction where possible; all activity logged to a store testers cannot change	Security operations
Hand-over	Credentials shared through a vault or one-time secret link, never email or chat	Engagement manager
Close	Disable and delete identities, revoke sessions and keys, remove trust policies and test resources, confirm in writing	Cloud platform team
After	Rotate any secret found during testing, because it has now been seen by a third party and is written in a report	Secret owners

The broader rules for tester access appear in the Penetration Testing Guide; the rotation steps are in the Leaked Credential Response Playbook.

Handling findings and reports

Report structure: ask for findings grouped as attack paths (starting identity, each step, impact) as well as individual issues, with the exact policy, binding or setting that needs to change. The NCSC notes that risk decisions on findings remain the organisation's, not the tester's.
Severity in context: agree a scheme that weights identity reach and data sensitivity.
Secrets in reports: require testers to redact credentials and tokens in the report and evidence, and to store evidence encrypted with agreed retention and destruction dates.
Provider vulnerabilities: if testers find a flaw in the provider's own service, it is reported to the provider under its programme (AWS Security within 24 hours where the flaw comes from AWS tools or services, MSRC, Google VRP), not exploited further.
Remediation and retest: enter findings into the vulnerability management process with owners and due dates, and include a retest in the contract. See the Vulnerability Management Guide.
Risk acceptance: any finding not fixed gets a documented acceptance with an expiry date and a compensating control.

How to commission and run a cloud test

Set the objective: for example, "can a compromised CI runner reach customer data in production?"
Inventory the estate: accounts, subscriptions, projects, identity providers, federation trusts and CI/CD systems.
Run your own checks first: configuration posture tooling and access analysers.
Check provider rules: read the current AWS, Microsoft and Google pages and file the AWS simulated events form at least two weeks ahead if the test includes red team, phishing, malware or command and control.
Sign authorisation and rules of engagement: as set out above, with contacts and stop conditions.
Prepare test identities and logging: issue scoped, labelled, expiring identities; confirm that AWS CloudTrail, the Azure activity log and Entra ID sign-in and audit logs, and Google Cloud Audit Logs are capturing the in-scope accounts.
Start in non-production or with a pilot slice: one account or project first, review the first day's activity and any side effects, then widen.
Hold daily check-ins: critical findings are reported the same day, not saved for the report.
Roll back at close: remove every test identity, resource, policy change and trust, compare against the pre-test configuration snapshot, and get written confirmation.
Report, fix and retest: track remediation to closure and feed lessons into guardrails.

Decision guidance

Situation	Better choice	Trade-off
First test of a new cloud estate	Configuration review plus assumed-breach identity path test	Less realism about external entry, far more coverage of what matters
Internet-facing application on cloud	Application test plus cloud configuration of its hosting account	Two scopes to coordinate; see the Web Application Security Testing Guide
Mature estate with strong guardrails	Objective-based red team with provider approvals	More cost and lead time; needs a white cell
Small organisation vs large multi-cloud estate	Small: annual assumed-breach test from a developer identity. Large: rolling programme by business unit plus cross-cloud federation paths	Needs central scoping standards and a single findings register
Continuous assurance needed between tests	Breach and attack simulation for repeatable checks	Covers known scenarios only; see the Breach and Attack Simulation (BAS) Guide

Detection and measurement

Ask the SOC to record what it saw and compare with the testers' activity log at close.

What to monitor during the test: new access keys, role or binding changes, assumed roles from unusual sources, service account token creation, consent and federation changes, and data access spikes on in-scope stores.
Percentage of tester actions detected: share of reported steps that produced an alert or a log the SOC reviewed.
Time to detect and time to contain: for unannounced tests, from first action to alert and from alert to disabling the identity.
Identity paths to crown jewels: count of complete paths from a standard starting identity to regulated data; this should fall between tests.
Critical finding closure time: median days from report to verified fix.
Test hygiene: tester identities removed within one business day of close, and secrets rotated where exposed (target: all).

Framework mapping

Framework	Reference	How a cloud penetration test supports it
NIST SP 800-53 Rev. 5	CA-8 Penetration Testing; CA-8(1) Independent Penetration Testing Agent or Team; CA-8(2) Red Team Exercises	Independent testing of cloud systems, with red team exercises for mature estates
NIST SP 800-53 Rev. 5	RA-5 Vulnerability Monitoring and Scanning; AC-6 Least Privilege	Findings feed vulnerability management; identity path findings test least privilege
NIST CSF 2.0	ID.RA-01; ID.IM-02; PR.AA-05	Vulnerabilities identified and recorded; improvements from tests; access permissions reviewed
CIS Controls v8.1	Control 18 Penetration Testing	A programme of external and internal testing with remediation
ISO/IEC 27001:2022 Annex A	A.8.8 Management of technical vulnerabilities; A.8.29 Security testing in development and acceptance	Evidence that vulnerabilities in cloud systems are found and treated
Methodology	NIST SP 800-115; CSA Cloud Penetration Testing Playbook	Testing process and cloud-specific scope boundaries for the provider to follow

Common failure patterns

Testing the network, missing the identity layer: a port-and-host test of cloud workloads with no assumed-breach phase. The Capital One breach turned on a firewall's role credentials and what that role could read, exactly the path an identity-scoped test is meant to find.
Trusting role names over permissions: scoping a role as harmless because of its name or description. The Azure Key Vault Contributor escalation showed a role described as having no data access could still lead to reading secrets.
Vague authorisation: letters naming "our AWS environment" rather than account IDs, so testers touch a partner's account.
Test access that never ends: tester users, keys and trust policies left in place after the report.
Reports full of live secrets: unredacted tokens and connection strings in reports and evidence, stored in shared drives and ticketing systems.
Red team without provider approval: command and control or phishing simulations on AWS without the simulated events form, leading to abuse reports and a stopped test.

Practitioner checklist

State one objective for the test and choose external, assumed-breach or both.
List every in-scope account, subscription, tenant and project ID and confirm ownership.
Read the current AWS, Microsoft and Google Cloud testing policies and file AWS simulated events forms two weeks ahead where needed.
Sign written authorisation and rules of engagement with dates, source IPs, contacts and stop conditions.
Put identity paths in the statement of work: role assumption, role passing, service account impersonation, federation, metadata and CI/CD credentials.
Issue dedicated, labelled, expiring tester identities with a permissions boundary, and rehearse the kill switch.
Confirm cloud audit logging is on for all in-scope accounts before day one.
Require redaction of secrets in reports and encrypted evidence with a destruction date.
Remove all tester access and test artefacts at close, rotate exposed secrets and schedule the retest.

Cloud Penetration Testing Guide: Scope, Provider Rules and Identity Paths