Your SOW is Not a Pentest Authorization Letter: Here is Why It Matters

The Confusion That Creates Legal Gaps

Many organizations treat their penetration testing statement of work (SOW) as their authorization document. Their procurement process generates a SOW, the SOW gets signed, and the team assumes authorization is covered.

This is not always wrong. A well-drafted SOW can include authorization language. But most SOWs don't, they're commercial documents covering scope, pricing, deliverables, and IP. The authorization language that makes testing legally permissible is different from the commercial terms that govern the engagement.

When things go wrong, law enforcement arrives, a service goes down, a dispute arises about scope, the distinction matters.

What Each Document Does

Statement of Work (SOW):

A statement of work is a commercial contract between a client and a testing firm. It defines the business relationship. It answers what is being delivered and under what terms. A typical SOW includes:

• Description of services

• Deliverables and timelines

• Pricing and payment terms

• Intellectual property ownership

• Termination conditions

• Liability caps and indemnification

In simple terms, the SOW answers: What are we paying for and what are we getting in return

It does not inherently answer whether the testing activity itself is legally permitted. The SOW answers: "What are we paying for and what are we getting?"

Authorization Letter (also: Rules of Engagement, Permission Letter):

An authorization letter is a legal permission document. It defines what actions the testing team is explicitly allowed to perform on specific systems within defined boundaries.

It exists because penetration testing involves actions that, without authorization, could be treated as unauthorized access under applicable laws. A complete authorization letter typically includes:

• Explicit authorization statement

• Clearly defined in-scope systems

• Out-of-scope exclusions

• Named individuals allowed to test

• Permitted and restricted techniques

• Testing window and timing

• Emergency procedures

• Data handling rules

• Cloud provider compliance

• Legal acknowledgment and signatures

This document answers: Are these activities allowed, who approved them, and under what conditions

Where They Overlap (and Where They Don't)

Can You Combine Them Into One Document?

Yes, and some professional firms do this by default, creating a combined "Penetration Testing Agreement and Rules of Engagement" that serves both purposes.

For combination to work, the document must include all required elements of both. The commercial terms (pricing, IP, payment) and the authorization terms (explicit authorization, named individuals, emergency procedures, techniques matrix) must all be present.

The risk of combination: commercial terms are frequently revised (pricing changes, scope additions, timeline extensions) while authorization terms should remain stable. If the combined document gets amended for commercial reasons, someone needs to verify that the authorization terms aren't inadvertently affected.

For most organizations, keeping them separate is simpler and lower-risk.

The Minimum Authorization Letter (When You Have an SOW)

If your SOW already covers commercial terms comprehensively, the authorization letter can be a focused document covering only the authorization-specific elements:

This minimum letter combined with a comprehensive SOW provides adequate legal and operational coverage for most standard engagements.

When You Should Not Use a Minimum Letter

• Red team engagements: Need the full emergency procedure detail because blue team response is expected and must be handled specifically.

• Physical security testing: Needs precise physical scope, law enforcement pre-notification documentation, and the get-out-of-jail card provisions.

• Multi-cloud environments: Need detailed cloud provider authorization status per provider.

• Regulated industries: HIPAA, PCI, FedRAMP engagements benefit from the full letter's documentation of regulatory-specific provisions for audit evidence.

• First engagement with a new firm: Use the full letter to establish the relationship clearly.

What Your Legal Team Will Ask For

If your legal team reviews the documentation package, they will typically want:

1. A signed document that explicitly states the testing activities are authorized

2. Clear identification of who authorized them and their authority level

3. Named individuals (not just the firm)

4. Explicit scope with out-of-scope exclusions

5. Indemnification provisions (which may be in the SOW)

6. Governing law

Items 1-5 must be present regardless of whether they're in the SOW or the authorization letter. If your SOW covers all of them, your legal team may be satisfied with the SOW alone. If it doesn't, the authorization letter fills the gaps.

Where Traditional Authorization Models Break with AI Driven Testing

Traditional authorization models assume that testing is controlled, linear, and human-driven. AI-driven testing changes that assumption.

AI systems can explore systems in non-linear ways, chain vulnerabilities across services, and interact with infrastructure at a scale that was not possible before.

This increases the likelihood of:

• Unintentional access to out-of-scope systems

• Interaction with third-party services

• Triggering cloud provider abuse detection

• Generating traffic patterns that were not explicitly planned

Authorization documents written for manual testing often do not account for this behavior. This creates a gap between how testing is defined and how it actually executes.

Why This Matters More for AI Driven Penetration Testing

AI-driven penetration testing introduces a new layer of risk. Automation increases speed, coverage, and exploration depth. But it also increases the chance of crossing boundaries that were not clearly defined.

Without strong authorization controls, AI systems can unintentionally move beyond permitted systems or interact with environments that require separate approval. This makes clarity in authorization more important than ever.

The becomes the control layer that governs how testing, whether manual or automated, is allowed to operate.

How to Adapt Authorization for AI Based Testing

Authorization documents must evolve to support AI-driven testing safely.

This includes:

• Defining scope in terms of systems and interaction boundaries

• Restricting automated chaining across third-party systems

• Strengthening out-of-scope handling procedures

• Explicitly addressing cloud provider compliance for automated traffic

• Defining limits on automated exploitation and data access

The goal is not to reduce testing effectiveness. The goal is to ensure that increased automation does not create unintended legal or operational exposure.

Commercial Agreement Does Not Equal Authorization

A statement of work defines what will be done. An authorization letter defines what is allowed.

That distinction is easy to overlook because both documents reference the same engagement. They describe the same systems, the same timelines, and the same testing activities. But they serve fundamentally different purposes.

• One governs the business relationship.

• The other governs legal permission to perform actions that would otherwise be considered unauthorized.

This is where gaps are created.

When organizations rely only on a SOW, they assume authorization is implied. In practice, that assumption only holds if the SOW explicitly includes authorization language, named individuals, and operational safeguards. Most do not.

The safest approach is clarity.

Use the SOW to define commercial terms. Use the authorization letter to define legal permission and operational boundaries. If you combine them, ensure nothing is missing when revisions happen. Because when something goes wrong, the question is not what was agreed commercially. The question is whether the activity was explicitly authorized.