Legal Reference
This appendix provides a reference guide to the laws, regulations, and legal frameworks most relevant to ethical hackers and penetration testers. It is not legal advice. Laws change, court interpretations evolve, and jurisdiction-specific details matter enormously. Always consult a qualified attorney before making legal decisions about security testing activities.
Computer Fraud and Abuse Act (CFAA) — United States
Overview
The CFAA (18 U.S.C. Section 1030) is the primary federal law governing computer crimes in the United States. Enacted in 1986 and amended multiple times since, it criminalizes unauthorized access to computer systems and the damage or theft of information from them.
Key Provisions
Section 1030(a)(1) — Espionage Accessing a computer to obtain national defense or foreign relations information with the intent or reason to believe it will harm the United States or benefit a foreign nation. Penalty: Up to 10 years (first offense), 20 years (subsequent offenses).
Section 1030(a)(2) — Unauthorized Access to Obtain Information Intentionally accessing a computer without authorization, or exceeding authorized access, to obtain information from a financial institution, the U.S. government, or any protected computer (which includes virtually all internet-connected computers). Penalty: Up to 1 year (first offense misdemeanor), up to 5 years (if for commercial advantage, financial gain, or furtherance of another crime), up to 10 years (subsequent offenses).
Plain language: If you access a computer system without permission and view information you should not see, this section applies. It does not require that you damage anything or steal anything of monetary value — merely viewing the information is sufficient.
Section 1030(a)(3) — Trespassing in a Government Computer Intentionally accessing a nonpublic U.S. government computer without authorization. Penalty: Up to 1 year (misdemeanor, first offense), up to 10 years (subsequent offenses).
Section 1030(a)(4) — Computer Fraud Knowingly accessing a protected computer without authorization, or exceeding authorized access, with the intent to defraud, and obtaining something of value. Penalty: Up to 5 years (first offense), up to 10 years (subsequent offenses).
Section 1030(a)(5) — Damaging a Computer - (A) Knowingly causing the transmission of a program, information, code, or command that intentionally causes damage. Penalty: Up to 10 years. - (B) Intentionally accessing a protected computer without authorization and recklessly causing damage. Penalty: Up to 5 years. - (C) Intentionally accessing a protected computer without authorization and causing damage and loss. Penalty: Up to 1 year.
Plain language: If your scanning or testing crashes a service, corrupts data, or causes financial loss, these provisions may apply — even if the damage was unintentional — if you lacked authorization.
Section 1030(a)(6) — Trafficking in Passwords Knowingly trafficking in passwords or similar information that would permit unauthorized access to a computer. Penalty: Up to 1 year (first offense), up to 10 years (subsequent offenses).
Section 1030(a)(7) — Threatening to Damage a Computer (Extortion) Threatening to damage a computer, obtain information from it, or impair its confidentiality to extort something of value. Penalty: Up to 5 years.
The Critical Concept: "Exceeds Authorized Access"
The CFAA's most contested phrase is "exceeds authorized access." After decades of conflicting circuit court decisions, the Supreme Court addressed this in:
Van Buren v. United States (2021): The Supreme Court held that a person "exceeds authorized access" under the CFAA only when they access computer information they are not entitled to access at all — not when they access information for an improper purpose. This narrowed the CFAA's scope significantly. A police officer who accessed a license plate database (which he was authorized to use) for a personal reason did not violate the CFAA, even though department policy prohibited personal use.
Implication for penetration testers: If a client authorizes you to test their web application but you also access their email server (not in scope), you have likely "exceeded authorized access." If you test within scope but discover something the client did not expect, Van Buren suggests this is not a CFAA violation if you were authorized to access the system.
CFAA and Security Research
The CFAA has been criticized for chilling legitimate security research. Researchers have been prosecuted or threatened with prosecution for: - Accessing publicly available data via APIs (hiQ Labs v. LinkedIn) - Discovering vulnerabilities through testing that arguably exceeded authorized use - Publishing vulnerability details that helped others access systems
The Department of Justice updated its CFAA enforcement policy in 2022 to state that "good-faith security research should not be charged." However, this is a prosecutorial guideline, not a legal safe harbor — it does not prevent private civil lawsuits under the CFAA.
Practical Guidance for Penetration Testers
- Always have written authorization before testing any system
- Stay within scope — the authorization document defines your legal boundaries
- Document everything — your activity log is your defense if questioned
- Understand that the CFAA applies to both criminal prosecution and civil lawsuits — a client or third party can sue you under the CFAA even if the government does not prosecute
- Interstate commerce hook: "Protected computer" covers essentially any computer connected to the internet, making the CFAA applicable to virtually all computer systems
UK Computer Misuse Act 1990
Overview
The Computer Misuse Act (CMA) 1990 is the United Kingdom's primary legislation governing computer crime. It has been amended several times, most recently by the Serious Crime Act 2015.
Key Offenses
Section 1 — Unauthorized Access to Computer Material Causing a computer to perform any function with intent to secure access to any program or data held in any computer, where that access is unauthorized and the person knows at the time that it is unauthorized. Penalty: Up to 2 years imprisonment and/or unlimited fine.
Plain language: If you access a computer system knowing you are not authorized to do so, this offense applies — regardless of whether you damage anything or steal any data.
Section 2 — Unauthorized Access with Intent to Commit or Facilitate Further Offenses Committing a Section 1 offense with the intent to commit or facilitate the commission of a further offense (such as fraud or theft). Penalty: Up to 5 years imprisonment and/or unlimited fine.
Section 3 — Unauthorized Acts with Intent to Impair Operation Performing any unauthorized act in relation to a computer that the person knows is unauthorized, with the intent to impair the operation of a computer, prevent or hinder access to data, or impair the operation of any program or the reliability of data. Penalty: Up to 10 years imprisonment and/or unlimited fine. This section covers DoS attacks, ransomware deployment, and data destruction.
Section 3ZA — Unauthorized Acts Causing or Creating Risk of Serious Damage Added by the Serious Crime Act 2015. Covers unauthorized computer acts that cause or create a significant risk of serious damage to human welfare, the environment, the economy, or national security. Penalty: Up to 14 years (or life imprisonment if the damage causes or creates risk of loss of life).
Section 3A — Making, Supplying, or Obtaining Articles for Use in Computer Misuse Offenses Makes it an offense to make, adapt, supply, or offer to supply any article (including tools and software) believing it will be used to commit a CMA offense. Also covers obtaining such articles with intent to commit an offense. Penalty: Up to 2 years imprisonment.
Critical issue for security professionals: Section 3A has caused significant concern in the UK security community because it potentially criminalizes the creation and distribution of security tools. The Crown Prosecution Service (CPS) has issued guidance stating that prosecution should focus on criminal intent, but the statute itself is broad. Professionals should maintain clear evidence of lawful purpose when developing or distributing security tools.
CMA and Penetration Testing
The CMA does not contain a specific exemption for authorized penetration testing. UK pentesters rely on: 1. Explicit written authorization from the system owner (which prevents the "unauthorized" element of the offense) 2. CPS prosecution guidance that considers whether testing was authorized 3. CREST and CHECK standards that provide a framework of professional practice
Authorization must come from someone with the legal authority to grant it — typically the system owner, not just a user or employee.
EU Directive on Attacks Against Information Systems (2013/40/EU)
Overview
This EU directive establishes minimum rules regarding the definition of criminal offenses and sanctions in the area of attacks against information systems. EU member states were required to transpose it into national law.
Key Provisions
Article 3 — Illegal Access to Information Systems Intentional access without right to the whole or any part of an information system. Member states may choose not to criminalize cases that are not serious (a threshold allowing minor or de minimis exceptions).
Article 4 — Illegal System Interference Intentionally seriously hindering or interrupting the functioning of an information system by inputting, transmitting, damaging, deleting, deteriorating, altering, or suppressing computer data. Covers DoS attacks and ransomware.
Article 5 — Illegal Data Interference Intentionally deleting, damaging, deteriorating, altering, or suppressing computer data without right.
Article 6 — Illegal Interception Intentionally intercepting non-public transmissions of computer data to, from, or within an information system without right (including electromagnetic emissions from an information system carrying such data).
Article 7 — Tools for Committing Offenses Production, sale, procurement for use, import, distribution, or making available of tools designed or adapted primarily for committing these offenses, as well as computer passwords or access codes. Member states can choose not to prosecute if the tools are used for authorized testing.
Penalties
- Illegal access: Minimum maximum penalty of 2 years imprisonment
- System/data interference and illegal interception: Minimum maximum of 3 years
- Use of botnets or large-scale attacks: Minimum maximum of 5 years
Practical Implications
Each EU member state has implemented this directive differently. Penetration testers operating in Europe should: 1. Know the specific national implementation in the country where testing occurs 2. Obtain authorization that satisfies the local law's requirements 3. Be aware that cross-border testing may implicate multiple jurisdictions 4. Maintain documentation demonstrating lawful purpose for any security tools
GDPR Considerations for Penetration Testing
The General Data Protection Regulation (EU 2016/679) affects penetration testing when personal data is encountered during testing.
Key Considerations
Lawful Basis for Processing Personal Data During Testing
If you encounter personal data during a penetration test (usernames, email addresses, customer records, employee information), you are processing personal data under GDPR. The lawful bases most relevant to penetration testing: - Legitimate interest (Article 6(1)(f)): The controller has a legitimate interest in testing the security of systems that process personal data. A Data Protection Impact Assessment (DPIA) should be conducted. - Contractual obligation: If the testing is required by contract (e.g., PCI DSS requirements).
Data Minimization
Under GDPR's data minimization principle (Article 5(1)(c)), you should: - Access only the minimum personal data needed to demonstrate the vulnerability - Do not copy, download, or exfiltrate personal data beyond what is necessary for proof of concept - Take screenshots that redact actual personal data while showing that access is possible - Delete personal data from your testing systems as soon as it is no longer needed
Data Processing Agreement
The penetration testing firm acts as a data processor (or potentially joint controller) when accessing systems containing personal data. A Data Processing Agreement (DPA) should be in place between the client and testing firm, covering: - Categories of data that may be accessed - Security measures for handling data during testing - Data retention and deletion requirements - Breach notification procedures - Sub-processor arrangements (if the testing firm uses cloud infrastructure)
Cross-Border Considerations
If the target systems process personal data of EU residents, GDPR applies regardless of where the penetration tester is located. Testing a European company's systems from the United States does not exempt you from GDPR obligations.
Breach Notification
If a vulnerability you discover reveals that a data breach has already occurred (evidence of prior unauthorized access by a real attacker), the client may have a 72-hour breach notification obligation under Article 33. Report this to the client immediately.
Sample Authorization to Test Letter
This complete letter can be adapted for real engagements. Have it reviewed by legal counsel before use.
[COMPANY LETTERHEAD]
AUTHORIZATION FOR SECURITY TESTING
Date: [YYYY-MM-DD]
Reference Number: [AUTH-YYYY-NNN]
To Whom It May Concern:
I, [Full Name], in my capacity as [Title] of [Client Full
Legal Name] ("the Company"), with registered address at
[Full Address], hereby authorize [Testing Firm Full Legal
Name] ("the Tester"), with registered address at [Tester
Address], to perform security testing activities against
the Company's information systems as described below.
1. SCOPE OF AUTHORIZATION
The following systems, networks, and applications are
authorized for security testing:
IP Addresses/Ranges:
- [List all IP addresses and CIDR ranges]
Domain Names:
- [List all authorized domains and subdomains]
Web Applications:
- [List application names and URLs]
Physical Locations (if applicable):
- [List authorized physical locations]
The following systems are EXPLICITLY EXCLUDED from testing:
- [List excluded systems]
2. AUTHORIZED ACTIVITIES
The Tester is authorized to perform the following activities:
[X] Network vulnerability scanning
[X] Penetration testing (manual and automated exploitation)
[X] Web application security testing
[ ] Social engineering (phishing, vishing, physical)
[ ] Wireless network security testing
[ ] Physical security testing
[X] Post-exploitation activities (privilege escalation,
lateral movement) within authorized scope
[ ] Denial of Service testing (controlled)
[ ] Other: [specify]
The following activities are PROHIBITED:
- [List prohibited activities]
- Deliberate destruction of production data
- Testing against live customer/user sessions
- [Additional restrictions]
3. TESTING PERIOD
This authorization is valid from [Start Date/Time/Timezone]
to [End Date/Time/Timezone]. Testing outside this period
is not authorized without written amendment.
4. TESTING PERSONNEL
The following individuals are authorized to perform testing
under this authorization:
Name: [Full Name] ID/Passport: [Number]
Name: [Full Name] ID/Passport: [Number]
No other individuals are authorized to test under this
letter without written amendment.
5. TESTER SOURCE ADDRESSES
Testing will originate from the following network addresses:
External: [IP addresses]
Internal: [IP addresses, if applicable]
VPN: [Connection details, if applicable]
6. CONTACT INFORMATION
Company Emergency Contact:
Name: [Name]
Title: [Title]
Phone: [24/7 Phone Number]
Email: [Email]
Tester Lead Contact:
Name: [Name]
Phone: [Phone Number]
Email: [Email]
If testing causes any service disruption, the Tester will
immediately cease the causative activity and notify the
Company Emergency Contact.
7. DATA HANDLING
Any data accessed, collected, or created during testing will
be handled in accordance with the Data Handling Agreement
[reference number] between the parties. The Tester agrees to:
- Encrypt all testing data at rest and in transit
- Access only the minimum data needed to demonstrate findings
- Not exfiltrate sensitive data beyond the authorized network
- Securely delete all testing data within [N] days of the
engagement report delivery
- Immediately notify the Company if evidence of a prior
security breach is discovered
8. LEGAL PROTECTIONS
The Company acknowledges that authorized security testing
may trigger security alerts, log entries, and monitoring
systems. The Company agrees not to pursue legal action against
the Tester for activities performed within the scope of this
authorization.
This authorization does not extend to systems, networks, or
services owned or operated by third parties, even if they are
connected to or integrated with the Company's systems, unless
the Company has obtained and provided written authorization
from those third parties.
9. AUTHORITY
I confirm that I have the authority to authorize security
testing of the systems described above on behalf of the
Company. I understand the nature of penetration testing and
acknowledge that testing may involve attempts to access
systems, data, and services in ways that simulate real-world
attacks.
Authorized Signatory:
Name: ___________________________________
Title: ___________________________________
Department: ___________________________________
Signature: ___________________________________
Date: ___________________________________
Company Seal/Stamp (if applicable):
Acknowledged by Tester:
Name: ___________________________________
Title: ___________________________________
Signature: ___________________________________
Date: ___________________________________
Sample Rules of Engagement Document
RULES OF ENGAGEMENT — SECURITY TESTING
Engagement Reference: [AUTH-YYYY-NNN-ROE]
Associated Authorization: [AUTH-YYYY-NNN]
Version: 1.0
Date: [YYYY-MM-DD]
1. OPERATIONAL RULES
1.1 All testing must comply with the Authorization to Test
letter (Ref: [AUTH-YYYY-NNN]).
1.2 Testing hours: [HH:MM] to [HH:MM] [Timezone],
[Days of week]. Testing outside these hours requires
written approval from [Contact Name].
1.3 The Tester will use codeword "[CODEWORD]" to identify
themselves if contacted by the Company's security team.
1.4 Source IP addresses for testing:
External: [IPs]
Internal: [IPs]
2. CRITICAL FINDING NOTIFICATION
2.1 Findings rated Critical (CVSS 9.0+) will be reported
to [Contact] within [4] hours of confirmation.
2.2 Evidence of active compromise by a third party will be
reported to [Contact] within [1] hour.
2.3 Notification method: [Encrypted email to address /
Phone call to number]
3. PROHIBITED ACTIONS
- Denial of Service attacks of any kind
- Modification of production data
- Access to or exfiltration of [PII/PHI/PCI] data
beyond proof of access
- Installation of persistent backdoors
- Social engineering of employees (unless specifically
authorized in Section 4)
- Testing of third-party hosted services without
separate authorization
- Exceeding [N] concurrent connections / [N] requests
per second
4. SPECIFIC AUTHORIZATIONS
[X] Automated vulnerability scanning (max [N] threads)
[X] Manual exploitation of discovered vulnerabilities
[X] Password attacks: offline hash cracking only
[ ] Password attacks: online (max [N] attempts per account,
respecting lockout policy of [N] attempts / [N] minutes)
[ ] Phishing: [N] employees, approved templates provided
[X] Post-exploitation: privilege escalation and lateral
movement within scope
[ ] Physical testing: [specify locations and constraints]
[X] Wireless testing: Company-owned networks only
5. INCIDENT PROCEDURES
5.1 If testing causes a service disruption:
a) Stop the specific activity immediately
b) Notify [Contact] at [Phone] within 15 minutes
c) Provide incident details and potential root cause
d) Resume only after written approval from [Contact]
5.2 If the Tester encounters potentially illegal content:
a) Stop immediately and do not investigate further
b) Preserve evidence (do not delete or modify)
c) Notify Tester's legal counsel immediately
d) Follow direction from legal counsel on notification
6. DOCUMENTATION REQUIREMENTS
6.1 The Tester will maintain a detailed testing log with:
timestamps, actions taken, tools used, and results.
6.2 All evidence will be stored encrypted (AES-256+).
6.3 Screenshots will be taken for all significant findings.
6.4 The Tester will preserve sufficient evidence for each
finding to allow independent reproduction.
7. ACCEPTANCE
Company Representative:
Name: _________________________
Title: _________________________
Signature: _________________________
Date: _________________________
Lead Tester:
Name: _________________________
Signature: _________________________
Date: _________________________
Bug Bounty Safe Harbor Language Examples
Bug bounty programs increasingly include "safe harbor" provisions that protect researchers from legal action when they follow the program's rules. Below are examples of safe harbor language drawn from real-world programs (generalized for reference).
Example 1: Strong Safe Harbor
If you conduct security research in compliance with this policy, we will consider your research to be authorized, and we will not pursue legal action against you. If legal action is initiated by a third party against you for research conducted in compliance with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
Example 2: DOJ-Influenced Safe Harbor
We consider security research conducted consistent with this policy to constitute "authorized" conduct under the Computer Fraud and Abuse Act (18 U.S.C. Section 1030), the Digital Millennium Copyright Act (17 U.S.C. Section 1201), and applicable state computer crime laws. We will not bring a CFAA or DMCA claim against researchers who discover and report security vulnerabilities in accordance with this policy.
Example 3: Conditional Safe Harbor
We will not pursue legal action against you for security testing that: (a) is conducted in accordance with this Vulnerability Disclosure Policy; (b) is limited to in-scope systems; (c) avoids privacy violations, destruction of data, and interruption of services; (d) does not compromise the safety of others; and (e) findings are reported to us before public disclosure.
What to Look For in a Safe Harbor
- Explicit authorization statement — clear language that testing within the policy is "authorized"
- CFAA/CMA reference — explicit statement that the program considers compliant testing as authorized under relevant computer crime laws
- Third-party protection — commitment to defend you if a third party (e.g., a hosting provider) initiates action
- Good faith requirement — typically requires you to act in good faith and comply with the policy
- Limitations — most safe harbors do not protect against privacy violations, data destruction, or service disruption
What to Do If a Program Lacks Safe Harbor
If a bug bounty program does not include safe harbor language: 1. Consider the risk before testing — without safe harbor, you are relying on the company's goodwill 2. Be conservative in your testing — avoid any action that could be construed as harmful 3. Document your compliance with the program's rules meticulously 4. Consider asking the program to add safe harbor language (many have after researcher requests)
Key Court Cases Affecting Security Researchers
United States v. Aaron Swartz (2011)
Aaron Swartz was indicted under the CFAA for downloading academic articles from JSTOR through MIT's network. He faced up to 35 years in prison and $1 million in fines. Swartz died by suicide in 2013 before trial. The case generated widespread criticism of the CFAA's severity and prosecutorial overreach, leading to proposed (but not enacted) reforms ("Aaron's Law"). Significance: Demonstrated that the CFAA could be used aggressively against individuals engaged in activities many consider non-criminal.
hiQ Labs v. LinkedIn (2022, 9th Circuit)
hiQ scraped publicly available LinkedIn profiles. LinkedIn sent a cease-and-desist and blocked hiQ's access. The Ninth Circuit ruled that accessing publicly available data on the internet is not "unauthorized access" under the CFAA. Significance: Scraping publicly available data is likely not a CFAA violation, though the case focused on civil, not criminal, liability. Does not authorize bypassing authentication or access controls.
Van Buren v. United States (2021, Supreme Court)
A police officer accessed a law enforcement database (which he was authorized to use) for an unauthorized purpose (looking up a license plate for money). The Supreme Court ruled 6-3 that Van Buren did not violate the CFAA because he accessed a system he was authorized to use — the statute targets unauthorized access to information, not unauthorized purposes for accessing information. Significance: Narrowed the CFAA's "exceeds authorized access" provision. Reduced risk for employees who misuse authorized access, but did not affect scenarios where access is truly unauthorized.
United States v. Auernheimer (weev) (2013, 3rd Circuit)
Andrew Auernheimer discovered that AT&T's website exposed iPad user email addresses through a predictable URL pattern. He collected approximately 120,000 email addresses and provided them to a journalist. He was convicted under the CFAA but the conviction was vacated on venue grounds (not on the merits of the CFAA charge). Significance: Highlighted the legal risk of accessing data through URL manipulation even when no authentication bypass is involved. The underlying CFAA question was never definitively resolved.
Sandvig v. Barr (2020, D.C. District Court)
Researchers challenged the CFAA's application to research that involved creating fake profiles to study discrimination on employment websites (violating the sites' terms of service). The court ruled that the CFAA does not criminalize violations of website terms of service. Significance: Further limited the CFAA's scope to actual unauthorized access rather than terms-of-service violations.
United States v. Valle (2015, 2nd Circuit)
A police officer accessed a law enforcement database for personal purposes. The Second Circuit ruled that violating an employer's use policy did not constitute "exceeding authorized access." Significance: An early circuit decision narrowing "exceeds authorized access," later confirmed by Van Buren at the Supreme Court level.
State-Level Computer Crime Laws (United States)
All 50 U.S. states have their own computer crime laws in addition to the federal CFAA. State laws often have lower thresholds for prosecution and may define unauthorized access differently. Key points:
California Penal Code Section 502
One of the most comprehensive state computer crime laws. Criminalizes unauthorized access, data destruction, computer fraud, and disruption of computer services. Includes a private right of action (individuals can sue). Notably, California has a "white hat" provision (Section 502(h)) allowing authorized security testing.
New York Penal Law Article 156
Defines computer-related offenses from misdemeanor unauthorized use (Section 156.05) to felony computer tampering (Sections 156.20-156.27). Covers unauthorized use, computer trespass, computer tampering, and unlawful duplication of computer-related material.
Texas Penal Code Chapter 33
Broad computer crime statute covering unauthorized access, breach of computer security, and online harassment. "Breach of computer security" (Section 33.02) criminalizes accessing a computer without the effective consent of the owner. Penalties range from misdemeanor to first-degree felony depending on the nature and impact of the access.
General Guidance
- State laws apply in addition to federal law — you can be prosecuted under both
- The state where the target computer is located may assert jurisdiction, not just your home state
- Some states have harsher penalties than the federal CFAA
- Few states have explicit safe harbors for security research
- Always check the specific state law where your target systems are located
International Considerations for Cross-Border Testing
The Problem
Penetration testing frequently crosses borders. You may be in the United States testing a server in Germany that serves customers in Japan. Which country's laws apply? The answer is: potentially all of them.
Key Principles
Territorial jurisdiction: A country has jurisdiction over crimes committed within its territory. If the target server is in Germany, German law applies regardless of where the tester is located.
Effects-based jurisdiction: Some countries claim jurisdiction based on the effects of the conduct. If your testing affects users in a country, that country may claim jurisdiction.
Nationality jurisdiction: Some countries can prosecute their own citizens for crimes committed abroad.
Practical Guidance
- Identify where target systems are physically located — the host country's laws apply
- Identify where the client is incorporated — the client's country may have specific requirements for authorization
- Identify where personal data subjects reside — GDPR applies to data subjects in the EU regardless of where processing occurs
- For cloud-hosted targets: Determine the physical region/data center — cloud providers' legal jurisdiction depends on where the data center is located
- For multinational engagements: Obtain separate authorization that addresses each relevant jurisdiction
- Consult legal counsel familiar with international cybersecurity law for any cross-border engagement
- Avoid testing systems in countries with vague or aggressive computer crime laws unless you have clear legal guidance
- Travel risk: Some countries have arrested security researchers for work done in other countries. Be aware of legal risk before traveling to countries whose systems you have tested.
Country-Specific Notes
Australia: Criminal Code Act 1995, Part 10.7. Covers unauthorized access, modification, and impairment. Penalties up to 10 years imprisonment. No explicit security research exemption.
Germany: Section 202a-202c StGB (Strafgesetzbuch). Section 202c criminalizes the preparation of unauthorized access (creating/distributing hacking tools). Has been criticized for its breadth. German courts have generally interpreted it narrowly, but the law remains a concern for tool developers.
Japan: Unauthorized Computer Access Act (2000, amended 2013). Prohibits unauthorized access and the acquisition/storage of authentication credentials. Strict liability — intent is not required for some provisions.
Singapore: Computer Misuse Act (Chapter 50A). Similar to the UK CMA. Includes provisions against denial of service, unauthorized access, and unauthorized modification. Extraterritorial jurisdiction for acts affecting Singapore-based computers.
Brazil: Marco Civil da Internet (2014) and Lei Carolina Dieckmann (2012). The former establishes internet governance principles; the latter criminalizes invasion of computer devices to obtain, tamper with, or destroy data. Penalties of 3 months to 1 year imprisonment.
Best Practices Summary
-
Never test without written authorization. This is the single most important legal protection.
-
Keep authorization documents accessible — carry physical and digital copies during physical tests.
-
Stay within scope. Exceeding authorized scope can void your legal protection.
-
Document everything. Your activity log is your defense if questions arise.
-
Understand the laws in the jurisdictions where your testing occurs, where targets are located, and where data subjects reside.
-
Carry professional liability insurance. Errors and omissions (E&O) insurance covers claims arising from your professional activities.
-
Report findings responsibly. Follow agreed-upon disclosure procedures. Never go public with client findings without explicit permission.
-
Consult legal counsel for any situation that is ambiguous, cross-border, or involves sensitive data.
-
Understand that "I was just testing" is not a legal defense. Authorization from the system owner is the defense.
-
Stay current. Laws and interpretations change. Follow legal developments in cybersecurity law through resources like the EFF, ACLU, and specialized cybersecurity law blogs.
This appendix is provided for educational purposes only. It does not constitute legal advice. Consult a qualified attorney licensed in your jurisdiction for legal guidance specific to your situation.