Rules of engagement for penetration testing

Rules of engagement (often shortened to RoE) are the operating rules for a security test. Some providers combine them with the scope in one document, others keep a separate scope statement or statement of work. Either way, the content is the same: what is allowed, what is not, and how both teams communicate.

The National Institute of Standards and Technology (NIST) guide to security testing, SP 800-115, treats rules of engagement as a core part of planning an assessment, covering items such as authorized targets, testing times, permitted techniques and points of contact.

The techniques used in a penetration test are the same ones a criminal would use. What separates them is permission from someone with the authority to give it. In many countries, accessing a computer system without authorization is an offence, which is why testers insist on written, signed authorization before any activity.

Two details matter in practice:

• The signer must have authority over every system in scope. An engineering lead may not be able to authorize testing of a parent company's network or a vendor-hosted service.
• Third-party systems need their own permission. Your SaaS providers, payment processors and hosting companies own their infrastructure. Their published testing policies, or direct written consent, govern what is allowed there.

The safe window depends on the system. Customer-facing applications are often tested during business hours, when engineers are around to respond if something looks wrong. High-volume or riskier activities may be scheduled for quieter periods. Either way, write the window down with a time zone, and include blackout dates such as launches or end-of-quarter billing runs.

If detection and response are part of what is being tested, the RoE should say who knows the test is happening. A small trusted group (sometimes called a white cell) can confirm an alert is the test without tipping off the defenders being evaluated.

Out-of-scope lists are as important as in-scope lists, because ambiguity is where accidents happen. Common entries:

• Denial of service and load testing, unless explicitly arranged. Major cloud providers, including AWS and Microsoft, prohibit denial of service testing under their standard pentest policies.
• Third-party services you use but do not own, unless their owner has agreed.
• Social engineering, phishing or physical entry, unless specifically requested and authorized.
• Actions that change or delete real customer data.
• Specific fragile systems, such as legacy hardware or a database without a recent backup.

If testers discover a new asset during the engagement, such as an unlisted subdomain, the RoE should say what happens: usually they report it and wait for written approval before testing it.

Stop conditions are pre-agreed triggers that pause testing until both sides talk. They exist so nobody has to make a judgement call under pressure. Typical triggers:

• A system in scope becomes slow, unstable or unavailable.
• Testers find evidence of a real compromise by someone else, such as unknown accounts or web shells.
• Testers gain access to highly sensitive data, such as payment card data, health records or production secrets, beyond what is needed to prove impact.
• Activity appears to be reaching a system outside the scope.
• The client requests a pause for any reason.

Each trigger should name who to call and how fast, using the emergency contacts listed in the document.

Proving a finding sometimes means touching real data. The RoE should limit that to the minimum: retrieve enough to prove access (for example one redacted record), do not bulk download, and never use found credentials outside the agreed scope.

It should also cover where evidence and reports are stored, who can access them, how they are encrypted, and when they are destroyed after the engagement. Reports describe your weaknesses in detail, so they deserve the same care as the data they protect.