A cloud pentest is not a posture scan with a better PDF. This is the sequence we actually run, what you need ready before day one, how long it takes, and the things it deliberately leaves out.
A cloud penetration test answers one question: which single exposure in your AWS, Azure or Google Cloud estate actually reaches your data or your control plane. Not how many misconfigurations you have. Which of them connect.
That distinction is the whole job. A cloud security posture management (CSPM) tool returns hundreds of findings against a benchmark and cannot tell you which three of them chain. A pentest is a person following the chain by hand: this bucket is public, it holds this key, that key assumes this role, that role reads this database.
The threat data points the same way. The Cloud Security Alliance’s Top Threats to Cloud Computing 2024 ranks misconfiguration and inadequate change control first, identity and access management second, and insecure interfaces and APIs third. All three are things you configure, not things your provider runs.
Nothing is enumerated until the paperwork is done. Almost every argument later in an engagement traces back to something not written down here.
The rules of engagement record what may be touched and what may not: which accounts, whether production data may be listed or read, whether resources may be created, and who gets called if something breaks. Read only enumeration first, controlled exploitation only inside those rules.
Your provider’s policy sits on top of yours, and the three do not agree.
Testing starts where a real attacker starts: from the public internet, with no account and no key.
Nothing is acted on yet. This is intelligence gathering in PTES terms, the first half of discovery in NIST SP 800-115 terms.
On a web test the interesting object is a request. On a cloud test it is an identity. This phase has no equivalent in the other pentest types, and it takes the most time.
With the read only role we enumerate the estate as it is, not as the diagram describes it: roles and their trust policies, permission boundaries and service control policies, key and storage policies, and every machine identity attached to a workload. That list is then cut down to what is reachable from where we stand.
None of this is quick to fix. Verizon’s 2026 Data Breach Investigations Report, which draws on more than 22,000 confirmed breaches, looks separately at how third party cloud exposure gets remediated: only 23% of those organisations fully remediated missing or improperly secured multi factor authentication on their cloud accounts, and for weak passwords and permission misconfigurations it took almost eight months to resolve half of all findings.
Everything so far is a hypothesis. This phase turns each into a proof, or discards it.
We attempt the escalation: a limited role turned into a bigger one through a policy it can attach or a pipeline it can trigger. Then the hop into the next account, and the reach into the data: object storage, database snapshots, the keys that decrypt them. Every attempt runs inside the rules agreed on day one, and every successful one is captured as the exact request, the policy that permitted it, the response and a timestamp.
Privilege escalation has to be demonstrated rather than inferred: "this role could theoretically escalate" is a finding your engineers will argue with; "this role escalated at 14:12, here is the call" is one they will fix. And a chain is taken far enough to establish what it reaches, no further.
Patchable vulnerabilities belong here but are rarely the headline. The same Verizon report puts exploitation of vulnerabilities at 31% of known initial access vectors, ahead of credential abuse at 13%, and finds that only 26% of critical vulnerabilities, defined as those in CISA’s Known Exploited Vulnerabilities catalogue, were fully remediated during 2025, down from 38% the year before. That catalogue held 1,655 entries on 27 July 2026; anything appearing on it is tested first.
A chain like this, told end to end, reads like this: a server-side request forgery in a public application reaches the metadata service, the instance role credentials allow a second role to be assumed, and an over-permissive bucket policy turns that second role into reading another tenant’s data. Three configurations that were nothing on their own.
The report is the only part of the engagement most of your organisation will read, so it addresses two audiences.
NIST SP 800-115 describes a four stage methodology of planning, discovery, attack and reporting, with a feedback loop from attack back to discovery whenever an exploit reveals something new. That is what following a cloud chain looks like. PTES sets out seven sections: pre engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting.
Findings are mapped onto MITRE ATT&CK, whose cloud matrix covers IaaS, SaaS, identity provider and office suite platforms, and onto the relevant CIS Benchmark. CIS publishes Foundations Benchmarks for AWS, Azure and Google Cloud, plus benchmarks for managed Kubernetes including EKS and GKE.
A single account or subscription on one provider is typically one to two weeks of active testing. A multi account, multi region or multi cloud estate, or one with significant Kubernetes, is typically two to four weeks. Scoping happens before that window and the retest after your fixes.
The range is fixed in the proposal, not extended mid engagement because something interesting turned up.
This is the section most providers leave out, and the one that prevents an argument in month three.
A finding is not closed because a ticket moved column. It is closed when the original proof stops working.
The retest replays each proven chain against the fixed environment, using the steps recorded in the report. It fails at the step you changed, and closes with dated evidence. Or it still works, and you get the new request that proves it. Or it fails at a different step, which usually means the symptom was patched and the cause was not. That last outcome is why a retest starts from the original proof, not from the recommendation.
For an ISO 27001, ENS, PCI DSS or SOC 2 file, the retest evidence is what the auditor wants: not that you had findings, but that you closed them and can show the before and after, with timestamps.
The same seven phases applied across every engagement type are set out in our pentesting methodology, end to end. The scope and deliverables for this one are on our cloud pentesting page.
Every figure and framework reference above comes from one of these.
What the secure development lifecycle is, what happens in each phase, what SAST, DAST and SCA add, and where to start if you have nothing in place today.
What risks generative AI brings into a company, why prompt injection is not the real problem, and what an AI pentest actually tests.
What a penetration test is, what phases it has, what you get at the end, how long it takes and how it differs from a vulnerability scan.
If any of this looks like a problem you are carrying, half an hour on a call scoping it with a senior pentester is worth more than reading another article.
Hablar con un pentester seniorPick a time that suits you. You tell us what you need and where you are, and we explain how we work and how we can help.
