Direct answer
Scope a cloud assessment by account, service, region, identity and data boundary, then agree the evidence and testing permissions for each. Customer and provider responsibilities vary by service, so verify the relevant provider rules before testing.
Map accounts and ownership
List the cloud organizations, subscriptions or projects, accounts, regions and environments to review. Identify the owner of each and the services that hold sensitive data or expose interfaces to other networks.
Document the intended boundaries: production versus test, internet-facing versus internal, and the systems that are operated by a separate provider or customer. Establish a contact who can approve access and coordinate changes.
Reference: AWS shared responsibility model.
Select controls and evidence
Choose the review objectives for the actual services in scope. Typical areas include identity and role permissions, public storage exposure, network access, logging, secret handling and configuration drift. Document which resources and identities will be sampled and which require full inventory.
Provide an appropriately limited assessment identity and agree how permissions will be granted and revoked. A read-only configuration review and an active penetration test answer different questions; specify whether each is authorized and what evidence is needed.
Check provider rules and shared responsibility
Provider testing policies and customer responsibilities differ across services and can change. AWS, for example, publishes a list of permitted services and restrictions for security testing; verify the current policy and resolve any questions with the provider before starting.
For a managed service, the provider may operate some layers while the customer controls configuration, identities or data. Map that boundary for each selected service instead of assuming the same division applies to every workload.
- Identify the provider, service and region for each target.
- Check current permitted activities and any approval requirements.
- Obtain customer and third-party authorization for every included environment.
Reference: AWS penetration testing policy.
Agree on safe handling and retest
Use non-production fixtures where practical and avoid copying sensitive records into evidence. Agree on excluded actions, rate limits, a stop procedure and incident contacts. Logs and inventory exports may reveal secrets or personal data, so set access and retention rules before collecting them.
For each finding, record the resource and identity involved, observed configuration, intended policy, business impact and recommended change. Recheck the affected resource and legitimate access after the owner applies a fix.
Reference: NIST SP 800-115: Technical Guide to Information Security Testing and Assessment.
Assessment limits
A limited-permission or sampled review can miss accounts, regions, temporary resources and policy interactions. Provider rules and service capabilities change; scope and current policy must be verified for the specific environment. An assessment does not establish certification or compliance by itself.
Frequently asked questions
Is a cloud configuration review the same as a penetration test?
No. A configuration review inspects selected settings and permissions; a penetration test exercises agreed attack paths. An engagement may include both when explicitly authorized.
Does a read-only identity see every cloud risk?
No. Its visibility depends on permissions, included accounts and services. Record denied access and gaps in the coverage.
Can a customer test the cloud provider's infrastructure?
Customer authorization does not automatically authorize testing the provider's own infrastructure. Follow the provider's current policy and obtain any required approvals.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.
This guide was prepared with AI assistance using the linked sources and illustrative examples. Check current vendor guidance and your environment before making changes.