Every legitimate security test starts with permission. The technical work is the easy part; the professional discipline is what keeps it lawful, useful and repeatable.
Authorisation is specific
A vague "you can test our site" is not enough. A proper engagement defines:
- Targets: domains, IP ranges, applications, accounts and environments.
- Techniques: what is allowed, and what is explicitly out of scope.
- Time window: when testing may happen.
- Contacts: who to call if something breaks.
- Data handling: how findings and any personal data are stored and destroyed.
- Rules of engagement: constraints such as "do not test production payments".
Written authorisation should come from someone with the authority to grant it. A developer saying "sure, go ahead" may not be able to bind the organisation.
Scope is a technical control
Scope is not paperwork. It prevents you from:
- testing a shared service that belongs to another customer;
- causing an outage during business hours;
- accessing personal data you do not need;
- turning a learning exercise into unauthorised access.
If you find something outside scope, stop and report it. Do not "just check" whether it is exploitable.
You are testing app.example.com. While mapping, you notice admin.example.com resolves to the same infrastructure. The scope lists only app.example.com.
What is the correct next step?
Choose one option to continue.
Continue this lesson in the player
A free account unlocks the full lesson, the five-question knowledge check, progress tracking, notes and the completion certificate.