Scope and fit
Cloud testing can accidentally cross tenant or provider boundaries if the target is described only as a company domain. Scope should identify the actual accounts and allowed methods.
Map accounts and identities
List cloud organizations, subscriptions or projects, regions, roles, test identities, and production dependencies. Exclude unrelated customer environments and provider infrastructure not owned by the organization.
Review provider and customer rules
Confirm acceptable testing methods, rate limits, notification requirements, and any provider-specific restrictions from official documentation and agreements. Written authorization should cover assets and timing.
Test configuration and attack paths
Assess identity trust, public exposure, storage permissions, network routes, secrets, and workload-to-control-plane access. Separate configuration review from active exploitation and define stop conditions before testing.
Decisions and tradeoffs
Use this table as a working review record. Replace assumptions with evidence from the target environment.
| Decision area | Working guidance |
|---|---|
| Map accounts and identities | List cloud organizations, subscriptions or projects, regions, roles, test identities, and production dependencies. Exclude unrelated customer environments and provider infrastructure not owned by the organization. |
| Review provider and customer rules | Confirm acceptable testing methods, rate limits, notification requirements, and any provider-specific restrictions from official documentation and agreements. Written authorization should cover assets and timing. |
| Test configuration and attack paths | Assess identity trust, public exposure, storage permissions, network routes, secrets, and workload-to-control-plane access. Separate configuration review from active exploitation and define stop conditions before testing. |
Implementation questions
What should the team decide about map accounts and identities?
List cloud organizations, subscriptions or projects, regions, roles, test identities, and production dependencies. Exclude unrelated customer environments and provider infrastructure not owned by the organization. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about review provider and customer rules?
Confirm acceptable testing methods, rate limits, notification requirements, and any provider-specific restrictions from official documentation and agreements. Written authorization should cover assets and timing. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about test configuration and attack paths?
Assess identity trust, public exposure, storage permissions, network routes, secrets, and workload-to-control-plane access. Separate configuration review from active exploitation and define stop conditions before testing. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
Plan, build, verify, operate
Map accounts and identities: List cloud organizations, subscriptions or projects, regions, roles, test identities, and production dependencies. Exclude unrelated customer environments and provider infrastructure not owned by the organization. Record the result and the next owner before changing the next boundary.
Review provider and customer rules: Confirm acceptable testing methods, rate limits, notification requirements, and any provider-specific restrictions from official documentation and agreements. Written authorization should cover assets and timing. Record the result and the next owner before changing the next boundary.
Test configuration and attack paths: Assess identity trust, public exposure, storage permissions, network routes, secrets, and workload-to-control-plane access. Separate configuration review from active exploitation and define stop conditions before testing. Record the result and the next owner before changing the next boundary.
Deployment checks
Turn the page into a reviewable handover by assigning each check to a person and retaining its result.
Scope Cloud Security Testing Around Real Control Boundaries: decision 1
Write down the boundary, owner, dependency, and proof required for scope cloud security testing around real control boundaries before implementation begins.
Scope Cloud Security Testing Around Real Control Boundaries: decision 2
Write down the boundary, owner, dependency, and proof required for scope cloud security testing around real control boundaries before implementation begins.
Scope Cloud Security Testing Around Real Control Boundaries: decision 3
Write down the boundary, owner, dependency, and proof required for scope cloud security testing around real control boundaries before implementation begins.
Write a cloud rules of engagement
A cloud penetration-test scope must list the legal entity authorising the work, accounts, projects, regions, tenant and identity boundaries, resources, dates, methods, rate limits, exclusions, contacts, and stop conditions. Include provider-managed services and third-party integrations as boundaries; customer access does not authorise testing provider infrastructure or another tenant.
Separate read-only review from changes or proof-of-concept actions. Any test identity, configuration change, workload launch, privilege validation, secret handling, or data access requires explicit approval and rollback steps. Preserve only minimum evidence, protect account identifiers and logs, and report unexpected exposure through the agreed urgent route.
DeployOpen can test the written scope. The customer owns authorisation, production-risk decisions, and remediation choices; findings describe observations in the stated environment and period.
Handover and ownership
Before handover, name the system owner, support path, access boundary, backup or recovery responsibility, and the condition that pauses a change.
Keep a short record of what was tested, what remains outside scope, and when the review should happen again.
