Skip to main content

Scope, Authorization & Rules of Engagement

In one line: The difference between a penetration tester and a criminal is not skill — it's written authorization and a defined scope, so phase one of every engagement is the paperwork: who said you could test, exactly what, by what methods, when, and what happens when something goes wrong.

This is the lesson that keeps you out of prison

Unauthorized access to a computer system is a serious crime in essentially every jurisdiction (the US Computer Fraud and Abuse Act, the UK Computer Misuse Act, and equivalents worldwide) — regardless of whether you cause harm or even intend to. Good intentions, "I was just checking," and "they should thank me" are not defenses. The single most important professional skill in offensive security is never touching anything you don't have explicit, written permission to touch. This lesson is how that permission is established.

In plain English

Imagine a locksmith hired to test a building's locks. Before touching a single door they get a signed contract saying which building, which doors, what hours, and a phone number to call if an alarm trips. Without that, the exact same actions — picking locks, walking in — are breaking and entering. Offensive security is identical. The skills are dangerous and, used without permission, criminal. So professionals wrap every engagement in documents that answer: Am I allowed to do this? To what, exactly? Using what methods? When? And who do I call if I break something or stumble onto something serious? These aren't bureaucratic annoyances — they're what make the work legal, safe, and trusted. A brilliant exploit on an out-of-scope system is a career-ending mistake; the discipline of scope is the profession.

Authorization: the "get out of jail" document​

Before any technical work, you need explicit, written authorization from someone with the actual authority to grant it. Verbal "sure, go ahead" is worthless and unenforceable. The authorization establishes:

  • Who is authorizing — and that they own or legally control the target. (Testing a system your client merely uses — e.g., their cloud provider or SaaS vendor — may require that vendor's permission too.)
  • What is authorized — the specific scope (below).
  • The legal terms — a contract/statement of work, often with a liability waiver and confidentiality (NDA), because you'll see sensitive data.

This signed authorization is sometimes called the "get out of jail free" letter — the document you can produce to prove the activity was sanctioned. Carry/keep it for the duration; without it, you have no defense.

Terms, defined once
  • Authorization — explicit, written permission from a party legally able to grant it, to perform specific testing.
  • Scope — the precise set of in-bounds targets (and explicitly out-of-bounds ones).
  • Rules of Engagement (RoE) — the operational constraints: allowed methods, timing, intensity, handling of findings, and contacts.
  • Statement of Work (SoW) — the contract defining deliverables, timeline, and terms.
  • Scope creep — drifting beyond authorized targets, often by following a connection into an out-of-scope system. A serious breach of trust (and possibly law).
  • Safe harbor — a clause (common in bug bounties) promising not to pursue legal action against good-faith researchers acting within the published rules.
  • Production vs. non-production — whether you're testing live systems (real users, real data, real risk) or a staging copy.

Scope: exactly what you may touch​

Scope is the explicit list of what's in-bounds — and, critically, what's out. Vague scope is dangerous for everyone; precise scope protects the client and you.

A real scope specifies:

  • Targets — exact domains, URLs, IP ranges/CIDRs, applications, or accounts. "The company" is not a scope; app.example.com and 10.0.5.0/24 are.
  • Exclusions — systems explicitly off-limits (a fragile legacy box, a third-party-hosted service you can't legally test, the CEO's laptop).
  • Depth — are you allowed to exploit and pivot, or only identify vulnerabilities? Can you exfiltrate data to prove impact, or must you stop at proof?
  • Data handling — what you may do if you access real customer/personal data (usually: stop, note it, don't copy it).
Worked example: the connection that leads out of scope

You're testing app.example.com (in scope). You find it connects to a database at an IP that turns out to belong to a third-party analytics provider — not your client, and not in scope. The tempting move is to "follow the thread." Stop. That system isn't your client's to authorize, and testing it is unauthorized access to a different company — a crime, even mid-engagement. The professional move: document the finding ("the app trusts an external provider; here's the exposure"), report it, and do not touch the out-of-scope system. Scope boundaries don't pause because an attack path is interesting. This judgment — knowing when not to proceed — is the mark of a professional.

Rules of Engagement: how, when, and what-if​

If scope is what, Rules of Engagement (RoE) are how. They keep an authorized test from becoming an outage or a panic. Typical RoE cover:

  • Allowed and forbidden methods. Is social engineering (phishing employees) in scope? Physical access? Denial-of-service testing is almost always forbidden (you don't prove availability is fragile by taking production down). Destructive actions are off the table unless explicitly agreed.
  • Timing and intensity. Test windows (e.g., off-peak hours), rate limits to avoid overloading systems, and blackout dates (no testing during the holiday sale).
  • Notification & deconfliction. Who knows the test is happening? In a covert red team, almost no one — so there's a small "trusted agent" group who can confirm "yes, that alarming traffic is our authorized testers, stand down" to prevent a real incident response from spinning up.
  • Emergency contacts & stop conditions. A 24/7 contact, and the agreed triggers to halt immediately — e.g., you crash a production service, or you discover an active, ongoing breach by someone else.
  • Evidence handling. How findings, screenshots, and any accessed data are stored, encrypted, and destroyed afterward.
Highlight: discovering a real, prior breach mid-test

A scenario every tester should pre-plan: during an authorized test you find evidence that a real attacker is already inside. This is a defined stop condition — you immediately pause testing and escalate via the emergency contact, because continuing risks destroying forensic evidence or interfering with a live incident. The RoE should specify this in advance so there's no improvising during a crisis. Knowing the agreed stop conditions before you start is part of being trusted with this access.

The professional ethic​

Beyond the documents, offensive security runs on trust and a few non-negotiable ethics:

  • Stay in scope, always — the discipline above, every minute of the engagement.
  • Do no (unnecessary) harm — prove a vulnerability with the minimum impact. Don't delete data to show you could; a screenshot of a directory listing makes the point.
  • Confidentiality — you'll see secrets, sensitive data, and embarrassing weaknesses. They stay confidential, handled and destroyed per the agreement.
  • Honesty in reporting — report what you actually found, neither inflating severity to look impressive nor hiding a mistake you made.
  • Responsible disclosure — for issues found outside a paid engagement (e.g., in someone's public product), report privately to the owner and give them time to fix before any public discussion; never weaponize or sell it.
Highlight: the whole profession rests on one habit

Permission first, technique second. The most skilled tester in the world is a criminal the moment they act without authorization, and the most junior one is a trusted professional as long as they stay rigorously within written scope. Internalize this before you learn another exploit: your value — and your freedom — depends on the discipline of authorization far more than on any technical trick.

Why it matters​

  • It's the literal legal line. Identical actions are either a paid profession or a felony depending solely on authorization and scope. Nothing in the rest of this chapter is safe to do without this lesson.
  • It's what clients are actually buying. Organizations grant testers extraordinary access. That only works on a foundation of contracts, scope, and trust — the deliverable is impossible without it.
  • It's the most common way careers end. Technical mistakes are recoverable; an out-of-scope "I just wanted to see" is not. The discipline here protects you more than any skill.

Common pitfalls​

Where people commonly trip up
  • Relying on verbal permission. "They said it was fine" is not a defense. Get explicit, written authorization from someone with the authority to grant it.
  • Following an attack path out of scope. An interesting pivot into an unauthorized system is still a crime. Document it and stop at the boundary.
  • Testing systems your client doesn't own. Their SaaS vendor, cloud provider, or a shared service may require that party's authorization too. Confirm ownership.
  • Running DoS or destructive tests without explicit agreement. You don't demonstrate fragility by causing an outage. These are forbidden unless specifically authorized.
  • No plan for stop conditions. Crashing production or finding a real breach mid-test needs a pre-agreed halt-and-escalate procedure, not improvisation.
  • Mishandling accessed data. Copying real customer data "as proof" can itself be a breach. Prove with the minimum, store securely, destroy per the agreement.

Page checkpoint​

Required checkpoint

Did scope & RoE click?

Pass to unlock the Next button below

What's next​

→ Continue to Reconnaissance — with authorization and scope established, the first technical phase: methodically mapping the target's attack surface, passively then actively.

→ Going deeper: the bug-bounty model (with its safe-harbor terms) and the legal/compliance frame appear in Compliance & Risk; the incident-response side of a discovered breach is Incident Response & Forensics.