Rules of engagement and scoping
The contract that turns hacking into a profession: what is in bounds, what is forbidden, who is authorised, and what happens when something goes wrong. Get this right before you touch anything.
On this page
Learning objectives
- Explain why authorisation is what makes offensive security legitimate.
- Define scope precisely and identify what belongs in-scope versus out-of-scope.
- List the elements a solid Rules of Engagement document must cover.
- Describe the professional duties that sit beyond the contract itself.
Every technique in offensive security is, in the wrong context, a crime. The single thing that makes the work legitimate is authorisation: a clear, written agreement defining what you may do, to what, when, and what happens if something breaks. Scoping and Rules of Engagement (RoE) are not paperwork to rush. They are the foundation the entire engagement stands on.
No scope, no test. If it is not authorised in writing, you do not touch it, no matter how interesting it looks.
Scope: the boundary
Scope defines exactly what is, and is not, a valid target. Be precise. Ambiguity is where engagements go wrong.
- In scope: the specific IP ranges, domains, URLs, applications, accounts, or physical locations you are authorised to test.
- Out of scope: anything explicitly forbidden, such as production systems that cannot tolerate disruption, third-party services, sister companies, or particular subnets.
- Asset ownership: confirm the client actually owns or controls every target. Testing infrastructure you do not have authority over (a cloud provider, a SaaS, a shared host) can be illegal even with the client's blessing. Many providers have their own testing policies that must be honoured.
Capture scope as structured records, each target tagged in-scope or out-of-scope with notes and an authorisation role, so the boundary is explicit. The rule to internalise: you respect only the scope you actually wrote down.
Rules of Engagement: the conduct
If scope is what, RoE is how. A solid RoE covers:
- Timing: the testing window. Some clients require after-hours, some forbid it.
- Permitted techniques, and forbidden ones. Common carve-outs: no denial-of-service, no social engineering unless explicitly in scope, no destructive actions, no exfiltration of real data beyond proof-of-access.
- Approval gates: which actions require a human go-ahead before execution, such as credential attacks or anything state-changing.
- Handling sensitive data: what to do if you encounter real PII, credentials, or evidence of a pre-existing breach. Stop, document, notify, do not dig.
- Communications: who to contact, how fast, and the escalation path.
- Emergency stop: the signal that halts testing immediately, and who can give it.
Authorisation: the people
- Who signed? The authoriser must have the authority to permit testing of the assets. A signature from someone who does not own the systems is not protection.
- The "get out of jail" letter: written, signed authorisation the testing team carries, naming the scope, the window, and the authoriser, so that if testing is noticed (a SOC alert, a security guard) there is immediate proof it is sanctioned.
- Points of contact: a technical contact and an emergency contact, reachable for the duration.
The legal and ethical floor
Beyond the contract, professional offensive security carries duties:
- Operate within the law. Computer-misuse, privacy, and data-protection laws apply. "The client asked me to" is not a universal defence, especially for third-party assets.
- Duty of care. Minimise disruption, protect any data you touch, and never expand scope on a whim because something looked tempting.
- Confidentiality. Engagement data (findings, evidence, the client's weaknesses) is highly sensitive. Encrypt it, limit access, and dispose of it per the agreement.
- Honest reporting. Report what you found and what you did not. Do not inflate, do not hide a failed objective.
Where AI helps, and where it must be fenced in
An AI assistant can genuinely speed up the paperwork: drafting a proposal, turning a scope conversation into a structured target list, or checking an RoE draft for missing sections. Treat these as first drafts to be reviewed, not final documents.
What AI must never do is decide scope or authorisation on your behalf. A model does not know which assets your client legally controls, it can misread an ambiguous instruction as permission, and it has no standing to accept legal risk. Encode the boundary as an explicit, human-approved constraint that any tooling is bound to, and keep credential and destructive actions behind an approval gate that a person opens. The safest system is one where the AI can only ever act inside a scope a human wrote down and confirmed.
Related reading
- Engagement types: scope looks different for each.
- The penetration-test lifecycle: where scoping sits in the flow.
Knowledge check
Answer without AI. This is your own recall. 70% to pass.
1.A client asks you to test a system they use but do not own, such as a third-party SaaS. What is the correct stance?
2.You encounter evidence of a pre-existing breach during testing. What does a good RoE tell you to do?
3.What is the purpose of the written authorisation letter the testing team carries?