Check your cloud provider's current testing policy before you start. Some providers let you test your own resources for permitted services without prior approval, while banning denial of service and a few other activities, and requiring a form for simulated events. You also need written permission from your own organization and any other owner.
Two kinds of permission
- From the provider. Their policy says what you may do on infrastructure they run.
- From the owner of the target. If a third party owns the app, domain or tenant, you need their written authorization. Provider policy does not grant this.
What two major providers say today
Policies change, so treat this as a snapshot from 19 October 2026 and read the live page.
| Point | AWS | Microsoft Azure |
|---|---|---|
| Pre approval for your own resources | Not needed for listed services | Notification is not required |
| Scope limit | Listed services such as EC2, load balancers, RDS, Lambda and others | Your own tenant or assets you are explicitly authorized to test |
| Denial of service, including simulated | Prohibited | Prohibited under all circumstances |
| Other prohibited items | Flooding, DNS zone walking, bucket and subdomain takeover | Touching other tenants, using credentials that are not yours, post exploitation beyond proof of concept |
| Needs a form | Red, blue or purple team exercises, simulated phishing, malware testing | Not described on the page reviewed |
For AWS, requests for simulated events should be made at least two weeks ahead, and the page states a response within two business days.
Steps before a cloud pen test
- Read the provider's current policy and note the date you read it.
- Confirm every target is a service the policy lists.
- Get written permission from your own management and from owners of any shared or third party components.
- Put the policy limits into the rules of engagement. See the pen test rules of engagement template.
- Tell the tester which scanners must have denial of service tests switched off.
- Plan for managed services you do not control, such as a SaaS tool in the path.
- Keep the permission and policy snapshot with your test records.
What this does not cover
Testing a SaaS product you merely use usually needs that vendor's approval, and many publish their own rules. Never test a third party system on the assumption that your cloud account covers it.
Quick check
Can I run a denial of service test in the cloud?
Both providers reviewed prohibit denial of service testing, including simulated versions, under their standard policies. Check for a separate stress testing process.
Does my cloud account let me test a vendor's SaaS app?
No. Cloud provider rules cover your own resources. A third party product needs that vendor's permission.
Safeguard does not test infrastructure you do not own: its dependency scanning works from your repositories and SBOMs, and you can try a free scan.
Sources
Last reviewed: 19 October 2026.
