Penetration Testing Rules of Engagement: A Practical Checklist

A penetration testing rules of engagement document tells a tester exactly what they can attack, when, and who to ring if it goes wrong. If your provider hasn’t put one in front of you before testing starts, that’s a warning sign, not a shortcut worth taking.

This guide answers the practical questions IT managers and business owners actually ask when a rules of engagement lands on their desk for the first time. What needs to be in it. Who needs to sign it. What happens if it’s missing something.

What is a penetration testing rules of engagement document, in plain terms?

Think of it as the contract for the test itself, separate from the commercial contract. It answers four questions before anyone touches a keyboard: what is being tested, when, how hard, and who to call if something breaks. Providers sometimes call it an RoE for short.

It is not the same as the statement of work. The statement of work is about price, timeline and deliverables. The rules of engagement is about permission and boundaries once testing is under way.

Why you can’t skip it

Under Section 1 of the Computer Misuse Act 1990, gaining unauthorised access to a computer system is a criminal offence in the UK. The act does not carve out an exception for security testing. What makes a penetration test lawful is that the access was authorised, and the rules of engagement is the record that proves it.

Skip it, or leave it vague, and you’ve left both your organisation and your tester exposed. This isn’t hypothetical. In the US, two contracted penetration testers were arrested and jailed in 2019. They had tested a courthouse outside the location their client believed had been agreed. The case later settled for $600,000. It rested on US trespass law, not the Computer Misuse Act. But the lesson still applies here too: when the boundaries of a test are unclear, the people doing the work carry the risk.

The checklist: what a proper rules of engagement covers

According to guidance from the National Cyber Security Centre, a well-scoped test needs these agreed and written down before it starts.

1. Named scope. Specific IP ranges, domains, applications or sites, not a vague description like “the network”.
2. Named exclusions. Anything that must not be touched, such as production databases, medical devices or third-party systems you don’t control.
3. Testing window. Exact dates, hours and time zone, and whether testing can happen during business hours.
4. Permitted techniques. Whether denial-of-service style testing is in or out, and any systems that need extra care.
5. Emergency contacts. Named people, not a generic inbox, who can be reached quickly if testing needs to pause.
6. Data handling. What happens to sensitive data the tester finds, and how it lines up with your data protection duties.
7. Reporting cadence. How often you hear from the tester and what the final report will contain.

If a proposal is missing more than one or two of these, ask the provider to fill the gaps before you sign anything.

Who needs to be in the room when it’s agreed

NCSC guidance points to three groups. The risk owners, who know what’s genuinely sensitive. The technical staff, who know the real boundaries of your systems. And the testing team itself, who can flag what approach will give a full picture. Leave technical staff out of that conversation and the rules of engagement tends to miss something, because whoever wrote it didn’t know it was there to miss.

Black box, grey box, white box: does it change the document?

Yes, a little. A black box test starts the tester with almost nothing. The rules of engagement needs to say more here about how far reconnaissance can go before exploitation starts. A white box test hands over credentials or source code up front. The focus shifts to what the tester can do once inside, not how they get there. Grey box sits in between. The core sections stay the same either way, but the level of detail in each one shifts.

Common gaps that cause problems

• A scope described in general terms rather than named systems.
• A testing window agreed verbally on a call but never written down.
• An emergency contact who has since left the business.
• No agreement on what counts as a “critical” finding worth an immediate call.

None of these are dramatic by themselves. Together, they’re exactly the kind of gap that turns into a dispute the moment something unexpected happens mid-test.

What about cloud and third-party systems?

Part of the scope may sit on systems you don’t own outright, such as AWS, Azure or a SaaS platform. The rules of engagement needs to account for that too. Cloud services generally work on a shared responsibility model. Your provider owns some of the security stack, and you own the rest. Testing your own configuration is usually fine. Testing the underlying platform is not. Most cloud providers have their own rules about what testing they’ll permit, and expect to be told in advance.

Before signing off, check whether the systems in scope include anything hosted by a third party. If so, work out whether that party needs to be told, or asked for permission separately. Skip this step and a technically well-run test can still end up on the wrong side of someone else’s terms of service.

A worked example

Say a mid-sized retailer commissions an external network test. Here’s a tight rules of engagement: name the specific public IP ranges in scope. Exclude the payment gateway hosted by a third-party processor. Set testing hours to evenings only, to avoid disrupting online orders. List two named contacts reachable by phone. Specify that any card data encountered gets reported but never stored beyond the engagement. Now compare that with a loose version: “test our external network, weekdays are fine.” One document survives a difficult moment mid-test. The other turns that moment into an argument, because nobody can point to what was actually agreed.

Frequently asked questions

Who actually signs the rules of engagement?

Someone with the authority to authorise testing on the systems involved, usually a senior IT or security lead, not whoever requested the quote. Third-party systems, such as cloud infrastructure, may need separate sign-off from that provider too.

How long does scoping usually take?

A few days for a typical web application or external network test, once the right people are involved. Larger environments, or anything with safety-critical systems, take longer because there’s more to get right.

What if the tester finds something outside the agreed scope?

They stop and raise it with you rather than acting on it. Going outside the agreed boundaries, even out of curiosity, defeats the point of having rules of engagement in the first place.

Is the document legally binding?

Yes, treat it as a contract. It is the evidence that the access granted during the test was authorised, which matters both for your protection and the tester’s.

Does an internal test need one too?

It does, though the content shifts. Internal engagements focus more on network segmentation and privileged accounts, while external ones focus on perimeter systems and public-facing services.

A rules of engagement document is not red tape. It is what keeps a penetration test controlled, lawful and genuinely useful to you. Aardwolf Security walks every client through a clear one before testing starts, in plain English rather than boilerplate. If you’re scoping a penetration test and want a second pair of eyes on the paperwork, get in touch and we’ll go through it together.