What Is Red Team Authorization?
Red team authorization is the formal legal permission for a controlled adversarial security exercise in which the organization deliberately limits who knows the test is happening.
Unlike a standard penetration test, the authorization must account for secrecy, physical access, social engineering, lateral movement, law-enforcement escalation, and emergency contacts.
The authorization should be signed by an executive with authority over the systems and facilities being tested who is not part of the defensive team being evaluated.
The Paradox at the Center of Red Team Authorization
A red team engagement tests whether an organization's security team can detect and respond to a real attack. For the test to be valid, the security team being tested, the blue team, cannot know the test is happening.
This creates an authorization paradox: the people who would normally review, approve, and sign the authorization letter are exactly the people who must be kept in the dark.
Solve this wrong and one of two things happens. Either the blue team finds out (test is ruined), or no one with adequate authority knows the engagement is authorized (testers face legal exposure if caught). Both outcomes defeat the purpose of the engagement.
Red team authorization letters solve this through compartmentalization — a restricted knowledge model where authorization flows from a small number of executive-level stakeholders who are explicitly not part of the blue team.
Red Team Authorization vs. Penetration Test Authorization
A red team authorization letter is not simply a penetration test authorization letter with stricter confidentiality.
The two engagements have different operational and legal requirements because a red team may deliberately interact with people, facilities, and defensive systems that are not aware the test is occurring.
Authorization Element | Standard Penetration Test | Red Team Engagement |
|---|---|---|
Primary objective | Identify and validate vulnerabilities | Test whether an organization can detect, respond to, and contain a realistic attack |
Who normally knows | Security, IT, system owners, and testing stakeholders | Restricted executive and legal group; blue team may be intentionally excluded |
Signing authority | CISO, CTO, security executive, or delegated authority | Executive sponsor with authority over the target and independence from the blue team being tested |
Scope | Applications, APIs, infrastructure, cloud assets, or other defined systems | Technical systems plus potentially physical locations, personnel, identities, and defensive controls |
Social engineering | Usually excluded or separately authorized | May be explicitly authorized |
Physical access | Usually excluded or separately authorized | May include offices, facilities, badge systems, tailgating, or other approved techniques |
Lateral movement | Usually limited to defined technical targets | May be authorized as part of the attack path, subject to explicit boundaries |
Blue-team awareness | Usually expected | Often intentionally restricted |
Emergency contact | Testing firm's emergency contact and client security contact | 24/7 executive sponsor who can immediately confirm the operation |
Law-enforcement escalation | Addressed in emergency procedures | Must explicitly define how authorization is verified if law enforcement responds |
Rules of engagement | Define permitted testing techniques and timing | Must additionally define secrecy, detection response, stop conditions, physical and social-engineering boundaries |
Evidence of authorization | Signed authorization and scope documentation | Signed authorization, restricted knowledge list, rules of engagement, emergency contacts, and any required third-party/cloud approvals |
Who Can Sign: The Compartmentalization Problem
Standard penetration test authorization letters are often signed by the CISO, CTO, or another executive with documented authority over the systems being tested.
Red team engagements require more care because the person authorizing the engagement should not be part of the defensive team whose ability to detect the operation is being evaluated.
The signing authority rule for red teams:
The authorization letter must be signed by someone who is not part of the group being tested. Specifically:
If the CISO manages the SOC being tested → CISO cannot sign
If the entire security team is being evaluated → must go to CEO or board level
If the security team manages but doesn't operate the test target → CISO may sign if operationally separate from the blue team
The key principle is not "the CEO must always sign." It is that the signer must have actual authority over the assets and activities covered by the engagement and must be outside the operational group whose detection and response capabilities are being tested. If authority has been delegated, retain documentation showing that delegation.
In practice, most red team authorizations require CEO or board-level signature because the whole point of the engagement is to test the security function. The CISO who manages that function cannot objectively authorize their own team's evaluation.
Cloud Provider Authorization: AWS, Azure, and GCP
Red team authorization does not automatically give you permission to perform every activity against infrastructure hosted by a cloud provider. The organization authorizing the engagement must also account for the cloud provider's current acceptable-use, penetration-testing, and abuse-response policies.
Before testing begins, identify every cloud provider hosting an in-scope asset and verify its current requirements. Document the provider, account or subscription, regions, services, testing window, and any notification or approval requirements in the rules of engagement.
AWS
AWS permits security testing against many AWS services without prior approval, subject to its current policies and restrictions. Some activities and services have additional requirements or restrictions. The engagement owner should review AWS's current penetration-testing policy before testing and document any services or techniques that require additional handling.
Microsoft Azure
Azure has its own rules governing penetration testing and security testing against Microsoft-hosted services. The authorization package should identify the Azure subscriptions, resources, testing window, and approved activities, and the engagement team should verify Microsoft's current requirements before testing.
Google Cloud
Google Cloud also publishes requirements governing security testing of customer-controlled resources. The engagement owner should confirm that the proposed red team activities are permitted under Google's current policies and document the relevant projects, resources, regions, and testing boundaries.
What to Document
For every cloud provider in scope, record:
Cloud provider and account, subscription, or project identifier
Specific regions and resources in scope
Approved testing window
Approved attack techniques
Explicitly prohibited techniques
Cloud-provider notification or approval requirements
Emergency contact information
Executive authorization
Rules for handling provider abuse or security escalations
Stop conditions
Cloud authorization should be treated as a separate verification step, not assumed to be covered by the client's signed authorization letter. Cloud-provider policies change, so verify the current requirements immediately before the engagement rather than relying on a previous year's documentation.
The Sealed Envelope Approach
For organizations where legal, timing, or organizational dynamics make it difficult to get executive signatures at engagement start, the sealed envelope approach provides a practical solution.
For a standard penetration test, the authorization letter can usually be distributed to the relevant security and IT stakeholders.
Red team engagements require a more restricted model. See the penetration test authorization letter guide for the standard authorization structure, then adapt it for the additional secrecy, physical-access, social-engineering, and escalation requirements of a red team.
The envelope is opened only if:
A legal issue arises during the engagement
Law enforcement becomes involved
The organization faces an inquiry requiring documented authorization
This approach allows the engagement to proceed with strict compartmentalization while ensuring documented authorization exists and can be produced if needed.
The Get-Out-of-Jail Card
For engagements involving physical access or social engineering, every field operator should carry a physical authorization card or equivalent documentation that can be used to verify the engagement immediately if challenged by security personnel or law enforcement.
This is separate from the full authorization letter (which may be sealed) and serves as immediate verification during a law enforcement or security encounter.
Critical requirements for the card:
Must reference a 24/7-reachable phone number, not an office number
Must include an authentication code the contact can verify
Contact named must be the executive sponsor, not the security team
Every individual operating in the field must carry one
Physical copy: Carry a printed copy rather than relying solely on a phone or other device that may be inaccessible during an incident.
Red Team Rules of Engagement: What Must Be Defined Before Testing
The authorization letter establishes permission. The rules of engagement establish the boundaries within that permission. For a red team, both documents are essential.
The rules of engagement should define:
Objectives: What capability is being tested — detection, response, containment, physical security, identity controls, or the full attack lifecycle?
In-scope targets: Domains, IP ranges, applications, cloud accounts, offices, facilities, identities, and other assets that may be targeted.
Out-of-scope targets: Systems, subsidiaries, customers, third parties, production services, or individuals that must not be touched.
Permitted techniques: Phishing, vishing, physical access, badge testing, credential attacks, exploitation, persistence, lateral movement, or other techniques explicitly approved for the engagement.
Prohibited techniques: Techniques that could cause unacceptable operational, legal, or safety risk.
Testing window: Exact start and end dates, including any restrictions on physical activity or high-risk techniques.
Data handling: What happens if the team obtains credentials, customer data, employee information, or other sensitive material.
Persistence: Whether persistence is permitted, where it may be established, and when it must be removed.
Detection protocol: What happens when the blue team identifies or contains the operation.
Stop conditions: The events that require immediate suspension of testing.
Emergency contacts: The executive sponsor and backup contacts who can authorize an immediate pause or termination.
Law-enforcement response: How the engagement will be verified if police or another authority becomes involved.
Third-party boundaries: How cloud providers, managed service providers, building owners, or other third parties are handled.
Evidence preservation: What the red team must retain to demonstrate what happened during the exercise.
Cleanup: Required removal of accounts, persistence mechanisms, files, payloads, or other artifacts at engagement close.
Handling Blue Team Detection and Response
The authorization letter must address what happens when the blue team detects the red team and escalates. This is one of the most important scenarios that standard penetration test letters don't cover.
Scenario 1: Blue team detects activity but doesn't escalate to law enforcement Define whether red team should "break character." Most engagements specify that if the blue team detects and contains the attack without law enforcement, the red team continues as if undetected unless told to stop by the executive sponsor.
The rules of engagement should define detection thresholds and stop conditions before the exercise begins. The red team should not improvise these decisions after the blue team detects the operation.Scenario 2: Blue team escalates to internal security leadership (CISO) Define whether the CISO is in the "knows" group or the "doesn't know" group. If the CISO doesn't know, they may escalate to law enforcement thinking it's a real attack. The authorization letter must include a procedure for the executive sponsor to intervene at this point.
Scenario 3: Blue team calls law enforcement This is the Coalfire scenario. Law enforcement arrives. Red teamers are detained. The get-out-of-jail card is the first line of resolution. The executive sponsor contact is the second. The letter must specify that the executive sponsor is available 24/7 to confirm the engagement directly to law enforcement.
Scenario 4: Blue team successfully detects and stops the attack Define what happens to the engagement. Does it reset? Does testing end? Is a debrief triggered? The authorization letter should set the parameters so the executive sponsor doesn't have to make this decision under pressure.
Pre-Defined Stop Conditions
At minimum, define whether the engagement must immediately pause when:
production availability is materially affected
customer data may be at risk
a third party is inadvertently affected
law enforcement becomes involved
the blue team activates an emergency response procedure
the red team reaches a prohibited system or technique
the executive sponsor or designated safety contact orders a stop
What the Red Team Letter Must Include That Standard Letters Don't
Compartmentalization section: Explicitly list who knows the engagement is occurring and who must not be informed. Named individuals in each category. This protects both the engagement validity and the organization if the blue team later claims they weren't properly notified.
Executive sponsor 24/7 availability confirmation: The executive sponsor must confirm in writing that they will be reachable throughout the engagement window. Unlike standard engagements where emergency contact is a secondary concern, in red team this is a primary operational requirement.
Blue team response protocol: What should happen at each stage of blue team detection — continue, pause, stop, debrief. Without this, the executive sponsor faces real-time decisions they shouldn't have to make without prior guidance.
Law enforcement pre-notification decision: Some organizations choose to pre-notify local law enforcement that a red team is operating. This is the single most effective measure for preventing arrest scenarios. Document whether this was done and who was notified.
Physical access scope, precision matters: Physical red team engagements require the most precise scope definition of any engagement type. "The company's offices" is not sufficient. List specific addresses, floors, access types, and whether tailgating, badge cloning, and other physical techniques are in scope.
Cloud-provider authorization: Identify every cloud provider and in-scope account, subscription, or project, and document that the engagement team verified the provider's current security-testing requirements before testing.
Rules-of-engagement reference: The authorization should explicitly incorporate or reference the signed rules of engagement so there is no ambiguity about which techniques, targets, time windows, and escalation procedures are authorized.
Stop and termination authority: Name the person who can immediately pause or terminate the engagement and define the circumstances under which the red team must stop without waiting for further approval.
Red Team Authorization Is About Control Without Visibility
A standard penetration test is about permission. A red team engagement is about permission under controlled secrecy. That difference changes everything.
Authorization cannot be broad. It cannot be assumed. It cannot follow the same structure used for standard testing. Because the moment the wrong people know about the engagement, the test loses its value. And the moment the right people do not formally authorize it, the engagement carries real legal risk.
This is the balance red team authorization must achieve. Limited awareness. Explicit authority. Clear escalation paths. The organizations that do this well treat authorization as part of the engagement design, not as documentation that comes after. They define who knows, who does not, and who can intervene before testing begins.
If you get this right, the engagement runs exactly as intended. Realistic, controlled, and defensible.
If you get it wrong, you either lose the test or expose your team.
And in red team engagements, there is no middle ground.
