Scope & Rules of Engagement

Here is the uncomfortable truth that makes this the most important exercise on the platform: the techniques a penetration tester uses and the techniques a criminal uses are often *the same techniques*. The difference between the two people is not skill. It is permission.

Accessing, scanning, or interfering with a computer system you do not own, without authorisation, is a criminal offence in nearly every country — in India under the Information Technology Act, 2000, in the US under the Computer Fraud and Abuse Act, and under equivalent laws elsewhere. Crucially, this is true even if you cause no damage and even if your intentions are good. Unauthorised access is the offence, by itself.

So authorisation is not paperwork you do afterwards. It is the thing that makes the work lawful at all, and it exists *before* you touch anything. A professional does not run a single scan until they can point to written permission that covers that target.

Two words that sound similar do different jobs, and keeping them apart keeps you out of trouble.

Authorisation answers *may I test at all?* It is explicit, written permission from someone who actually owns or controls the system and has the authority to grant it. A verbal "yeah, go for it" is not enough; a message from someone who does not own the system is not enough.

Scope answers *what, exactly, may I test?* Authorisation without scope is dangerously vague, so a real engagement draws a precise boundary: these specific domains, these IP ranges, these applications — and, just as importantly, what is out of scope.

Scope is a fence, and everything inside it is fair game while everything outside it is off-limits, even when the outside looks tempting and reachable. A partner company's systems, a shared hosting neighbour, an employee's personal device, a third-party service the target merely uses — these are routinely *out* of scope even on a real engagement, because the client cannot authorise testing of systems they do not control. Staying inside the fence is not a courtesy; it is the line between the engagement and an offence.

Before testing starts, the tester and the client agree a rules-of-engagement document. It turns "you have permission" into a precise, shared understanding so there are no surprises on either side. It typically covers:

• Scope — the exact in-scope targets and the explicit out-of-scope exclusions.
• Timing — the window during which testing may happen (some work is restricted to off-hours to avoid disruption).
• Permitted and forbidden techniques — for example, whether denial-of-service testing or social engineering is allowed, or explicitly banned.
• Handling of sensitive data — what to do if real personal or confidential data is encountered (usually: stop, do not copy it, note it).
• Points of contact and escalation — who to call, and the procedure if something breaks or if a serious, dangerous issue is found mid-test.
• Evidence and reporting — what will be recorded and how findings will be delivered.

This document protects everyone. It protects the client from damage and surprise, and it protects the tester by putting the boundaries and the permission in writing. If an engagement does not have one, that is a reason to pause, not proceed.

Two situations test your discipline more than any technique.

You find a serious issue outside scope. While testing the in-scope app, you notice that an *out-of-scope* system is clearly vulnerable. The temptation is to "just confirm it". Do not. Testing it is outside your authorisation, full stop. The right move is to stop, document what you observed from where you were allowed to be, and report it to your point of contact so the owner can decide what to do. Reporting is responsible; probing is an offence.

You stumble onto real sensitive data. If you come across genuine personal or confidential data, the rules of engagement usually say the same thing: do not copy it, do not keep exploring it, record that it was reachable, and notify your contact. The goal is to demonstrate the risk, not to collect the data.

And the general stance underneath both: you are there to find and report problems so they can be fixed — not to cause damage, not to hide what you did, not to go further than agreed. Clarity, restraint and a good report are the job. On this platform every lab is yours to attack freely; out in the world, permission and scope decide everything.

Submit the keys below to finish.