Start with the question, then choose the method
A cloud configuration assessment asks whether the way you have built and operated the environment leaves avoidable exposure. A cloud penetration test asks whether an attacker, from an agreed starting point, can cross a particular security boundary. Both can reveal the same excessive permission, but they produce different evidence and have different coverage limits.
For a newly inherited AWS account or Azure subscription, a broad review may be the useful first step. For a customer asking whether a compromised application identity can reach a sensitive repository, a focused pentest may answer the question more directly. The names on proposals are not standardized; make the actual methods and deliverables explicit.
| Decision | Configuration assessment | Cloud penetration test |
|---|---|---|
| Primary question | Are the reviewed controls configured and operated appropriately? | Can the agreed starting access reach an unauthorized outcome? |
| Typical input | Inventory, architecture, read access to configuration, and owner interviews | Authorized targets, test identities, safe test data, and rules of engagement |
| Useful evidence | Configuration observations and gaps tied to affected resources | Validated attack paths with prerequisites and impact |
| Important limit | A detected weakness may not have been exploited | A time-limited test does not examine every setting or possible path |
Map the responsibilities you actually control
Managed cloud services do not transfer every security responsibility to the provider. Microsoft’s shared responsibility guidance distinguishes infrastructure, platform, and software services while keeping responsibilities for customer data and identities with the customer. Map your actual service model before assuming that patching, backup, access control, or logging belongs to someone else. [1]
In a fictional SaaS environment, the cloud provider may secure the physical hosts while the product team controls tenant authorization and the platform team controls deployment identities. Reviewing only the network perimeter would leave both application and identity decisions unexplored. Ask who owns each control and which evidence will show that it works.
Agree on safe access and provider rules
For a configuration review, use purpose-built access with the permissions needed for the agreed checks. Decide how exports, secrets, logs, and customer information will be handled. For a pentest, record starting identities, permitted actions, excluded dependencies, a pause contact, and proof-of-impact limits before activity begins. NIST SP 800-115 provides a planning and rules-of-engagement foundation. [2]
Check the current testing policy for each cloud provider and any third-party service in scope. For example, AWS permits testing of listed services under stated conditions, prohibits specified activities, and requires prior approval for testing that includes command-and-control infrastructure. Ownership of an account does not authorize every testing technique or a test against the provider itself. [3]
Combine them when breadth and impact both matter
One useful sequence is inventory and configuration review, correction of obvious exposure, then a focused test of the highest-consequence paths. Another is a narrow pentest first when a release or customer requirement has a defined question. Choose deliberately; a combined engagement still needs a clear allocation of time and coverage.
Ask for separate labels for observed configuration gaps, validated exploitation, and areas not examined. Each finding should name an owner, a practical correction, and the evidence that will demonstrate closure. A clean test report is a result within the agreed scope and time window, not a guarantee that the entire cloud environment is secure.
- Name the business decision and the cloud services in scope.
- Provide a resource inventory and identity/data-flow diagram.
- Confirm the provider policy and every required authorization.
- Agree on evidence, remediation ownership, and verification criteria.
See what useful reporting looks like. Our illustrative sample pentest report shows scope, evidence, risk, remediation, and verification using a fictional environment.