Rules of Engagement

1. Parties and authorisation

This document is between [CLIENT LEGAL NAME] ("the Client") and [TESTER NAME] ("the Tester"), and covers security testing performed between the dates set out in section 3.

The Client confirms it owns the systems listed in section 2, or holds written authorisation from their owner to permit testing. The Tester is entitled to rely on that confirmation and will stop immediately if it turns out to be wrong.

Where systems are hosted by a third party whose terms require notification or consent before testing — cloud providers, managed hosting, SaaS platforms — obtaining that consent is the Client's responsibility, and testing of those systems will not begin until the Client confirms it is in place.

2. Scope

In scope. Only the following are authorised for testing. Anything not listed here is out of scope, including systems discovered during testing that appear to belong to the Client.

• ▸[DOMAIN / APPLICATION URL] — [description, environment: production or staging]
• ▸[API BASE URL] — [description]
• ▸[IP RANGE, in CIDR] — [description]
• ▸Test accounts: [ROLE] / [ROLE] — supplied by the Client before the window opens

3. Out of scope

The following are explicitly excluded and will not be tested under this agreement:

• ▸Denial-of-service and resource-exhaustion testing of any kind
• ▸Social engineering of Client staff, including phishing and pretexting, unless separately agreed in writing
• ▸Physical access and physical security controls
• ▸Third-party services the Client does not own, even where they are reachable from an in-scope host
• ▸Any host or domain not named in section 2
• ▸[ADD ANY CLIENT-SPECIFIC EXCLUSIONS: payment processor, production database, particular business hours]

4. Testing window

Testing will take place between [START DATE, TIME, TIMEZONE] and [END DATE, TIME, TIMEZONE].

Automated traffic will be limited to [RATE] requests per second against any single host. If the Client requires testing to be confined to particular hours, those are: [HOURS].

Testing will originate from the following addresses, so the Client can allowlist or attribute traffic: [SOURCE IPs].

5. Permitted and prohibited techniques

Permitted: reconnaissance, enumeration, authentication and authorisation testing, injection testing, business-logic testing, and manual exploitation to the minimum extent needed to demonstrate impact.

Prohibited without separate written agreement: any action intended to degrade availability; modification or deletion of Client data; installation of persistence; pivoting to systems outside section 2; and extraction of production data at volume.

Where proving a finding would require extracting data at scale, the Tester will stop at the point the issue is demonstrated and describe the remaining path rather than walking it.

6. Contacts and escalation

Client technical contact: [NAME, PHONE, EMAIL]. Available during the testing window.

Client escalation contact: [NAME, PHONE, EMAIL]. For anything urgent outside working hours.

Tester: [NAME, PHONE, EMAIL].

Both parties confirm these contacts are reachable during the window. An engagement where nobody answers the phone at 9pm is an engagement where a mistake becomes an incident.

7. Critical findings and incidents

On discovering a finding assessed as critical — remote code execution, authentication bypass, or exposure of personal data at scale — the Tester will stop testing that component and notify the Client's technical contact within [2] hours rather than waiting for the report.

On discovering evidence of a prior or ongoing compromise by a third party, the Tester will notify the Client immediately, preserve what has already been observed, and take no further action on that system without instruction.

If testing appears to have caused an outage, data loss, or any unintended change, the Tester will notify the Client immediately — before establishing whether the Tester was in fact the cause.

8. Evidence and data handling

Evidence will be limited to what is needed to prove a finding exists and allow the Client's engineers to reproduce it. Where a finding exposes personal data, the minimum will be recorded, with identifying fields masked at the point of capture.

Evidence is stored encrypted on hardware controlled by the Tester, is not processed by any third-party service including AI tools, and is deleted [30] days after the retest concludes or immediately on the Client's request.

Credentials issued for testing are stored in a password manager, are never committed to a repository or reused across engagements, and are to be revoked by the Client at the end of the engagement.

9. Deliverables

The Client will receive a written report containing: an executive summary in business terms; an explicit statement of what was not tested and why; findings ranked by assessed impact with reproduction steps sufficient for the Client's own engineers to verify each one; remediation guidance; and a record of controls found to be working.

Delivery: within [5] working days of the testing window closing.

One retest of the reported findings is included, to be used within [90] days of delivery. A finding is closed when the original reproduction steps no longer work, not when a fix is deployed.

10. Confidentiality and disclosure

Findings are the Client's. The Tester will not publish, present, or otherwise disclose them — including in anonymised form — without the Client's written permission.

Where testing discovers a vulnerability in third-party software rather than in the Client's own systems, the Tester may wish to report it to that vendor. This will be raised with the Client first, and any such report will describe the flaw without identifying the Client.

11. Acceptance

Both parties agree to the scope, window, exclusions and contacts set out above. Changes to scope must be agreed in writing before the affected testing begins.

Client: [NAME] Role: [ROLE] Signature: ____________________ Date: __________

Tester: [NAME] Signature: ____________________ Date: __________