Write rules of engagement that prevent surprises
Turn an approved security review scope into operating rules for timing, rate limits, escalation, evidence, and changes during the test.
Rules of engagement explain how an authorized security test will run. Scope identifies what is included. Authorization establishes permission. Operating rules control the work once it begins: when requests may run, what load is acceptable, who can stop the test, and how changes are approved.
Keep these rules close to the test plan. A contract that nobody can consult during an incident does not help the person deciding whether to continue a failing request. The following is a suggested operational structure, informed by the review framework in the OWASP Web Security Testing Guide.
Which rules need an explicit answer?
| Decision | Record before the start |
|---|---|
| Test window | Dates, timezone, and prohibited periods |
| Traffic bounds | Agreed request rate, concurrency, and retry behavior |
| Identity | Source addresses and dedicated test account labels |
| Availability | Health signal, threshold, and escalation contact |
| Mutations | Allowed changes and the reset procedure |
| External effects | Email, SMS, billing, and vendor calls that must not occur |
| Evidence | Approved capture, transfer, and storage rules |
| Scope change | Who can approve it and where that decision is recorded |
Do not copy a generic traffic limit into a fragile system. Choose bounds with the system owner. A low request count can still trigger expensive exports, background jobs, or paid integrations.
How do you handle an unexpected behavior?
Define a pause procedure before the test. The reviewer stops the affected activity, saves minimal safe evidence, and contacts the named owner. The owner evaluates the system state and the proposed next step. Work resumes only after the conditions for resumption are satisfied.
Distinguish a temporary technical failure from a policy decision. A network timeout may permit a bounded retry under the rules. A scope denial does not. A new hostname discovered during a test is not automatically an approved destination.
Record approvals with enough detail to reconstruct the decision. Include the changed action, affected asset, reviewer, owner, and time. Avoid a generic “looks good” detached from the plan it approved.
How do you close the engagement?
Confirm that test jobs have stopped, temporary accounts are disabled, and created records are removed or retained by agreement. Review any unresolved availability or data-handling event before calling the work complete.
The final report should state deviations from the plan, not quietly absorb them into a successful outcome. If testing was blocked, state which conclusions could not be reached. Bring your review priorities to Sourced to define a practical scope and operating plan before testing begins.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.