What a Written Penetration-Test Authorization Should Contain

Start with the answer: before anyone sends a single packet, you need a signed document that says who is allowed to test what, when, how and under what limits. Without it, a test is indistinguishable from an attack, and the tester, the company and sometimes innocent third parties are exposed. This article describes what such a document usually contains. It is general information and not legal advice, so have your counsel review the final text.

Why it matters

Unauthorized access to computer systems can be a crime under federal law and under state laws. Authorization is what separates a test from an offense, and its quality decides whether the test is safe. NIST SP 800-115, the federal technical guide to security testing, places planning and written rules of engagement ahead of execution. The OWASP Web Security Testing Guide likewise starts with scoping and agreement. A clear document also stops arguments later, when a test knocks over a fragile system or a security operations team calls the police on the testers.

1. Who is authorizing, and do they have the authority

Name the organization and the person signing, and their role. The signer must be able to authorize access to every system in scope. A department head cannot approve testing of a shared platform owned by another group, and a company cannot approve testing of a landlord's network or a vendor's hosted service. If the owner is someone else, get their signature too.

2. Scope: in, out and unclear

• In scope: list systems by name and by address range, domain, application or building, with environments such as production or staging.
• Out of scope: list what must not be touched, such as payment processors, life-safety systems, medical devices, partner connections and shared infrastructure.
• Unclear items: say what happens when a tester discovers an asset not on the list. The usual answer is to stop and ask.
• Test type: external, internal, web application, wireless, social engineering or physical. Each has different risks and needs its own approval.

3. The test window

State dates and times with time zone, including blackout periods such as month-end closing, a product launch or a peak season. Say whether testing may run outside business hours, and whether the security team is told in advance. Some tests are announced so that defenders do not escalate a false alarm. Others test detection, and a very small group knows. Write down which one this is and who knows.

4. Permitted and prohibited techniques

This is the section that prevents outages. Spell out what is allowed and what is not. Typical items to address:

• Vulnerability exploitation, and whether exploitation may go as far as running commands or reading data, or must stop at proof of access.
• Password attacks, including guessing and credential stuffing, and any account lockout risk.
• Denial-of-service and load testing, which are usually prohibited unless specifically agreed.
• Social engineering, such as phishing and phone pretexts, including which people and which lures are allowed.
• Physical entry, lock bypass and device placement, with a letter the testers carry.
• Persistence, data copying and lateral movement, and whether testers may use credentials they find.
• Use of the organization's own accounts, and test accounts the client provides.

5. Contacts and escalation

List names, roles and phone numbers for both sides, with a 24‑hour contact for the test period. Include the person who can stop the test, the person who handles an urgent finding such as an already compromised system, and the person who talks to law enforcement if a tester is stopped. Agree on how sensitive findings are sent, for example by an encrypted channel and not in plain email.

6. Stop conditions

Define when testing pauses or ends. Common triggers include a service outage or degraded performance, discovery of an active intrusion by someone else, access to data the test was not meant to touch such as health records or card numbers, a request from the owner, and any sign the testers have left scope. Also say what the testers do next: stop, record, notify the contact and wait for instructions.

7. Data handling, evidence and reporting

• What data testers may view or copy, how long they keep it, how it is encrypted, and how it is destroyed.
• What the report will contain, who receives it, and how findings are rated.
• Whether a retest is included after fixes.
• Confidentiality of the findings and of any personal data seen.

8. Third parties and platforms

Cloud and hosting providers publish their own testing policies, and some require notice or prohibit certain actions. Managed service providers, software vendors and landlords may need to consent. Systems that process data for other organizations raise contract questions. Identify these before the test and record the consent in the file.

9. Liability, insurance and law

Your counsel should review indemnification, limits of liability, insurance for the testers and the company, and how the agreement relates to existing contracts and any applicable law. Some sectors have testing expectations in their own rules. This is where legal advice, not a template, is needed.

A short checklist

Authority confirmed, scope and exclusions listed, window set, techniques approved, contacts and escalation named, stop conditions written, data handling agreed, third parties cleared, counsel has reviewed, and everyone has a signed copy. Our cybersecurity team starts every engagement with verification and written authorization, then works only within the scope you approve. Start with our Cybersecurity service.

Sources

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide
• OWASP Top 10:2021

This article is general information, not legal advice. Have your counsel review any authorization before testing begins. Rules differ by state, sector and contract. Last reviewed November 9, 2026.

Keep reading

Next · SecurityWhat a Code and Endpoint Security Review Finds in the First 24 HoursMost first-day findings are not exotic. They are leaked credentials, outdated libraries, missing authorization checks and files that should never have been public. Here is what to expect, and why an engineer must confirm each one.7 min read

• Before Anyone Scans Your Website: Verification and Written Authorization7 min
• Hardening On-Premises Microsoft Exchange in 20268 min