A Rules of Engagement template for the pentests you sell.

1. The parties

• Provider running the test: legal name, company registration, technical contact email.
• Organisation being tested (the client): legal name, company registration.
• Who authorises: name, job title and email of the person signing for the client.

The person who signs has to hold authority to authorise the test on behalf of the organisation. A technician who operates the system is usually not that person.

Why this clause exists: The authorisation is the only thing separating a security test from an incident. It has to come from someone who can give it, and it has to stay on record with a name, an address and a date.

2. Authorised targets

One per line, written out in full. No abbreviations, and no "and subdomains".

• Domain or host: example.com
• IP address or range: 203.0.113.10
• Application or URL: https://app.example.com

The rule that governs the whole document: what is not on this list is not authorised.

Why this clause exists: "And anything else that belongs to the client" is where the accidents live — a third-party host that merely looks like the client's, a shared hosting IP carrying four other companies. The explicit list is your defence.

3. Out of scope

• Third-party hosts and services — hosting, SaaS, payment providers — that do not belong to the client.
• Any target not listed in clause 2.
• Physical access to premises.
• Social engineering against the client's staff.
• If it applies: production during business hours.

Why this clause exists: A shared IP address is the classic trap: the target resolves to a host that also serves companies who never authorised anything. Naming the exclusion is cheaper than explaining it afterwards.

4. Type and depth of the test

• [ ] Surface discovery — maps what is exposed, without exploiting anything.
• [ ] Unauthenticated test (black box) — no credentials: the view an attacker has from outside.
• [ ] Authenticated test (grey box) — the client provides ordinary user access, and the test shows what an attacker holding that access would reach.
• Controlled exploitation? ( ) No ( ) Yes — authorised only when this line is marked: the test may exploit confirmed flaws to demonstrate the impact a real attacker would have, with no data destroyed, no service deliberately taken down, and nothing left behind, inside the clause 5 window.
• Privilege escalation permitted? ( ) No ( ) Yes.

Why this clause exists: Depth is the difference between "we found a door" and "we went in". Raising it later is new scope, and new scope needs a new signed RoE — not an edit to this one.

5. Testing window

• Start: ____ / ____ / ______ at ____:____ (time zone)
• End: ____ / ____ / ______ at ____:____ (time zone)

Outside this window, nothing runs.

Why this clause exists: Agree the window with whoever operates the system, not only with whoever signs. The person who signs rarely knows that the monthly closing runs on the third business day.

6. Conduct and technical limits

• Maximum request rate: ______ per second.
• Concurrent executions: ______.
• Identification in the logs: part of the traffic carries the label "______".

Be honest about identification. Some stages use varied identifiers, including ones deliberately shaped like an ordinary browser or a known scanning tool, because part of what is being assessed is how the controls react to each of them. Network services — SMB, LDAP, SSH, databases — have no equivalent field at all.

What separates this test from a real incident is not the label on the traffic. It is this authorisation and the window above.

Why this clause exists: Without an agreed rate ceiling, a test can take down a fragile service, and the next conversation is about losses rather than about security.

7. What the test will do

Describe it in the client's language, matching what you actually contracted. A workable baseline:

• Enumerate what is exposed on the listed targets.
• Identify observable technologies, versions and configurations.
• Test for known flaws, with requests that demonstrate the flaw exists.
• Where clause 4 authorises exploitation, demonstrate what a real attacker would reach — the access obtained, the data reachable — and record the minimum evidence needed to prove it.
• Record evidence for every finding, so each one can be reproduced and fixed.

Why this clause exists: A client who does not know what was done cannot tell a finding from an opinion. This clause is what makes the report defensible later.

8. What the test will NOT do

• No attempt at physical access to the premises.
• No social engineering: nobody on the client's team is approached, tested or deceived.
• No backdoor and no malware installed, and nothing left behind beyond what was agreed.
• No real user data taken beyond the minimum needed to demonstrate the flaw.
• No target tested that is not listed in clause 2.

Why this clause exists: Only promise what the engagement actually refrains from. A fixed list of noble-sounding exclusions, printed on an engagement that does the opposite, is the kind of contradiction a client signs without noticing — and discovers at the worst possible moment.

9. Possible impact — read this one out loud with the client

An active test is not passive observation. Say so plainly:

• Some checks send requests that may alter data on the systems being tested — for example, submitting a test value to confirm a business-logic flaw.
• A service running with little headroom may become slow or unavailable during the window.
• Alerts will fire in the client's monitoring and in their SOC. Warn them beforehand, or someone will open an incident on you.

Why this clause exists: This is the conversation nobody wants to have afterwards. Signed beforehand, an incident becomes something that was foreseen.

10. Stop rules and contacts

Stop the test immediately on any of these: a service becomes unavailable, data is lost, a critical finding shows active exposure, or the client asks you to stop.

• Provider technical contact: name, phone, email — reachable throughout the window.
• Client emergency contact: name, phone, email.
• Channel and deadline for reporting a critical finding: ______ (for example: by phone, within 4 hours).

Why this clause exists: A stop rule nobody can execute is decoration. Both contacts have to be reachable during the window — which means a mobile number, not a ticket queue.

11. Evidence and data handling

• Where the evidence is stored, and for how long: ______
• Who can access it: ______
• How it is returned or disposed of at the end: ______

If any part of the processing happens on infrastructure you do not own — analysis, comparison across assessments, anything that leaves your own systems — say it here, and say where. Do not write "no data leaves our environment" if data leaves it.

Why this clause exists: A confidentiality promise your operation does not keep is the promise that catches you in an audit. The clause that protects you is the one that describes what actually happens, including the parts you would rather not mention.

12. Validity and signatures

• This authorisation covers only the targets in clause 2, for the period in clause 5.
• Validity: ______ days from the date of signature.
• A material change — a new target, greater depth, a new window — requires a new signed RoE.

• Client: name, job title, date, signature.
• Provider: name, date, signature.

Why this clause exists: Editing a signed document destroys the only thing it was for. The signature proves consent to a specific text; change the text and you are holding a signature for something nobody agreed to.

Before you send it for signature

• [ ] Every target in clause 2 belongs to the client, and I could prove it if asked.
• [ ] The person signing holds authority to authorise on behalf of the organisation.
• [ ] The signing address belongs to the client's organisation — not my own mailbox, not a technician's personal one.
• [ ] The depth in clause 4 was agreed with the client — and, if exploitation is marked, how far it may go and who authorised it in writing.
• [ ] The window in clause 5 was agreed with whoever operates the system, not only with whoever signs.
• [ ] The client has been told that some checks may alter data (clause 9).
• [ ] The client's monitoring or SOC knows the window.
• [ ] Both sides have an emergency contact who is reachable during the window.
• [ ] The rate ceiling in clause 6 fits what the environment can actually take.
• [ ] Out of scope (clause 3) names every third-party host sharing an address with a target.
• [ ] If the scope changes, I issue a new RoE instead of editing this one.

After it is signed, keep four things

• The signed document itself.
• The date and time of the signature.
• The address of the person who signed.
• An immutable copy of the scope as it read at that moment.

Those four are what answer the question "who authorised this test?" months later, when the person who signed has left the company and the only thing left is your record.

Why this clause exists: The fourth is the one people forget. A signature attached to a scope that has since been edited proves nothing at all.

Subject: Authorisation for the security test — [client name]

[Name],

Before any test runs, I need your authorisation in writing. Attached (or at the link below) are the Rules of Engagement: what will be tested, when, within which limits, what will not be done, and what the possible impact is.

Three points I would like you to read carefully:

• The target list. Only what is on that list will be tested. If something is missing, or if something on it is not yours, tell me before you sign.
• The window. The test runs between [date and time] and [date and time]. Outside that, nothing runs.
• The impact. The test is active: some checks send requests that may alter data — for example, a test value to confirm a logic flaw. A service with little headroom may slow down during the window, and your monitoring will raise alerts.

If you agree, sign [at the link / on the document] and send it back. Nothing starts before that.

Any questions, call me on [phone] — I am available throughout the test window.

[Signature]

How Wardizon enforces it

• The provider assembles the scope in the console and sends the authorisation request. The signing link goes to the approver address the provider names, and the provider warrants that the address belongs to the client.
• The client opens the document — targets, assessment, what will and will not be done, perimeter, conduct, possible impact, data handling, validity — and signs it online. The signing link is valid for 60 minutes.
• The platform requires a signed RoE before it starts a test. There is no path that runs one without it.
• The platform runs only the depth the signed document authorises — including whether exploitation is permitted at all.
• The signed scope is frozen into an immutable snapshot, and that snapshot is what enters the document hash and the signature hash. A material change asks for a new RoE rather than an edit.
• On the paid plans, executions inside each signed RoE are recurring: up to 30 across the 30 days of validity, and at most one per day.
• The report carries the provider's logo, with "Powered by Wardizon", on every plan. Each finding shows the path an attacker would take and the fix that closes it — the report is what the remediation plan is built from.

Why this clause exists: Clause 12 is the one a platform can keep and a PDF cannot. A signature that is bound by hash to a frozen scope cannot be quietly widened afterwards — which is the single failure this whole document is written to prevent.

The data-handling text the client signs

Reproduced as it stands on the signing page today, because clause 11 is only worth as much as its honesty:

"Os achados ficam armazenados na plataforma Wardizon. Quem conduz o teste, a sua organização e, para suporte e auditoria, a Wardizon podem acessá-los. Para conduzir a avaliação, analisar os achados e compará-los entre avaliações, os dados desta avaliação — como alvos, tecnologias detectadas, evidências e achados — são processados na infraestrutura da Wardizon, no Brasil, e na de suboperadores, nos EUA. A lista de suboperadores está disponível sob pedido a quem conduz o teste. Os dados de cada organização são isolados dos das demais, e o acesso à plataforma é feito por conexão protegida (HTTPS)."

Note what it does not say. It does not promise that no data leaves, and it does not promise that no finding is ever shared — because analysis and comparison across assessments do process assessment data on sub-processors. An earlier version of this text did make that promise, and it was removed for being wider than the truth. That is the standard clause 11 asks you to hold yourself to.