Engagement Types & Rules of Engagement

You already picked an adversary to impersonate. That decision is real, but it is not yet legal. Choosing to act like a nation-state actor or an organized-crime crew does not, by itself, give you any right to attack the client's systems — and the techniques you are about to use are, in every other context, exactly the crimes those adversaries commit. What separates a paid engagement from a prosecution is not skill, tooling, or intent. It is authorization, in writing, agreed before the work starts.

So the work of this phase is translation: take the abstract "we will simulate this attacker" and turn it into a concrete, bounded agreement. That agreement answers four questions before any packet leaves your machine — how much will the tester be told (the knowledge level), where does the attack originate (the test type), what exactly is allowed and forbidden (the rules of engagement), and who is authorizing it (the authorization letter). Get those four right and the engagement is defensible. Get them wrong, or skip them, and even a perfectly executed test becomes a liability for everyone who touched it.

The first dial on the contract controls how much the client hands over before you begin. More knowledge means a faster, more thorough test; less knowledge means a more realistic simulation of an outside attacker who has to discover everything for themselves. The three standard settings trade realism against thoroughness against time and cost.

There is no "best" setting in the abstract — only the right setting for the goal. If the client wants to know how they'd fare against an unknown attacker on the internet, lean black box. If they want maximum assurance that a critical application is sound, lean white box and hand the testers the source. Grey box is the workhorse of the industry precisely because it captures most of the realism of a blind test while spending the budget on findings instead of guesswork.

The second dial sets the attacker's vantage point. The same target looks very different depending on whether you start outside the fence or already inside it, and most contracts specify one, the other, or a deliberate progression from one to the next.

• External — the attack originates from the public internet and targets the organization's perimeter: public-facing websites, VPN and mail gateways, exposed services, and anything else reachable from outside. It answers the question every executive asks first: "what can someone on the internet do to us right now?"
• Internal — the test assumes a foothold already exists and starts from inside the network. It models a malicious insider, or, just as often, an outside attacker who already phished an employee or compromised a single laptop. The question shifts from "can they get in?" to "once they are in, how far can they go, and how fast?"

The distinction matters because perimeter defenses and internal defenses fail in different ways. A hardened external surface tells you nothing about whether the inside is soft — and the inside is very often soft, because organizations have historically spent on the wall and trusted everything behind it. An internal test exposes the flat networks, over-privileged accounts, and unmonitored lateral paths that an attacker rides once the perimeter is breached.

The knowledge level and test type are settings inside a larger agreement. That agreement is the Rules of Engagement (ROE) — the document that defines, in detail, what the testers may and may not do. It is the heart of the engagement: the place where good intentions become enforceable boundaries, and the reference everyone returns to the moment something is unclear or goes wrong. A well-written ROE pins down:

• Exact scope — the precise IP ranges, domains, hostnames, and applications that are in bounds, paired with an explicit, written out-of-scope list. The out-of-scope list is not an afterthought; it is what keeps you off the shared cloud tenant, the third-party payment processor, or the production database you assumed was fair game. If an asset isn't named in scope, treat it as forbidden.
• Timing windows — when testing is permitted. Some clients want testing only after hours to protect business-critical systems; others want it during the day so their defenders can practice responding. Either way, the window is agreed in advance so nobody mistakes the test for a real incident at 3 a.m.
• Permitted techniques and explicit prohibitions — what is on the table and, just as important, what is off it. Common carve-outs: no denial-of-service against production, no social engineering unless specifically authorized, and no physical intrusion. The prohibitions protect the client from collateral damage and protect the tester from blame for things they were told not to touch.
• Handling of discovered sensitive data — what happens when you stumble onto real customer records, credentials, or regulated data. The ROE says whether you may access it to prove impact, how much you may copy, how it must be stored, and how it gets destroyed afterward. You are there to demonstrate risk, not to exfiltrate the client's crown jewels.
• Emergency and escalation contacts — named people, reachable in real time, on both sides. When you find something actively dangerous, or when a system you touched starts misbehaving, you need to reach a decision-maker immediately, not file a ticket.
• An "if something breaks" plan — the agreed procedure for when a test causes an outage or instability. Who gets called, who can pause or stop the engagement, and how the client and tester recover together without finger-pointing.

Alongside the ROE sits a second document that does one specific legal job: the authorization letter, often called the "get out of jail" letter. It is explicit, written permission from someone with the authority to grant it — a system owner or an executive who can actually speak for the organization, not a friendly contact in IT who lacks the standing. A proper authorization letter names the systems you are permitted to attack, the dates during which the permission is valid, and the testers it covers.

This letter is the tester's legal shield. If a defender, an ISP, or law enforcement ever questions why traffic from your machine is hammering the client's servers, the authorization letter is the document you produce. Carry it — physically or accessible — for the duration of the engagement. Without it, "the client asked me to" is just your word; with it, you have proof that the owner empowered the work.

Working from a written checklist does more than protect you legally. It keeps the engagement orderly: you move through reconnaissance, scanning, exploitation, and reporting in a deliberate sequence instead of improvising, and at every step you can check the target against the in-scope list before you act. This is how professionals avoid the two classic mistakes — drifting out of scope, and skipping a phase under time pressure.

You do not have to invent these checklists from scratch. Mature, community-maintained pentest checklists circulate publicly — for example, external-penetration-test checklists hosted on code-sharing platforms like GitHub — precisely so practitioners can adopt a proven, step-by-step structure and adapt it to each engagement. Borrowing a battle-tested checklist is not a shortcut; it is how seasoned testers make sure nothing important, especially the authorization step, ever gets skipped.

Everything in this lesson exists to make one thing true before you start: the engagement is legal, bounded, and agreed. The adversary you chose in the last lesson tells you how to behave; the contract you build in this one tells you what you are allowed to do while behaving that way. They are two halves of the same setup, and skipping the second half doesn't make you bold — it makes you a criminal with good intentions.

Carry these forward into the rest of the phase:

• Set the two dials on purpose. Decide the knowledge level (black, grey, or white box) and the test type (external, internal, or external-to-internal) deliberately, because together they shape realism, coverage, and cost.
• Treat the ROE as binding. Scope, timing, permitted techniques, data handling, and escalation contacts are not paperwork — they are the walls you operate inside. If it isn't in scope, it's off-limits.
• Get the signatures before the scan. The signed ROE and the authorization letter are what make the work defensible. Put them first on the checklist and never start technical work without them.

With the contract signed and the boundaries clear, the next step is to build somewhere you can actually practice these techniques safely and legally — a lab you own, where the only rules of engagement are the ones you set for yourself.