Legal Limits: Knowing Where and When to Stop

Throughout this course, almost every lesson has included a reminder about scope, authorisation, and legal boundaries. This lesson brings those scattered reminders together into a single, practical framework for the moments when a real decision has to be made, often quickly, during an actual engagement.

Why this deserves its own lesson, at the end

By now you understand the techniques and the paperwork. The hardest part of professional practice is not knowing the law in the abstract; it is recognising, in the middle of a real, sometimes exciting or pressured moment, that a specific situation requires you to pause, ask, or stop. This lesson is a rehearsal for exactly those moments.

A simple decision framework: the three questions

Whenever you are unsure whether to proceed with a specific action during an engagement, ask these three questions, in order:

1. Is this system or action explicitly covered by my current, signed authorisation and scope? If no, stop immediately; this is never negotiable in the moment, regardless of how harmless the action seems.
2. Even if covered by scope, could this action cause harm beyond what the client has explicitly accepted (for example, a genuinely destructive or disruptive technique not specifically discussed)? If there is real doubt, pause and ask your contact before proceeding, exactly as the "allowed and forbidden techniques" section of your authorisation (chapter 1) should have anticipated.
3. Have I seen something that goes beyond the technical scope of this test entirely (evidence that another party has already compromised the system, apparent illegal content, or anything suggesting immediate danger to people)? If yes, stop testing that area immediately and escalate to your contact right away, following whatever emergency procedure your authorisation document defines.

Recognising scope creep in the moment

Scope creep rarely announces itself. It usually sounds like genuine, well-meaning curiosity or helpfulness: "while I'm here, let me just quickly check this other system too", or a client casually saying "feel free to also look at X" in an informal chat, without a formal scope update. The professional habit, rehearsed throughout this course, is simple: any new system or technique needs to be added to the written scope, explicitly, before it is tested, no matter how minor it seems or how informally the suggestion was made.

When a client pressures you to go further than agreed

Sometimes the pressure to exceed scope comes from the client itself, perhaps a frustrated executive wanting faster, more dramatic proof. A professional response acknowledges the request while holding the boundary firmly: explain clearly why the current scope and techniques were chosen (often for good legal or safety reasons), and offer to formally discuss an extension to the scope and authorisation, through the proper written process, rather than simply agreeing verbally in the moment. A reputable tester never allows urgency or persuasion, however sincere, to replace a signed, written authorisation update.

What to do if you discover something seriously alarming

If, during an authorised test, you discover clear evidence that a real attacker has already compromised the system (for example, signs of an active, ongoing unauthorised intrusion unrelated to your own testing), the professional response is immediate and specific:

1. Stop your own testing activity in that area immediately, to avoid interfering with evidence or an ongoing incident.
2. Contact your designated client contact right away, following the emergency procedure from your authorisation document.
3. Document exactly what you observed, with timestamps, without taking any further action yourself beyond that documentation.
4. Let the client's own incident response process, or law enforcement if the client involves them, take over from there; this is now beyond the scope of a standard penetration test.

Personal boundaries and saying no

Professional ethics sometimes requires refusing a request entirely, not just negotiating its scope. If a prospective client asks you to test a system you know, or reasonably suspect, they do not actually have the authority to authorise (recall the "third parties and hosted systems" discussion from chapter 1), or asks for a technique explicitly outside what is legally and professionally reasonable, the correct answer is simply no, clearly and without ambiguity, even at the cost of losing the engagement. Professional reputation, and personal legal safety, are built on this kind of consistency over an entire career, not on any single engagement.

Your fil rouge: a personal decision checklist

Write your own short, personal checklist, in your own words, based on the three-question framework above, that you could genuinely imagine pinning next to your screen during a future real engagement. Save it in your Project Lighthouse engagement folder as a closing artefact of the whole course.

Your turn: decide across four scenarios

For each scenario, decide what the correct action is, using the three-question framework.

1. Mid-engagement, you notice a second internal server that was not in the original scope, reachable from a machine you compromised.
2. Your scope allows testing a web application, and you are considering an action that, while technically in scope, could plausibly crash the production database if it goes wrong, which was never specifically discussed.
3. While reviewing files on an authorised test server, you find what appears to be evidence that someone else already has unauthorised remote access to it, unrelated to your own test.
4. A client contact says in a casual phone call, "don't worry about the formal scope update, just go ahead and test the new payment system too, I trust you."

See a solution

(1) This is a scope question: pause, document what you observed, and confirm with the client before testing the new server, exactly the pivoting caution from chapter 4. (2) This is a potential-harm question: pause and explicitly confirm with the client whether this specific, riskier action is acceptable, even though the broader application is in scope, since the authorisation likely did not specifically anticipate this exact risk. (3) This goes beyond the technical scope of a standard test entirely: stop testing that area, document what you saw with timestamps, and escalate immediately to your contact following the emergency procedure, without taking further action yourself. (4) Despite the client's verbal trust and good intentions, a casual verbal statement is not a valid scope update: politely explain that you need a written confirmation before testing the new system, and offer to arrange it quickly through the proper process.

The final lesson of this course, and of this entire parcours, looks back at everything you have learned and forward at where a beginning white hat can go next.