Penetration Testing Regulations and Standards

What Makes Penetration Testing Legal (vs. Illegal Hacking)

The line between legal security testing and illegal hacking is not defined by the tools you use or the techniques you employ — it's defined entirely by authorization. The same tools that security professionals use every day — Nmap, Wireshark, Metasploit, Aircrack-ng — are also used by criminals. The legal difference is whether you have permission.

In the United States, the Computer Fraud and Abuse Act (CFAA) prohibits accessing a computer "without authorization." In the UK, the Computer Misuse Act prohibits accessing a computer "without due authorization." In Germany, Section 202a of the Strafgesetzbuch (Criminal Code) prohibits unauthorized access to data. The pattern is consistent: unauthorized access is the common element across virtually every jurisdiction's computer crime laws.

Legal penetration testing is testing that is:

• Authorized in writing by someone with actual legal authority over the systems being tested
• Scoped precisely to specific systems, IP ranges, time periods, and methods
• Conducted with documented consent from all affected parties
• Performed with the intent of improving security, not personal gain or harm

Everything else — no matter how "benign" it seems — is potentially illegal hacking.

PTES: Penetration Testing Execution Standard

The Penetration Testing Execution Standard (PTES) was created in 2009 by a group of security professionals who recognized that the penetration testing industry lacked a common framework for how tests should be scoped, conducted, and reported. PTES provides a structured methodology that covers the entire lifecycle of a penetration test.

PTES Pre-Engagement Interactions

The first phase of PTES focuses on defining the engagement before it begins. This includes:

• Understanding the client's business and technical environment
• Defining the scope, objectives, and constraints
• Establishing communication protocols and emergency contacts
• Agreeing on legal terms, liability, and payment
• Defining "what if" scenarios (e.g., what happens if critical vulnerabilities are found)

PTES Intelligence Gathering

PTES recognizes that successful penetration testing requires thorough reconnaissance. This phase covers passive and active information gathering — from public sources (OSINT) to direct network probing — all done within the authorized scope.

PTES Threat Modeling

Threat modeling in PTES involves identifying assets, analyzing threats, and determining which attack vectors are most relevant to the client's environment. This ensures testing is focused and prioritized, not just a scattergun approach.

PTES Vulnerability Analysis

This phase covers both automated scanning (using tools like Nessus, OpenVAS, or Qualys) and manual verification of findings. PTES emphasizes that scanners find known vulnerabilities but miss business logic flaws and complex chain attacks.

PTES Exploitation

The exploitation phase applies techniques to demonstrate that identified vulnerabilities can actually be exploited. PTES requires that exploitation be done carefully, with awareness of potential side effects (data destruction, service disruption, etc.).

PTES Post-Exploitation

After gaining access, PTES guides testers through determining the value of compromised systems, maintaining access, and documenting the potential business impact of what an attacker could do with this foothold.

PTES Reporting

The final phase produces two deliverables: an executive summary for senior leadership (business risk, budget implications, overall posture) and a technical report for the IT team (detailed findings, proof-of-concept steps, remediation guidance, prioritization by risk level).

OWASP Testing Guide

The OWASP Testing Guide is the definitive methodology for testing web application security. Published by the Open Web Application Security Project (OWASP), it provides a comprehensive framework for identifying vulnerabilities in web applications and APIs.

The current version, OWASP Testing Guide v4.2, is organized into the following testing phases:

• Information Gathering: Conducting reconnaissance on the target application, including footprinting, enumeration, and identifying application architecture.
• Configuration and Deployment Management Testing: Testing how the application is configured and deployed — testing for misconfigurations, default credentials, debug endpoints, and exposed administrative interfaces.
• Identity Management Testing: Testing how identities are created, authenticated, managed, and destroyed — including account enumeration, weak lockout policies, and credential recovery.
• Authentication Testing: Testing the login mechanisms, including brute force protection, credential transmission security, multi-factor authentication bypasses, and session management.
• Authorization Testing: Testing vertical and horizontal privilege escalation, IDOR (Insecure Direct Object Reference), and path traversal vulnerabilities.
• Session Management Testing: Testing how sessions are created, validated, expired, and protected against hijacking and fixation attacks.
• Input Validation Testing: Testing for injection vulnerabilities — SQL injection, Cross-Site Scripting (XSS), LDAP injection, XML injection, and more.
• Error Handling Testing: Testing how the application handles errors and whether verbose error messages leak information.
• Cryptography Testing: Testing for weak encryption, improper key management, and sensitive data exposure in transit and at rest.
• Business Logic Testing: Testing the application's business logic for flaws — workflow circumvention, race conditions, and validation bypasses.
• Client-Side Testing: Testing for DOM-based XSS, cross-site flashing, clickjacking, and other client-side attacks.

The OWASP Testing Guide is the standard for web application penetration testing engagements and is referenced in PCI-DSS Requirement 6.6.

OSSTMM: Open Source Security Testing Methodology Manual

The OSSTMM, maintained by the Institute for Security and Open Methodologies (ISECOM), is a peer-reviewed, scientific methodology for conducting security testing and measurements. It is arguably the most rigorous and comprehensive security testing methodology available.

OSSTMM defines security testing across five core channels:

• Human Security: Testing the human element — social engineering, phishing resistance, insider threat, and physical security interactions with people.
• Physical Security: Testing physical barriers — locks, barriers, surveillance, access control systems, and environmental controls.
• Wireless Communications: Testing WiFi, Bluetooth, Zigbee, RFID, and other wireless technologies — including signal interception, jamming, and protocol attacks.
• Telecommunications: Testing landline phones, VoIP systems, and related telecommunications infrastructure.
• Data Networks: Testing wired network infrastructure, including switches, routers, firewalls, and the data that flows through them.

OSSTMM is distinctive in that it provides measurable security metrics — it tries to quantify security posture rather than simply identifying vulnerabilities. This makes it particularly valuable for organizations that need to demonstrate security improvement over time, or that need to compare their posture against industry benchmarks.

The OSSTMM also introduces the concept of Trust as the central variable in security analysis: security is the protection of trust relationships. When a trust relationship is violated, security has failed.

The Importance of Written Authorization (SOW, Rules of Engagement)

Verbal authorization is not authorization. In the legal context of penetration testing, verbal consent is a starting point that must be immediately documented in writing. Here's why written authorization is the absolute minimum requirement for any legitimate security testing engagement:

• Proof of consent: If you are ever investigated or sued, a signed document is your evidence that you had permission. A verbal conversation ("Sure, go ahead and test it") is almost impossible to prove.
• Scope definition: Written authorization should specify exactly what is in scope. This protects you: if you accidentally test something outside the scope, you have a record of what was authorized. It also protects the client: they know exactly what to expect.
• Limitation of liability: A properly drafted authorization agreement can limit your liability if something goes wrong — for example, if your testing inadvertently causes a service disruption.
• Compliance evidence: For regulated industries (healthcare, financial services, critical infrastructure), having documented penetration testing is often a regulatory requirement. The written authorization and report serve as compliance evidence.

What to Include in a Pen Test Agreement

A proper penetration testing agreement (sometimes called a Statement of Work, or SOW) should cover the following elements:

• Parties and authority: Full legal names of the client organization and the testing firm. Verification that the person signing has actual authority to authorize the testing — not just IT staff, but someone with legal authority over the assets.
• Scope definition: Specific IP addresses, domain names, physical locations, and system categories in scope. Explicitly list what is out of scope as well.
• Time window: Start date and end date, or specific testing windows. Some clients want testing done outside business hours to minimize disruption.
• Testing methods authorized: Which techniques are permitted? Social engineering? Physical testing? Denial-of-service testing? If it's not listed, it's not authorized.
• Data handling requirements: How will any sensitive data accessed during testing be handled? Encrypted? Not copied? Not retained beyond the engagement?
• Disclosure requirements: When and how findings will be disclosed. Some clients require findings to be held until patches are deployed.
• Emergency contacts: Named individuals to contact if testing causes an incident or service disruption.
• Liability provisions: Who is liable if testing causes damage? What's the limitation of liability cap?
• Non-disclosure provisions: Confidentiality obligations on both sides.
• Deliverables: What the testing firm will deliver (report format, timelines, etc.).

Scope Documentation Requirements

Beyond the high-level agreement, the scope document is the technical equivalent — a precise description of what will be tested, how, and when. Scope documents typically include:

• Target system inventory (IP addresses, hostnames, network diagrams)
• User accounts or test accounts to be used
• Any systems that require special handling (production systems, systems with data at risk)
• Network segmentation and VLAN configurations relevant to the test
• Any known limitations or constraints (e.g., "do not run aggressive port scans during business hours")
• Expected availability of target systems
• Any prior testing history (so you know what was already found)

What Happens If You Go Out of Scope

Going out of scope — testing something that wasn't in your authorization — is one of the most serious issues a penetration tester can face. Here's what typically happens:

• Immediate stop: The moment you realize you're outside the agreed scope, you stop. You don't "just finish this one thing."
• Client notification: You immediately contact the emergency contact and explain what happened, what you found, and what you're doing about it.
• Documentation: You document exactly what you did, when, and what data or access was involved. This goes into the report.
• Legal review: Depending on what you found or accessed, the client's legal team may need to be involved. This is why clear scope documentation matters.
• No "exceeds authorized access" defense: Going out of scope can mean you're now operating without authorization on those systems — even if the original agreement covered other systems. This can expose you to legal liability.

Bug Bounty Programs vs. Authorized Testing

Bug bounty programs are a popular alternative to formal penetration testing engagements. Instead of a contracted testing engagement, organizations run public programs that invite security researchers to find and report vulnerabilities in exchange for a reward (bounty). Popular platforms include HackerOne, Bugcrowd, and Open Bug Bounty.

Key differences from formal authorized testing:

The critical thing about bug bounty programs is that they have terms of service. These terms typically include:

• A safe harbor clause that protects researchers from prosecution "within the scope" of the program
• Specific prohibitions (often including DoS testing, physical attacks, social engineering, and spam)
• Data handling requirements for any data accessed
• Disclosure timelines (often 90 days from initial report before public disclosure is permitted)

Read the terms of every bug bounty program before you test anything. Some programs that look permissive actually have very restrictive fine print.

Liability for Penetration Testers

Even with a signed agreement, penetration testers carry real liability risk. Here's what can go wrong and how to protect yourself:

• Service disruption: A poorly timed port scan can take down a production system. A vulnerability that looks exploitable may actually crash the application. Testers have been held liable for disruptions caused by their testing. Mitigation: clear liability provisions in the contract, adequate insurance (Errors & Omissions / Professional Liability).
• Data exposure: If testing accesses personal data or regulated data (PII, PHI, cardholder data), testers may have obligations under privacy laws — even if they didn't steal anything. Mitigation: data handling provisions in the contract, minimal data retention, immediate notification if regulated data is encountered.
• Third-party liability: If the client's systems are connected to third-party networks, testing could affect those third parties. Mitigation: explicit scope boundaries, third-party notification by client before testing.
• Professional liability: If a tester fails to identify a vulnerability that is later exploited, the client may claim the tester was negligent. Mitigation: clear contract language about the nature of testing (best-effort, not guaranteed discovery),Errors & Omissions insurance.

Sample Scope Checklist

Before starting any penetration test, run through this checklist:

═══════════════════════════════════════════════════════
PENETRATION TEST SCOPE CHECKLIST
═══════════════════════════════════════════════════════

CLIENT INFORMATION
  □ Client name and legal entity verified
  □ Authorizing individual identified and documented
  □ Emergency contact established (name, phone, email)
  □ NDA / MSA executed before testing begins

SCOPE DEFINITION
  □ IP addresses / CIDR ranges explicitly listed
  □ Domain names explicitly listed
  □ Physical locations (if applicable) listed
  □ Mobile applications identified (iOS/Android packages)
  □ API endpoints / web services identified
  □ Cloud environments (AWS, Azure, GCP) identified

OUT OF SCOPE (explicitly excluded)
  □ Certain subdomains or IP ranges excluded
  □ Social engineering excluded (if applicable)
  □ Physical security testing excluded (if applicable)
  □ Denial-of-service testing excluded (if applicable)
  □ Third-party systems clearly excluded

AUTHORIZATION DOCUMENTATION
  □ Signed SOW / contract in hand before testing
  □ Authorization covers all in-scope systems
  □ Authorizing party has legal authority over all in-scope systems
  □ Scope documented and agreed by both parties
  □ Time window agreed and documented

TESTING PARAMETERS
  □ Testing hours agreed (business hours / off-hours / weekends)
  □ Rate limiting / throttling requirements agreed
  □ Maximum packets-per-second limits set
  □ Specific tool restrictions (if any) documented
  □ Escalation procedures if findings are critical

DATA HANDLING
  □ Agreement on how sensitive data will be handled
  □ No sensitive data will be retained beyond engagement
  □ No data will be exfiltrated
  □ If PII/PHI/PCI data encountered: immediate stop and report

DELIVERABLES
  □ Executive summary format agreed
  □ Technical report format agreed
  □ Timeline for draft and final report agreed
  □ Remediation verification (retest) scope agreed

LEGAL AND LIABILITY
  □ Liability provisions agreed
  □ Indemnification provisions agreed
  □ Insurance certificates exchanged
  □ Non-disclosure agreement in place
  □ Limitation of liability cap agreed

═══════════════════════════════════════════════════════