Legal & Ethical Considerations
Hacking without authorization is a serious crime in virtually every jurisdiction. This lesson covers the legal frameworks that govern penetration testing, including the Computer Fraud and Abuse Act (CFAA) in the US and equivalent laws globally. You will also explore the ethical responsibilities that come with offensive security knowledge.
Learning Objectives — Deep Dive
Each objective below is broken down into plain English so you know exactly what you are learning, why it matters, and what you will be able to do when you are done. Mark each one complete as you work through the lesson.
Read the full text of the Computer Fraud and Abuse Act
Navigate to law.cornell.edu and read 18 U.S.C. 1030 in its entirety — it is not long and every security professional should have read it at least once. Pay special attention to section (a)(2) which criminalizes accessing a computer without authorization to obtain information (the most commonly charged provision), and section (a)(5) which covers causing damage to protected computers. Note that protected computer is defined extremely broadly — it includes essentially any computer connected to the internet. The key phrase throughout the statute is without authorization — this is why written authorization is the foundation of all legitimate security testing.
open https://www.law.cornell.edu/uscode/text/18/1030Study the Aaron Swartz case and its implications
Read the Wikipedia article on Aaron Swartz and then read the actual indictment document, which is available online. Swartz was a brilliant programmer and activist who downloaded academic articles from JSTOR using the MIT network — he believed academic research should be freely available. Despite the fact that JSTOR declined to press charges, federal prosecutors charged him with 13 felony counts under the CFAA with a potential sentence of 35 years. This case illustrates two critical lessons: good intentions provide no legal protection under the CFAA, and prosecutors have enormous discretion in how aggressively they apply the law. The security community widely considers this prosecution an overreach, but it happened and it can happen again.
open https://en.wikipedia.org/wiki/Aaron_SwartzDraft a comprehensive penetration testing authorization letter
Create a template authorization letter that covers all the elements needed to protect both you and your client legally. The letter must be signed by someone with actual authority to authorize security testing — a system administrator cannot authorize testing of systems they do not own. Include: the exact scope listing every IP address, domain, and application explicitly; the testing window with specific dates and times; the authorized techniques (scanning, exploitation, social engineering — list each explicitly); emergency contact information for both parties; and what happens if you discover a critical vulnerability during testing. Have a lawyer review your template before using it professionally.
Research and compare responsible disclosure policies
Read the disclosure policies of HackerOne, Bugcrowd, and at least one direct bug bounty program like Google or Microsoft, noting the key differences: disclosure timelines (typically 90 days from notification, but some programs allow extensions), what information can be published (some programs prohibit publishing any details, others encourage it), safe harbor language (the legal protection the company provides to researchers), and what happens if the company does not respond within the timeline. The 90-day disclosure deadline was pioneered by Google Project Zero and has become the industry standard — it gives vendors enough time to patch while preventing them from indefinitely suppressing vulnerability information.
open https://hackerone.com/disclosure-guidelinesUnderstand GDPR obligations during security testing
During a penetration test, you will inevitably encounter personal data — user records in databases, email addresses in files, customer information in application responses. Read the key GDPR principles at gdpr-info.eu: data minimization (only process what you need), purpose limitation (only use data for the stated purpose), and storage limitation (do not retain personal data longer than necessary). In practice this means: do not download databases containing personal data unless specifically required by the scope, do not store personal data on your testing machine, and immediately notify the client if you access personal data accidentally. Include a data handling section in your authorization letter that addresses these obligations explicitly.
open https://gdpr-info.eu/art-5-gdpr/Build your pre-engagement legal checklist
Create a comprehensive checklist that you will complete before starting any security engagement, covering these mandatory items: written authorization signed by an authorized representative (not just any employee), scope document listing every target explicitly, testing window with start and end times in the client timezone, emergency contact information for someone available 24/7 during testing, data handling agreement covering personal data encountered during testing, and confirmation that the client owns or has permission to authorize testing of all listed systems. Make this checklist a non-negotiable part of your engagement process — if a client refuses to provide written authorization, walk away from the engagement regardless of the financial opportunity.