Explain why written authorisation is what separates security testing from crime, and how responsible disclosure works.
Why it matters
The tools and techniques of attackers and defenders are the same. A port scan, a password-guessing script or an XSS payload is a legitimate test in one situation and a crime in another. The difference is not skill or intent; it is authorisation. Understanding this protects you, your employer and the people whose systems and data you touch. This lesson is general awareness, not legal advice: laws differ by country and state, and professionals check with their organisation's legal team before testing.
The core rule
Only test systems you own, or systems whose owner has given you explicit, written permission, and only within the scope they agreed.
"I was only looking", "the server was misconfigured", "I didn't change anything" and "I was going to report it" are not authorisation.
The laws, in brief
Most countries have laws against accessing computers without permission:
- United States: Computer Fraud and Abuse Act (CFAA). It makes it a crime to access a computer "without authorization" or to exceed authorized access, and to cause damage. Many states have their own computer crime laws too. In 2022 the US Department of Justice announced a policy of not charging good-faith security research under the CFAA, but that is prosecutor policy, not a legal shield: civil lawsuits, state laws and other countries' laws still apply.
- United Kingdom: Computer Misuse Act 1990. Unauthorised access, access with intent to commit further offences, and unauthorised acts that impair a computer are all offences.
- Elsewhere: the Council of Europe's Budapest Convention on Cybercrime has been adopted by many countries, and most have similar offences.
Data protection laws (such as GDPR in Europe) add duties when testing involves personal data, even with permission.
What authorisation looks like at work
Professional penetration testers and red teams never start without paperwork:
- A contract or statement of work with the system owner, signed by someone who actually has authority over those systems.
- Scope: exactly which domains, IP ranges, applications and accounts are in, and which are out. Third-party services (a cloud provider, a SaaS tool) usually need their own permission or have published testing rules.
- Rules of engagement: allowed techniques (is social engineering allowed? denial of service?), testing hours, how to handle sensitive data found, and who to call if something breaks.
- A "get out of jail" letter: a signed authorisation the tester can show if questioned.
If anything is unclear, stop and ask in writing before continuing.
Ethics beyond the law
Being legal is the minimum. Professional codes of ethics (from bodies such as ISC2 and EC-Council, and CompTIA's candidate code of conduct) add expectations:
- Protect the confidentiality of anything you see. Take only the minimum evidence needed.
- Do no harm: avoid actions that could take systems down or destroy data, even within scope.
- Report honestly, including your own mistakes.
- Do not use access for anything beyond the agreed purpose.
Responsible (coordinated) disclosure
Sometimes you find a vulnerability by accident, for example a website that shows other customers' orders when you change a number in the URL. Coordinated vulnerability disclosure is the accepted way to handle it:
- Stop. Do not explore further, download data or "prove" the impact. Note only what you saw.
- Find the right contact. Look for a
security.txtfile (a standard defined in RFC 9116) athttps://example.com/.well-known/security.txt, a vulnerability disclosure policy, or a bug bounty programme page. - Report privately with clear, minimal details: what you saw, where, when, and how to reproduce it safely.
- Give the owner time to fix it, commonly around 90 days, and agree on any public write-up.
- If you get no response, national coordination centres (such as CERT/CC in the US) can help.
Many organisations publish a vulnerability disclosure policy (VDP) that promises not to take legal action against good-faith reporters who follow its rules. Bug bounty programmes go further and pay for valid findings, but only within their published scope and rules. Testing outside the scope, or breaking the rules, removes that protection.
Worked scenarios
| Situation | Authorised? | What to do |
|---|---|---|
| Scanning the laptop and VM you own on your home network | Yes | Go ahead; keep it on your own network |
| Your employer asks you, by email, to "check the website's security" | Unclear | Get written scope, rules of engagement and sign-off from someone with authority |
| Testing a company's main website because it has a bug bounty | Only within the programme's scope | Read the scope and rules first; out-of-scope assets are off limits |
| Noticing that your school portal shows other students' grades when you change the URL | No further testing | Stop, report privately to the school's IT or security contact |
| Practising on TryHackMe, Hack The Box or PortSwigger's Web Security Academy | Yes, within their rules | These platforms exist to give you legal targets |
Common mistakes
- Assuming public means permitted. A website being reachable from the internet does not give you permission to test it.
- Scope creep. Finding a link to another server during an authorised test does not put that server in scope.
- Verbal permission. Always get it in writing, from someone who has the authority to give it.
- "Proving" a bug by taking data. Downloading records turns a report into a breach.
Quick recap
- Authorisation, in writing and within scope, is what separates security testing from crime.
- Laws such as the US CFAA and the UK Computer Misuse Act make unauthorised access illegal; good intentions are not a defence. This is not legal advice.
- Professional testing uses contracts, scope and rules of engagement.
- Found something by accident? Stop, report privately through
security.txtor a disclosure policy, and give the owner time to fix it.