Writing an Authorisation and a Scope

The authorisation and the scope are the documents that make your work legal, safe and measurable. In this lesson you will learn what they contain, why every line matters, and you will write your own for Project Lighthouse.

In lesson 1.1 you saw that a legal test rests on three pillars: a contract, a written authorisation and a scope. In practice, the contract and the scope are often combined with a "rules of engagement" document. Here we will look at the elements you need, in plain language. Your employer's or client's legal team will write the final wording, but a tester who understands each element avoids many painful misunderstandings.

Why paperwork matters to a hacker

Imagine you are testing a company's servers at two in the morning and the security team notices strange traffic. They call the police, or they shut down a critical service in panic. Without a clear document and a contact to call, you have a very bad night. With the document, a phone call resolves it in minutes.

The authorisation also protects the client. It proves who agreed to what, and it lets the client explain to its own providers and insurers why a test took place.

The elements of a good authorisation

1. Parties and signatories

Who is the client, and who is the testing team? Names, legal entities, and the signature of a person who can legally authorise tests on the listed systems, such as a managing director or a chief information security officer. A signature from someone without that authority is worth nothing.

2. Objectives

What does the client want to learn? "Check whether an outsider can reach customer data from the internet" is an objective. "Do some hacking" is not. Objectives guide your decisions when something unexpected appears.

3. Scope: what is in

The list of systems you may test, as precisely as possible: IP ranges, host names, application addresses, physical locations if relevant. For each item, who owns it and where it is hosted.

4. Scope: what is out

Just as important is the list of what you must not touch: production databases, a supplier's platform, a medical device, an employee's personal equipment. Often, "everything not listed as in scope is out of scope" is written explicitly.

5. Allowed and forbidden techniques

May you try to crash a service (denial of service tests)? May you use social engineering? May you attack the wireless network? May you leave a harmless marker file as proof? Each answer is a line in the document. A typical safe default: denial of service is excluded unless specifically requested and scheduled.

6. Dates and time windows

Start and end date, and the hours when testing is allowed. Intensive scans may be restricted to evenings and weekends to protect business activity.

7. Contacts and escalation

Names and phone numbers, on both sides, available during testing. Include the "emergency stop" procedure: who can ask you to stop immediately, and how. Also include what you do if you discover evidence that someone else has already compromised the system, or illegal content: stop and call the contact immediately.

8. Source addresses

The IP addresses you will test from. This lets the client's security team distinguish your traffic from a real attack.

9. Data handling

What data you may access, how you store it, how long you keep it, and how you destroy it. This is where the GDPR obligations from lesson 1.1 become concrete.

10. Reporting and confidentiality

What you deliver, in what format, when, and to whom. And the confidentiality obligations, which usually continue after the mission ends.

11. Liability and insurance

Who is responsible if something goes wrong? Professional testers carry insurance, and contracts often include a clause acknowledging that tests carry a small residual risk of disruption. This is a contract matter for lawyers, not for you to improvise.

Scope in practice: common pitfalls

• Scope creep: "While you are there, could you also look at the new server?" Always update the document before testing anything new.
• Shared infrastructure: a scope that says "the web server at address A" does not cover the shared hosting platform on which it runs.
• Redirects and links: a login page that redirects to an external identity provider takes you out of scope. Stop at the border.
• Wildcard scopes: "all subdomains of the company domain" sounds simple, but some subdomains may point to third-party services. Specify how to handle them.
• Dynamic environments: in cloud setups, addresses change. List the accounts or tenants instead of only fixed addresses when possible.

A sample, for your lab

Below is a simplified template you can adapt for your lab. It is deliberately generic and uses addresses that only exist inside a private virtual network.

ENGAGEMENT AUTHORISATION (LAB TEMPLATE)

Client:            Lighthouse Labs (fictional, played by: your name)
Tester:            your name
Authorised by:     your name, owner of all systems listed below
Dates:             from 2026-01-10 to 2026-01-24
Hours allowed:     any time (private lab)

Objective:
  Practise a complete penetration test and produce a professional report.

In scope:
  - Virtual network 192.168.56.0/24 (host-only, no internet access)
  - Machine "kali-attacker"   192.168.56.10  (tester machine)
  - Machine "lab-web01"       192.168.56.21  (training VM)
  - Machine "lab-srv02"       192.168.56.22  (training VM)

Out of scope:
  - The host computer and the home network
  - Any machine reachable via the internet

Allowed:   scanning, enumeration, exploitation of training VMs, password
           attacks on lab accounts, post-exploitation inside the lab
Forbidden: any traffic leaving the host-only network

Emergency stop: power off the virtual machines.
Data: lab data only, deleted at the end of the course.

It looks almost too simple, but the structure is the same as a professional document. For a real client, every line grows into a paragraph reviewed by legal teams.

Your fil rouge: Project Lighthouse paperwork

Write the authorisation for your Project Lighthouse lab. Fill in your own names, dates and the addresses your hypervisor assigns to the virtual network. Save it as the first file of your engagement folder (you will create the folder structure in lesson 1.4). If you use a hosted training platform instead of local virtual machines, read its rules and quote them in the "allowed" and "forbidden" lines.

Your turn: find the flaws

A colleague proposes this scope sentence for a real mission: "Test the company network and the website. Any technique is allowed. Start whenever you want." List at least four problems with it.

See a solution

• "Company network" and "the website" are not precise: no addresses, no domains, no owners, no hosting information.
• "Any technique is allowed" includes denial of service, social engineering and destructive actions, probably unintentionally.
• "Start whenever you want" provides no time window, so the security team cannot tell a test from an attack.
• There is no emergency contact, no data-handling rule, no mention of third-party providers and no signatory authority.

With the paperwork in place, you can organise your tools and your working method, which is the topic of the last lesson of this chapter.