Penetration test rules of engagement
Every penetration test needs a written authorisation before anyone touches anything. In Canada that document does double duty: it is what keeps testing lawful under the Criminal Code, and it is the artifact you produce when a cloud provider, a landlord or your own security team asks who authorised this.
The rules of engagement is a short document, normally two to four pages, that names what may be tested, from where, by whom, during which hours, using which techniques, and who to call when something breaks. It is signed by somebody at your organisation with the authority to authorise it. Without it a penetration test is unauthorised access to a computer system, and the firm will not start. Firms that offer to start without one are telling you something about how they work.
2 to 4 pages A rules of engagement document that is actually read
Before day one When it must be signed, not during
24/7 Reachability the escalation contact needs
Who has to sign it, and why it is not you
The signatory must be able to authorise testing of every asset in scope. For your own production application on your own cloud account, that is normally a CTO, a VP of Engineering or a CISO. It stops being simple the moment the scope touches something you do not own outright.
| What is in scope | Whose authorisation you need | Lead time |
|---|---|---|
| Your application on your own cloud account | Your own executive signatory | Days |
| A SaaS product you subscribe to | The vendor's, in writing. Usually refused | Weeks, if ever |
| Shared or managed infrastructure | Your hosting provider or MSP | 1 to 3 weeks |
| An office you lease | The building owner or property manager, for anything past your own suite | 2 to 6 weeks |
| Staff, for phishing or pretexting | Your own executive, plus a privacy and HR review | 1 to 3 weeks |
| A subsidiary or an acquired company | A signatory in that entity, not just the parent | Days to weeks |
The lead times in that table are the reason this document is discussed during scoping rather than during testing. A physical engagement blocked on a landlord's consent is the most common cause of a test slipping a month, covered on physical penetration testing.
What belongs in the document
- Scope, as addresses and identifiers. Hostnames, IP ranges with CIDR notation, cloud account or subscription identifiers, application URLs, mobile package names, wireless SSIDs. Not "the production environment", which is a description rather than a scope. Building it properly is on how to write a penetration test scope.
- Out of scope, stated positively. Everything not listed as in scope is out, and then name the traps explicitly anyway: shared infrastructure, third-party integrations, anything belonging to another tenant.
- Testing window. Dates and hours, in a named timezone. "Eastern" is ambiguous twice a year; write the offset or the observance rule.
- Source addresses. The IP addresses the testing will come from, so your team can tell an engagement from an incident. Ask for these before the test, not after somebody pages the on-call.
- Prohibited techniques. Denial of service, destructive testing, social engineering, physical entry, and anything touching production customer data are each in or out by name.
- Escalation contacts. Two named people on each side with phone numbers, reachable outside business hours for the duration.
- Handling of discovered data. What the tester does on finding real personal information or credentials, how it is stored, and when it is destroyed. This is the clause that matters most in Canada and it is covered on data residency during a penetration test.
- Evidence and report handling. Encryption at rest, retention period, deletion date, and who may receive a copy.
- The stop condition. One sentence naming what causes testing to halt immediately, normally the discovery of an active compromise or an unrelated outage.
The clause almost every template omits
If the tester finds evidence that somebody else is already inside, testing stops and you are told immediately. Write down who is told, how, and how quickly. Without it a tester who stumbles onto a live intrusion is in an awkward position, and the awkwardness costs you hours at the worst possible moment. Add it. It costs nothing.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Cloud providers have their own rules, and they win
Testing anything running on AWS, Azure or Google Cloud is governed by the provider's own customer support policy in addition to your document. You are permitted to test your own resources, and you are not permitted to test the provider's shared infrastructure or another tenant, ever, regardless of what your rules of engagement say. Denial-of-service simulation and network stress testing are the categories that still need the provider's prior approval.
Read the current version of the provider's policy during scoping, then put the link and the date you read it into the document. Terms have changed before, and a copy pasted from a three-year-old blog post is not a defence. Which services are covered and what the boundaries are for each provider is on cloud penetration testing, and the control-plane version of the same question is on Kubernetes penetration testing.
The Canadian legal frame
Section 342.1 of the Criminal Code makes unauthorised use of a computer an offence, and section 430(1.1) covers mischief in relation to computer data. The authorisation in your rules of engagement is what puts the testing outside those provisions. That is the entire legal function of the document, and it is why the signatory's authority matters more than their seniority.
Privacy law arrives separately. If testing will expose personal information, PIPEDA's safeguarding requirement applies to how that information is handled during the engagement, and a breach involving real personal information that creates a real risk of significant harm is reportable to the Office of the Privacy Commissioner of Canada regardless of your having commissioned the work. In Quebec, Law 25 adds its own confidentiality incident obligations and, for public bodies and many organisations, an assessment before personal information is transferred outside Quebec.
Non-production data is the cheap answer here
Most of this section stops applying if the test runs against a mirror seeded with synthetic data. It is not always possible: a staging environment that differs from production produces findings about staging. Where you can arrange it, it removes a whole class of privacy obligation for the price of a data-seeding script. Ask during scoping rather than assuming production is the only option.
Clauses to refuse
| Clause | Why it is a problem | What to ask for instead |
|---|---|---|
| The firm owns the report and you hold a licence to view it | You cannot give it to the customer who asked for it | You own the report, with the right to share it under NDA |
| Findings may be used in marketing, anonymised | Anonymised findings from a named vertical are not anonymous | Strike it, or require written approval per use |
| Testing may occur at any time during the period | You cannot staff an escalation contact for six weeks | Named dates, or 48 hours notice of the start |
| Evidence retained indefinitely for quality purposes | Your credentials and data sit on their storage forever | A stated retention period, normally 12 months, then deletion |
| No liability for outages caused by testing | Removes any incentive to be careful | Liability capped at fees, with carve-outs for gross negligence |
| Subcontractors may be used at the firm's discretion | You do not know who is on your network | Named testers, or approval rights over substitution |
Press on the last row. Subcontracting is common and not inherently bad. You want to know it is happening, and the same background-check and residency assurances to apply to the subcontractor. Asking the question is on questions to ask a penetration testing vendor.
When a lighter document is the right call
Not every engagement needs the full treatment. A short, unauthenticated external scan of six hosts you own outright, run inside business hours, with no personal information anywhere near it, does not need a four-page instrument and a landlord's consent. A one-page authorisation naming the ranges, the window, the source addresses and one phone number is proportionate, and insisting on more is procurement theatre that delays a useful piece of work.
The threshold is roughly this: the document grows when the scope touches something you do not own, when real personal information is in play, when techniques could cause an outage, or when somebody other than your own team could mistake the test for an attack. If none of those are true, keep it short.
Get the scope and the rules written once
The scoping questionnaire produces a document you can send to several firms, so the quotes describe the same engagement.
Build a scope documentCommon questions
What is a rules of engagement document in penetration testing?
It is the written authorisation for the test. It names the systems in scope, the testing window and timezone, the source IP addresses, the prohibited techniques, the escalation contacts, and how discovered data and evidence are handled. It is signed before testing starts by someone with authority over every asset in scope, and it is what makes the testing lawful.
Who signs the rules of engagement?
Someone in your organisation who can authorise testing of everything listed, typically a CTO, VP of Engineering or CISO. If the scope includes a leased building, a managed hosting environment or a subsidiary, you need the corresponding authorisation from that party as well, and those take one to six weeks to obtain. Start them during scoping.
Do we need permission from AWS or Azure to run a pentest?
Not for testing your own resources under the major providers' current customer support policies. You do need prior approval for denial-of-service simulation and network stress testing, and you may never test the provider's shared infrastructure or another tenant. Read the provider's policy during scoping and record the link and date in your document.
Can we test a SaaS product we pay for?
Only with that vendor's written permission, which is usually refused, and their terms of service almost certainly prohibit it. What you can do is ask for their own most recent test report or attestation letter under NDA, which is the artifact your auditor wants anyway. The difference between the two documents is on report against attestation letter.
What happens if the test causes an outage?
The escalation contact is called and testing pauses. That is the whole purpose of naming a reachable human. Denial-of-service testing is excluded by default in almost every engagement, so the realistic risk is an old and fragile device that falls over when scanned rather than a deliberate attack. Naming those devices during scoping is cheaper than discovering them at 2am.
Is a rules of engagement document the same as the statement of work?
No, and both should exist. The statement of work is commercial: fees, deliverables, timelines, payment terms. The rules of engagement is operational and legal: what may be attacked, how, when, and by whom. Firms sometimes fold one into the other, which is acceptable as long as every clause above appears somewhere and is signed before testing begins.