Rules of engagement in plain English
In a penetration test, experts attack your systems using the methods of real attackers – but with your permission and under controlled conditions. For that to work, you need clear agreements. That’s exactly what the rules of engagement, or RoE for short, provide.
An everyday comparison: before the fire department holds a large-scale drill at a company, everyone agrees exactly which buildings are involved, when the drill takes place, which areas are off-limits, and who can call off the exercise at any time. Nobody should think there’s a real fire, and operations should be disrupted as little as possible. Rules of engagement do the same for a simulated cyberattack.
They build on the scope, the agreed extent of the test. Put simply, the scope answers the question “What will be tested?” The rules of engagement also answer the question “How will it be tested?”
How rules of engagement work
The rules are drawn up jointly before testing begins and recorded in writing. Typical contents include:
- Target systems and exclusions: Which applications, IP address ranges, or locations will be tested – and which explicitly won’t, such as systems run by service providers.
- Time frame and testing windows: On which days and at what times testing takes place – for example, at night for particularly sensitive systems, or not during month-end closing.
- Permitted and prohibited techniques: Whether social engineering – deliberately deceiving people – is allowed, whether vulnerabilities may be actively exploited, and which risky attacks are off-limits, such as denial-of-service attacks designed to overload systems.
- Contacts and escalation paths: Who can be reached on both sides, and who is notified immediately if the testing team finds a critical vulnerability or a system becomes unstable.
- Abort criteria: The circumstances under which the test is paused or stopped.
- Data handling: How confidential information the testing team comes across is handled, and when it is deleted.
Red teaming – a covert, simulated attack over an extended period – adds a special twist: only a small circle of insiders, known as the white team, knows about the exercise. In this case, the rules of engagement also specify how this group tells a real incident apart from the exercise.
A practical example
Here’s a typical scenario: A logistics company has its internal network tested. The rules of engagement specify that testing will take place on five business days, and that the warehouse management system will only be tested at night, when hardly any goods are being booked in or out. Denial-of-service attacks are excluded, and the IT manager can be reached by phone throughout the test.
On the second day of testing, the testing team discovers a script on a file share that contains the password for an administrator account. As agreed, the team calls the IT manager right away. The password is changed that same day – long before the final report is available.
Why does this matter for businesses?
Attacking someone else’s IT systems without permission can be a criminal offense. German criminal law, for example, makes it a crime to gain unauthorized access to specially protected data (§ 202a StGB, German Criminal Code). Only the consent of an authorized person – in practice, a written engagement – turns the attack into a permitted test. The rules of engagement document what this permission covers.
That way, they protect both sides: your company, because sensitive systems are handled with care and critical periods are avoided – and the testing team, because it’s clear what they’re allowed to do. They prevent misunderstandings, for example when your IT service provider mistakes a test for a real attack. And they ensure that the test answers exactly the questions that matter to you.
What to look out for
- In writing and in advance: Have the agreement signed by an authorized signatory before testing begins.
- Clarify responsibilities: If systems are operated by a hosting provider, in the cloud, or by an IT service provider, find out whether their consent is required.
- Ensure availability: Name contacts, with deputies, who can be reached throughout the entire testing period.
- Flag sensitive systems: Point out systems that might react sensitively, as well as times when no testing may take place.
- Decide who’s in the know: Make a deliberate decision about who knows about the test – usually IT operations for a pentest, only a small circle for red teaming.
- Record changes: If targets or the time frame change, update the agreement in writing.
How Rootsektor can help
Whether it’s a penetration test or Red Teaming & APT Simulation, we draw up the ground rules together with you and put them in writing. You’ll have a dedicated contact person at Rootsektor, and we report critical vulnerabilities immediately – during the test, by phone or email to the agreed contact person. On request, we sign a non-disclosure agreement in advance. After scoping, you’ll receive a fixed-price quote – you can request it via our Pentest Quote page.