What must a signed red-team authorisation letter contain for a SOC analyst to act on it at 02:00?
answer
- two audiences: lawyers and the night shift
- scope stated in both directions
- window needs a time zone
- addresses and markers, not just clauses
- authorises activity, identifies nobody
basics
~20 sTwo halves: the legal core — a signatory with authority, in-scope and explicitly out-of-scope systems, a dated window, prohibited actions — and fields a defender can check an alert against: operator source addresses, test markers, out-of-band deconfliction numbers.
solid answer
~50 sThe letter serves two audiences. The legal half names the parties, the signatory who actually has authority over every system in scope, the exact in-scope inventory (address ranges, domains, tenants, accounts, sites) and an explicit out-of-scope statement, the engagement window with dates, times and time zone, prohibited actions such as destructive changes or touching real customer data, and how anything the operators collect is stored, returned or destroyed. The operational half is what makes it usable during a response: the operator source addresses, agreed test markers and file-naming conventions, the deconfliction contacts with out-of-band numbers, and the cleanup-and-evidence obligation. Note the limit — the letter authorises activity, it does not identify an actor. Matching a source address to the operator range says the traffic came from an address the exercise was expected to use, not that the exercise sent it.
go deeper
Know that testing without signed, specific written authorisation is not a job you take, and be able to name the obvious contents: who signed, what is in scope, what is out, and when the window runs.
Explain the operational fields a defender can actually use — source addresses, markers, window with a time zone, deconfliction numbers — and why an explicit out-of-scope statement is not redundant.
Demonstrate the limit: the letter authorises but identifies nobody, so a source-address or marker match raises probability rather than settling a verdict, and the exercise window is when a real intruder is hardest to see.
Own the awkward scope conversations: third-party platforms the client cannot consent for, subsidiaries, regulated data, and who in the business is genuinely able to sign for the estate you are about to have attacked.
## Why the letter has two halves A red-team authorisation letter — often called the rules of engagement, or informally the get-out-of-jail letter — is usually written by lawyers for lawyers. That version protects the testing firm and the client, and it is useless at 02:00. A good letter carries a second half written for the people who will be holding an alert: the sponsor, the trusted agents, and whoever ends up reading it during a response. ## The legal core - **Parties and signatory.** A named individual who has authority over *every* system listed. This is where scope quietly breaks: an estate includes a hosted platform, an identity provider's tenant, a managed service run by a third party. The client cannot consent on behalf of a provider it does not own; those systems need their own authorisation or must be carved out. - **Scope, stated in both directions.** An in-scope inventory (address ranges, domains, cloud accounts and tenants, account sets, physical sites, and whether subsidiaries are included) *and* an explicit out-of-scope statement. Silence is read as permission by operators and as trespass by system owners afterwards. - **Window.** Dates, times and a time zone. "The week of the 9th" is not a window a defender can compare an alert's timestamp against. - **Prohibited actions.** Typically: no destructive changes, no denial of service, no modification or disabling of production security controls unless explicitly listed, no interaction with real customer or personal data — decoy data is planted instead. - **Data handling.** What the operators may collect, how it is encrypted and stored, when it is returned or destroyed, and the certificate that evidences the destruction. ## The operational half, and this is the part that gets left out - **Operator source addresses** and any infrastructure they will originate from. - **Test markers**: an agreed string in file names, a distinctive user-agent, a naming convention for planted accounts and scheduled tasks, a comment field. Markers are what makes activity recognisable *later*, during cleanup verification and during the report reconciliation. - **Deconfliction contacts** on both sides with alternates and out-of-band numbers. - **The cleanup and evidencing obligation**: an inventory of everything planted, and proof it was removed. - **A statement that the client's own responders are expected to respond.** Defenders who suspect a test sometimes hesitate; the letter should say plainly that acting on what they see is correct behaviour and will not be second-guessed. ## Who holds it The letter is normally held by the sponsor and a small trusted-agent group, not distributed to the SOC — an estate whose defenders have all read the scope letter is no longer measuring what the exercise was built to measure. That is exactly why the deconfliction contact matters: the analyst's route to the letter's contents is a person, not a document in a shared drive. ## The limit every candidate should state **The letter authorises; it does not identify.** Four traps follow from this: 1. **Source addresses are weak evidence of identity.** They can be spoofed, reused after the engagement, or shared with something else in the same hosting range. A match says the traffic came from an address the exercise was expected to use. 2. **Markers are copyable.** Anyone who has seen one can plant it. A marker raises the probability that activity is test traffic; it does not settle it. 3. **Being in the window means nothing on its own.** A genuine intruder inside the exercise window is exactly the case the whole arrangement has to survive. 4. **In-scope is not the same as ours.** An in-scope host can be attacked by someone else on the same night. So the letter is one input to a verification, alongside a deconfliction call rooted in a pre-recorded contact. Treated as proof on its own, it becomes the intruder's best friend: a defender who stands a case down because the activity "fits the scope letter" has been persuaded by a document that never claimed to identify anybody. ## What good looks like A letter a defender can use has, on one page: window with time zone, in-scope and out-of-scope lists, operator addresses, markers, two phone numbers, and one sentence saying respond as you normally would. Everything else can live in the twelve pages behind it.
- The scope includes a SaaS identity provider and a managed hosting platform the client does not own. What changes?The client cannot authorise testing of somebody else's systems. Either the provider gives its own written permission under its testing policy, or those systems come out of scope and the engagement is designed around them — for example testing the client's own tenant configuration and detections rather than the provider's infrastructure. Proceeding on the client's signature alone exposes the operators personally.
- Should the SOC be given a copy of the authorisation letter before the exercise?Normally no — defenders who have read the scope, the addresses and the markers cannot produce an honest response, and the exercise stops measuring anything. The letter sits with the sponsor and a small trusted-agent group, and the SOC's route to it is the deconfliction contact. What the SOC should have in advance is the escalation path to that group.
- Why include an explicit out-of-scope statement when the in-scope list is already complete?Because the in-scope list is never complete. Estates contain systems nobody remembered, shared ranges, subsidiaries, and third-party tenants. An explicit exclusion for named systems, data classes and techniques removes the argument after the fact, when an operator's reasonable reading of an omission has become somebody's outage or somebody's regulated data.
saying these in an interview costs you the question
- Treats the letter as proof that observed activity is the red team
- Lists in-scope systems and no out-of-scope statement
- Window given as dates only, with no times or time zone
- Assumes the client can authorise testing of a third-party platform
- Omits operator addresses, markers and deconfliction numbers
- Distributes the letter to the SOC and still calls the test realistic