Safeguard
Application Security•

Pen Test Rules of Engagement: A One Page Template

The rules of engagement authorize the tester and protect you. A one page template built from the PCI SSC guidance and the AWS and Microsoft testing policies.

Safeguard Security Team
Updated 3 min read

As of 18 October 2026, AWS's penetration testing policy still lists request flooding, simulated denial of service and subdomain takeover as prohibited, and requires prior approval for any test that includes command and control. A tester who does not know that is working outside the provider's rules. The rules of engagement exist to prevent exactly that.

What's affected

Anyone signing a penetration test statement of work. The PCI Security Standards Council's guidance says to document, before testing starts, the conditions of testing and the degree of exploitation allowed, because this authorizes the tester and sets expectations for the organization.

Three provider rules matter if you host in the cloud:

  • AWS prohibits DoS and DDoS including simulated versions, port, protocol and request flooding (for example login or API request flooding), S3 bucket takeover and subdomain takeover.
  • Microsoft prohibits DoS testing and phishing or social engineering, and says that if you accidentally reach data you have no rights to, you stop, notify MSRC, delete the data and disclose it in your report.
  • Google Cloud says you do not need to contact it first, but tests must follow its acceptable use policy and affect only your own projects.

What to do now

Put these fields on one page and have both sides sign it before the first request is sent:

Window:        Tue to Thu, 09:00 to 17:00 UTC, no testing outside it
Source IPs:    tester provides all addresses before day one
Environment:   staging mirror of production; production only for read checks
Allowed:       authenticated testing, exploitation to proof of concept
Forbidden:     denial of service, request flooding, social engineering,
               testing third party services, data export beyond proof
Legacy:        billing-worker is fragile; no automated scanning against it
Data handling: no retention of customer data; screenshots redact values
Stop rule:     any outage, any real customer data exposure, any sign of
               a prior compromise: stop and phone the emergency contact
Contacts:      security lead (mobile), engineering on call, tester lead
Updates:       daily summary by 17:30 UTC; critical findings same day
Cleanup:       tester lists every account, file and record created

Each line maps to a PCI guidance consideration: time window, legacy systems with known scanning issues, communication method, whether sensitive data found must be disclosed or retained, tester source addresses, and what happens if the tester detects a previous or active compromise (activate incident response and pause the test).

How to avoid this trap

  • Ask your hosting provider's policy page what needs approval before you accept a tester's standard template.
  • Tell the tester about fragile systems in writing. Silent fragility is how a test becomes an outage.
  • Decide in advance whether your monitoring should alert on the test. Both answers are valid, but pick one.

Quick check

Who must approve a cloud penetration test?

It depends on the provider and the activity. AWS permits testing of listed services without approval but requires approval for command and control, and a Simulated Events form for red team style work. Always read the current policy page.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.