Cloud Penetration Testing: The Scope Line That Shrinks the Test
A cloud penetration testing engagement tests how an attacker could abuse your cloud environment, across IAM roles, exposed storage, identity attack paths, cloud-native services, containers, and hybrid connections. The test covers only the accounts and systems on the written scope list, so the scope document decides the result. A 6-question scope audit before kickoff keeps the engagement from shrinking to a single account.
The scoping call starts with a line that sounds complete and is not. "Test our cloud" is one of the most expensive phrases in a security budget, and in scoping calls, we consistently watch the production account get dropped from the list: it is the account nobody wants to hand over a read-only key for, or the account the list was written before. The test then runs against the sandbox, the staging tenant, the dev account, and the report comes back clean. Clients are often surprised to learn the clean report described only the account they least use, not the one where the data is.
The problem is real and current. NIST SP 800-145 defines cloud computing by on-demand access to a shared pool of configurable resources, and that shared pool is exactly what a scope must name, because the pool spans accounts, regions, and services that do not all answer to one team [4]. CISA's Known Exploited Vulnerabilities catalog held 1,754 entries as of October 21, 2026, and its two newest additions, entered on October 20, 2026, are the kind of findings a cloud scope misses when the vulnerable server sits in an account the list never named: a Siemens Software Center flaw with a due date of November 3, 2026, and a chain of Plex Media Server flaws, including a server-side request forgery an attacker can steer at their own destination, with a due date as close as October 23, 2026 [1].
Clone Systems' position: a cloud penetration test is only as good as the account list behind it. "Test our cloud" is a line, not a scope, and the account the list misses is the account the attacker uses. The fix is not a bigger test, it is a written scope that names every account, region, and identity, audited against six questions before the kickoff call.
What Does a Cloud Penetration Test Actually Cover?
A cloud penetration test answers the question a scanner cannot: what can an attacker actually do with the misconfiguration, not just that the misconfiguration exists. NIST SP 800-145 describes cloud computing as on-demand access to a shared pool of configurable resources [4], and that is why the coverage follows the pool, not the server: every account the pool spans, every identity in it, every service that can hold or move your data.
The coverage we build into a cloud scope, matched to how attackers move:
- Identity and IAM. Over-permissive roles, standing credentials that outlive their owner, identity attack paths from one identity to more access. A scanner reports a policy; a test walks the policy the way an attacker would.
- Exposed storage. Buckets and volumes reachable when they should not be, including the public one that holds the last year of exports.
- Cloud-native attack paths. Chains of cloud services an attacker could abuse: a misconfigured service that hands over a token, a token that unlocks the next service.
- Containers. Workloads and the permissions around them, which scanners see one pod at a time.
- Hybrid connections. The paths between cloud and on-premises, where the scope line between "our cloud" and "our network" quietly decides what gets tested.
Two numbers frame why the exploitation step matters. Cobalt's 2026 State of Pentesting, built on more than 16,500 tests, puts the half-life of high-risk findings at 10 days for programmatic teams against 249 days for organizations that treat testing as a one-time task [2]. The same report finds programmatic teams resolve 45 percent of critical findings within three days, 4.5x the rate of compliance-driven teams [2]. A clean report on a one-account scope buys you none of that, because the risk you care about was never in scope.
How Is a Cloud Penetration Test Different From a Cloud Security Audit or a Configuration Scan?
It is the difference between knowing a door is unlocked and knowing what is behind it. A configuration scan or posture audit lists every misconfiguration it can see and stops there: the public bucket, the wildcard policy, the unencrypted volume. A penetration test takes one of those doors and walks through it, to the data, to the next identity, to the lateral path.
| Test | What it answers | What it needs | What it costs in findings |
|---|---|---|---|
| Configuration scan / posture audit | What is misconfigured, and where | Scan credentials per account | High volume, unvalidated |
| Cloud penetration test | What an attacker can do with the misconfiguration | Written scope, read-only keys, rules of engagement | Fewer, exploitable, evidence-backed |
| Cloud penetration test with retest | Whether the fix closed the path | A named retest date in the SOW | Closure, proven |
A scan tells you what is present. A test tells you what it is worth to an attacker. The same distinction on the network side, and why the two are not substitutes, is covered in penetration testing vs vulnerability scanning. And when the test finds a broken authorization path in a cloud API, the five-request version of that test is in how to test for broken object level authorization.
If you are comparing quotes for the same cloud scope and the numbers differ widely, the difference is usually the account list, not the hourly rate: penetration test cost: what moves the number.
If your cloud has more than one account and you cannot name the scope line that separates them, the next test should start with the scope, not the scan. Cloud penetration testing for AWS, Azure, and Google Cloud starts with a scoping call and a fixed statement of work.
What Should Your Cloud Penetration Test Scope Include, in Writing?
The scope is a list of things an attacker could use, not a description of your architecture. The items we insist on seeing in writing before kickoff:
- Every account, named by ID or alias. Production, staging, development, shared tooling, and any account a contractor holds. "All our AWS accounts" is not a list; it is an invitation to a clean report on the account you least use.
- Every region, per account. A service in a region the list omits is out of scope by definition, and out of scope is where the findings hide.
- Every identity class. Human, service account, role, federated. The service account is the one nobody wrote down, and the one that holds more rights than its owner remembers granting.
- Workloads and storage. Container hosts, buckets, volumes, and the hybrid paths between them and on-premises systems.
- Out-of-scope list, written. Destructive actions, blackout windows, third-party SaaS you will not touch. Written exclusions protect you as much as written inclusions.
- A retest date. The same scope, re-run after remediation, so the report proves closure instead of assuming it. We cover why that date matters in how often you should penetration test.
In our scoping calls, the first hour of a cloud engagement is usually spent closing exactly this gap: the account list, the region list, the identity list. Each one costs a week of field time when it arrives late, and each one shrinks the effective scope by exactly the amount nobody priced.
The 6-Question Cloud Scope Audit
Run these six questions before you sign the SOW. If the answer to any of them is "we will figure it out on the kickoff call," the scope will shrink, and it will shrink in the direction that makes the report look good.
The Clone Systems 6-Question Cloud Scope Audit
- Can I name every cloud account ID in the scope, not just the provider?
- Is production in that list, with the region where the data actually lives?
- Does the list include service accounts and roles, or only human logins?
- Are the out-of-scope items written down, and who signed them?
- Is there a named retest date for the in-scope findings?
- Does the report say which account and which region each finding came from?
Question six is the one that tells you the test was real. A finding that cannot be placed in an account and a region cannot be verified, and a retest that cannot be placed cannot prove the fix held.
How Clone Systems Can Help
If you are scoping the next test and the cloud line is the soft one, this is how we structure it:
- A written scope, account by account. We run the 6-Question Cloud Scope Audit with you on the scoping call, so the SOW names every account, region, and identity before fieldwork starts. Cloud penetration testing.
- Credentialed, gray box testing. Read-only access for each account in scope, confirmed at kickoff, so the test covers what an attacker with a valid credential could reach.
- Engineer-written report with evidence. Reproduction steps and remediation for every finding, placed in the account and region it came from, with a free remediation retest.
- Managed rhythm after the test. If the gap between tests is the problem, managed penetration testing keeps the scope current as the environment changes.
Not sure what your cloud scope should be? Talk to our team and we will run the six questions with you before you spend on the test.
Frequently Asked Questions
What does a cloud penetration test cover? It covers how an attacker could abuse your cloud environment: IAM misconfigurations, exposed storage, identity attack paths, cloud-native attack paths, containers, and hybrid connections. The test is limited to the accounts and systems named in the written scope, which is why the scope decides the result.
What is the difference between a cloud penetration test and a cloud configuration scan? A configuration scan lists the misconfigurations it can see; a penetration test exploits a path to show what the misconfiguration is worth to an attacker. The scan is high volume and unvalidated; the test is fewer findings with evidence.
What access does a cloud penetration test need? Read-only credentials for each in-scope account, agreed at kickoff with rules of engagement and blackout windows. The access depends on the scope, and the scope is the list of accounts, regions, and identities you hand the tester.
How long does a cloud penetration test take? It scales with the account list: a single-account scope is measured in days, and a multi-account scope with containers and hybrid paths takes longer. The account list is the number that moves the timeline, which is why it is the first thing to fix in penetration test cost.
Do I need a retest after a cloud penetration test? Yes. A retest on the same scope, on a named date, proves the fix closed the path instead of assuming it did. That is the step most cloud test SOWs leave out, and it is the one your auditor will ask about.
Conclusion
"Test our cloud" is the line that lets everyone feel covered and test nothing. The scope is the test: the account list, the region list, the identity list, the written exclusions, the retest date. Run the six questions before kickoff, and the report will describe the cloud you actually run, not the one the list happened to reach.
If your cloud has more than one account, the next step is not a bigger test, it is a written scope. Contact Clone Systems and we will run the 6-Question Cloud Scope Audit with you before the SOW is signed.
References
[1] CISA, Known Exploited Vulnerabilities (KEV) Catalog, accessed October 21, 2026. Catalog listed 1,754 entries; the two most recent additions (CVE-2026-110936 Siemens Software Center, due 2026-11-03, and the chained Plex Media Server entries including CVE-2026-96652 SSRF, due 2026-10-23) were added 2026-10-20. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [2] Cobalt, State of Pentesting Report 2026 (publisher landing page; full report is a PDF, figures taken from the publisher's summary). https://resource.cobalt.io/state-of-pentesting-2026 [3] CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, issued June 10, 2026. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk [4] NIST, SP 800-145, The NIST Definition of Cloud Computing (Mell and Grance, 2011). https://csrc.nist.gov/pubs/sp/800/145/final [5] Clone Systems, Penetration Testing vs Vulnerability Scanning: Why the Difference Matters. https://www.clone-systems.com/blog/penetration-testing-vs-vulnerability-scanning [6] Clone Systems, How to Test for Broken Object Level Authorization: The 5 Requests That Prove It. https://www.clone-systems.com/blog/how-to-test-for-broken-object-level-authorization [7] Clone Systems, Penetration Test Cost: What Moves the Number and Why Two Quotes for the Same Scope Can Differ by 5x. https://www.clone-systems.com/blog/penetration-test-cost-what-moves-the-number [8] Clone Systems, How Often Should You Penetration Test? Frequency, Scans, and the Retest Nobody Books. https://www.clone-systems.com/blog/how-often-should-you-penetration-test-frequency-scans-and-the-retest-nobody-books [9] Clone Systems, Cloud Penetration Testing for AWS, Azure and Google Cloud. https://www.clone-systems.com/cloud-penetration-testing [10] Clone Systems, Managed Penetration Testing Services. https://www.clone-systems.com/managed-penetration-testing-services/