Home / Knowledge hub / Rules of engagement
Knowledge hub
Rules of engagement
The agreed limits, times and contacts that govern how a security test is run.
What it means
Rules of engagement are the agreed terms for how a security test will be carried out. They cover when testing may happen, which techniques are allowed, how much load is acceptable, who to contact if something breaks, and how found data must be handled. They are usually written down and signed before testing starts.
NIST's testing guidance treats them as part of planning a test. They sit beside the scope: scope says what is in range, and rules say how the tester must behave inside it. Together they make a test controlled, predictable and defensible.
Why it matters
A test touches live systems, and live systems can be fragile. Without rules, an enthusiastic test could fill a database with junk, lock real users out, or trigger your monitoring at three in the morning with nobody told. The rules keep the test useful without being harmful. Clear rules let everyone relax: the tester can work with confidence and your operations team is not surprised.
They also give both sides legal clarity. Written permission shows the activity was authorised. Clear stop conditions mean a tester halts if they see real personal data or a system degrading. See also test scope. Record every approval, so you can show later what was agreed.
How it shows up
A sensible document lists testing windows, allowed and forbidden actions such as denial of service or social engineering, rate limits, test accounts, what to do on finding live customer data, a named contact on each side with a phone number, and how findings are shared securely.
Mistakes: no emergency contact, rules not shared with the operations team so a test looks like a real incident, and no agreement on whether to test exploits that change data. Agree these ahead, keep them next to the scope, and record changes. Pairs with incident response contacts.
Questions people ask
Rules of engagement, answered
Are rules of engagement the same as scope?
No. Scope says what may be tested. Rules of engagement say how and when, and what to do when something unexpected happens.
Most engagements keep both in one agreed package.
Who should know a test is happening?
The people who would respond to an alert, usually operations and security, and anyone who owns an affected system. Tell them the window and the source address.
Otherwise a test may be handled as a real attack. Tell them before the first request is sent.
What happens if the tester finds real customer data?
The rules should say to stop, report straight away and avoid copying or keeping it. Handling personal data carelessly during a test creates its own incident.
Agree this before the work starts.
Can rules forbid certain tests?
Yes. Clients often exclude denial of service, social engineering or changes to production data. Say so in writing.
Tests that are excluded should be listed so nobody assumes they were covered.
Do they need to be signed?
Yes, by someone with authority over the systems. A signature turns the document into permission.
Without authority to approve, the test should not start. Keep a copy with the scope.
Related
Terms that sit next to this one
Penetration test scope
The written list of what a pentest may and may not touch.
Penetration test
A time-boxed engagement where skilled people attack your systems by hand.
Incident response
The agreed plan for the hours after something has gone wrong.
PTES
A standard outline of the phases of a penetration test.
Web application penetration testing
A pentest focused on a web app, its APIs and the logic behind them.
Who is told before the test starts?
Testing only means something when the limits are clear. We work inside the scope you set, and each reported finding is one we actually exploited. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.