AI Code Review
Penetration Test Authorization Checklist: 5 Elements You Cannot Miss
Sonali Sood
Founding GTM, CodeAnt AI
Why Letters That Look Complete Aren't
Most penetration test authorization letters cover the obvious elements: the scope, the testing firm, the signatures, some sense of what's in and out. They satisfy the visual requirements of looking like a serious document.
What they miss are the elements that matter when something goes wrong, when law enforcement arrives, when a tester accidentally accesses a system outside scope, when a service goes down mid-engagement, or when the engagement discovers that someone else is already in the target environment.
These five elements are absent from the majority of authorization letters in practice. Each one has caused a real-world engagement failure.
1. The Safe Word Protocol
What most letters have: Emergency contact names and phone numbers.
What they miss: A pre-agreed authentication mechanism that proves, in real time, that the emergency contact is confirming a legitimate engagement and not being socially engineered.
When law enforcement stops your testers, they will call the number on the letter. They are calling a random phone number they found on a document, and they know that a sophisticated social engineer would have exactly this document and phone number ready. Law enforcement is trained to be skeptical.
A safe word solves this. The contact on the letter tells law enforcement: "The safe word for this engagement is BLUEKITE." Law enforcement asks the testers: "What's the safe word?" The testers answer. This completes a two-factor verification that the engagement is legitimate.
What to include:
2. The Accidental Out-of-Scope Access Procedure
What most letters have: A list of out-of-scope systems.
What they miss: Step-by-step instructions for what the tester does when they accidentally access something outside scope.
During real engagements, testers will sometimes follow an exploit chain into territory that wasn't anticipated in the scope definition. They exploit a server-side request forgery vulnerability and find themselves looking at an internal HR database. They follow a CORS misconfiguration and can read responses from a third-party payment system. What now?
Without explicit instructions, the tester is making a judgment call, continue, retreat, document, notify immediately? Each organization has different preferences and different risk tolerances.
What to include:
3. The Active Breach Discovery Protocol
What most letters have: Nothing. This scenario is almost universally absent from authorization letters.
What they miss: What the tester does when they discover that someone else, a real attacker, is already in the client's environment.
This happens more often than the industry acknowledges. A penetration tester is exploiting a vulnerability and finds that the exploit path is already compromised. They find backdoors they didn't install. They find data staging that looks like exfiltration in progress. They find attacker tools that aren't part of their engagement toolkit.
At this point, the engagement has become a real incident. The tester is not the right person to lead incident response. But they hold important forensic evidence, and what they do in the next few minutes matters enormously.
What to include:
4. Named Individual Authorization (Not Just Firm)
What most letters have: The name of the penetration testing firm.
What they miss: The names of the specific individuals authorized to conduct testing.
Naming the firm without naming the individuals means anyone at the firm could theoretically claim authorization. This matters in three specific scenarios.
First, law enforcement encounters: a named individual can be immediately verified against the letter. An unnamed individual claiming to work for the named firm cannot.
Second, scope disputes: if a specific tester exceeded scope, the letter establishes that only specific individuals were authorized — not a general grant to the firm's entire staff.
Third, subcontractors: many penetration testing firms use subcontractors for specialized testing. If subcontractors aren't named in the letter, their activities may not be covered by the authorization.
What to include:
5. The Self-Destruct Version Mismatch Check
What most letters have: Standard scope and data handling language.
What they miss: Specific forensic detection methodologies for supply chain attacks on the testing environment itself.
This sounds edge-case until you consider the axios npm compromise, where malware deleted itself after running, leaving only a version mismatch between the package lockfile (4.2.1) and what npm list reported (4.2.0) as the only forensic signal.
If your pentest team installs dependencies during engagement setup without checking for these signals, they may be conducting an engagement from a compromised environment, exfiltrating their own findings to an attacker C2.
What to include:
The Gaps Only Show Up When Things Go Wrong
Most authorization letters look complete when everything is going according to plan. The scope is defined. The signatures are in place. The testing begins without friction.
The real test of an authorization letter is not how it performs under normal conditions. It is how it holds up when something unexpected happens. When a tester accesses something they should not have. When law enforcement gets involved. When a service is disrupted. When the engagement uncovers something that was never part of the original plan.
That is where these elements matter.
Each of the five elements in this guide exists because of a real failure. A situation where the absence of a single clause created confusion, delay, or legal exposure. Adding them does not make the document longer for the sake of completeness. It makes the engagement predictable under pressure.
Before your next penetration test, review your authorization letter against these scenarios. If your document cannot answer what happens in each case, it is not complete. And in security testing, incomplete authorization is not a documentation issue.
It is an operational risk.
FAQs
Why are these elements missing from most authorization letters?
Is a safe word really necessary for penetration testing?
What is the risk of not defining accidental out of scope procedures?
How common is discovering an active breach during a pentest?
Why is naming individual testers important in the authorization letter?
Ship clean & secure code faster
Made with Love in San Francisco
355 Bryant St. San Francisco, CA 94107, USA
Ask AI for summary of CodeAnt
