What are rules of engagement in a red team engagement?

The document that authorises the testing and records its limits. It names the person consenting, the systems and windows in scope, permitted and forbidden techniques, stop conditions, the deconfliction contact and out-of-band channels, and how collected data is stored and destroyed. It is separate from the commercial statement of work because it needs to be short enough to read at speed during an incident.

Who can authorise a penetration test or red team?

Someone with authority over every asset in scope. That is straightforward for infrastructure you own and often impossible for a SaaS tenancy, a payment provider, a managed endpoint service or a shared datacentre, where the provider's contract decides whether you may authorise testing. Build a scope table with an owner column before signature, and turn every row you cannot complete into an exclusion.

Do you need cloud provider permission to test?

It depends on what you are testing, and red team activity is often the part that needs asking about. Major providers permit customer-initiated testing of resources you control, but AWS requires a Simulated Events form for covert adversarial simulation, command and control hosting, and simulated phishing or malware testing, filed at least two weeks before the start date. Microsoft no longer requires notification to test your own Azure tenant, though DDoS resilience testing must run through a Microsoft-approved simulation partner. No policy extends to the provider's control plane, other tenants, or managed services where your configuration and their platform blur, so read the current one during scoping rather than relying on a previous engagement.

How should container and Kubernetes scope be written?

In terms of namespaces, service accounts and objectives rather than IP ranges, because one cluster commonly hosts several teams. State whether the control plane API is a target or a boundary, whether escaping to the node is permitted, whether node cloud credentials may be used if obtained, and whether reaching another team's namespace is authorised or must be reported and stopped.

What is deconfliction in a red team exercise?

The process that lets defenders find out whether suspicious activity is the exercise without learning the scope. A single trusted contact can confirm or deny that a given indicator belongs to the test, logs every request, and shares that log at the debrief. The log is itself useful evidence, because each query records a moment when someone noticed something.

What happens to data a red team collects during testing?

It should be minimised, encrypted, inventoried and deleted on a stated schedule with written confirmation. Prefer proof of access, such as a directory listing and a file hash, over copies of files. Where staff or customer personal data is involved, the lawful basis and any consultation requirement depend on jurisdiction, so agree with counsel what may be processed and stored before the engagement begins.

Red teaming guide

Red team rules of engagement: the clauses that matter

A statement of work is not authorisation. The rules of engagement are the document that makes the activity lawful, tells the testers where to stop, and tells you who to ring at three in the morning, and it is separate from the commercial contract for a reason. Most engagements that go wrong do so because a boundary was assumed rather than written, and almost all of those boundaries involve somebody else's systems.

What does the rules of engagement document actually do?

It converts activity that would otherwise be unlawful into authorised testing, and it records the limits of that authorisation. Unauthorised access to computer systems is a criminal matter in most jurisdictions, under the Computer Misuse Act in the United Kingdom and comparable statutes elsewhere, and consent from a person with the authority to give it is what distinguishes a test from an offence. That consent has to name the systems, the window and the techniques.

It is also the operational document. Stop conditions, the deconfliction contact, out-of-band communication channels, evidence handling rules and the escalation path all live here, because they need to be readable at speed by someone who was not in the scoping meeting. Keep it short enough that the on-call engineer can read it in five minutes.

One structural point is worth making early. The rules of engagement protect the testers as much as they protect you, which is why a competent supplier insists on them and will not start without a signature from someone whose authority they can verify. A supplier willing to work from a verbal go-ahead is telling you how they will behave when a boundary turns out to be ambiguous at two in the morning.

Treat it as living. Red teams discover systems nobody mentioned, and the correct response is a written scope amendment before touching them, not a judgement call at the keyboard. If your supplier is comfortable extending scope on a verbal nod, that is a supplier who will be comfortable doing it when the system in question turns out to belong to a customer.

Which clauses matter most?

The ones below cause the arguments. Every row represents a real failure mode rather than boilerplate, and the third column is what happens when the clause is missing or vague.

Clause	What it must state	What goes wrong without it
Authorisation and signatory	A named person with authority over every in-scope asset	Testing against systems nobody could lawfully authorise
Scope boundaries and exclusions	Address ranges, domains, cloud accounts, clusters, plus explicit exclusions	A tester reaches a neighbouring tenant or a customer environment
Third party consent	Which providers were notified or gave prior approval, and the evidence of it	A hosting or SaaS provider treats the test as a live attack
Deconfliction and stop conditions	A reachable contact, a phrase that halts activity, and who can use it	A real incident and the exercise get investigated as one event
Evidence and data handling	Proof-of-access limits, storage, encryption, retention and deletion	Live personal data or credentials sitting on a supplier laptop
Personnel limits	Named exclusions, no coercive pretexts, no personal devices or homes	A staff welfare complaint that ends the programme
Insurance and liability	Cover level, and who bears the cost of an outage caused by testing	An unbudgeted argument after something breaks

Who has to sign, and can they?

Someone with authority over every asset in scope, which is rarely one person and is often nobody in the room. Your own infrastructure is straightforward. A SaaS tenancy you rent, a payment gateway, a managed service provider running your endpoints, or a datacentre you share are all systems where your contract may not permit you to authorise testing, and where the provider's terms decide the answer.

Cloud accounts are a partial exception worth understanding, and the exception is narrower than it looks for red teaming in particular. The major providers permit customer-initiated testing of the resources you control, subject to a published policy, and that covers your instances and your workloads. What the policies hold back for prior arrangement is the part that catches red team buyers out. AWS requires a Simulated Events form for covert adversarial simulation and for hosting command and control infrastructure, as well as for simulated phishing and malware testing, and it must be submitted at least two weeks before the start date. On AWS, in other words, the engagement this guide describes is itself the reserved category, not just the denial of service test everybody remembers. Microsoft's position differs: notification is no longer required to test your own Azure tenant, while DDoS resilience testing has to run through a Microsoft-approved simulation partner rather than your own testers.

Neither policy covers the provider's own control plane, other tenants, or managed services where the boundary between your configuration and their platform is unclear. Read the current policy at scoping time rather than relying on what was true at the last engagement, and if a covert engagement is planned on AWS, put the form in before you book the testers.

The practical step is a scope table with an owner column, filled in before signature, where every entry has a named internal owner and a note on whether third party consent is required and obtained. Any row you cannot complete becomes an exclusion. This is dull work and it is the single most common reason engagements are delayed, so start it a month early.

How do containers and shared platforms change scope?

They break the assumption that scope can be drawn around a network. A Kubernetes cluster commonly hosts several teams, sometimes several business units, and occasionally workloads processing data with different legal constraints. Naming the cluster as in scope quietly authorises reaching anything in it, which is not what the person signing usually intends.

Write cluster scope in terms of namespaces, service accounts and objectives rather than IP ranges. State whether the control plane API is a target or a boundary, whether escaping a container to the node is permitted, whether the node's cloud instance credentials may be used if obtained, and whether lateral movement into namespaces belonging to other teams is authorised or must be reported and stopped. The interesting finding is usually that the escape is possible, and you do not need the team to keep going to prove it.

Add two clauses specific to this environment. First, CI/CD systems: a build pipeline with deployment credentials is one of the most valuable targets in a modern estate, and pipelines often deploy to environments outside the agreed scope, so state explicitly whether the pipeline may be used to deploy. Second, secrets: if a token, kubeconfig or cloud key is captured, the rules should require immediate notification and rotation at the end of the engagement, with the captured material handled as live credentials rather than as evidence.

How do you write stop conditions people will use?

Make them specific and make them cheap to invoke. A stop condition phrased as a judgement about materiality will not be used, because nobody wants to be the person who halted a paid exercise. A stop condition phrased as an event will be: a production service degrades, a safety system is implicated, personal data would have to be moved to prove access, a regulator or law enforcement becomes involved, or a genuine unrelated incident begins.

Name the mechanism as well as the trigger. That means a trusted contact reachable outside working hours by a channel independent of the systems under test, a second contact for when the first is unreachable, and an agreed phrase or code that means stop now and explain later. Testing that channel before the engagement starts is a five minute job that occasionally saves a weekend.

Agree in advance what happens after a stop. Does the engagement pause and resume, does the commercial clock stop, and who decides that the cause has been resolved? Without those answers a stop condition becomes a negotiation at the worst possible moment, which is precisely when nobody should be negotiating.

Deconfliction deserves its own paragraph in the document. Your defenders will see something and need to know whether it is the exercise, and they must be able to find out without learning the whole scope. The usual pattern is that a single trusted agent can confirm or deny that a given indicator belongs to the test, keeps a log of every such request, and shares that log at the debrief because it is itself a detection record.

What happens to the data the red team collects?

It has to be minimised, encrypted, and destroyed on a stated schedule, and the rules of engagement should say so in terms you could show a data protection officer. Red teams accumulate credential material, screenshots containing personal data, extracts from file shares and internal documents, all of which is your risk sitting on someone else's laptop.

Specify four things. Proof of access rather than proof of exfiltration wherever possible, meaning a directory listing and a file hash instead of a copy of the file. An inventory of anything that was copied. Encryption at rest and a named location, with a note on which country the data sits in, because that determines which rules apply. And a deletion deadline after report acceptance, with written confirmation.

Where personal data is involved the position is jurisdictional and worth a short conversation with counsel rather than an assumption. Under European and United Kingdom data protection law, testing that processes staff or customer personal data needs a lawful basis and may need a documented assessment, and employee monitoring in some countries requires consultation with a works council before it begins. The question to put to counsel is narrow: what may the testers process, where may it be stored, and who must be informed before rather than after.

Common questions

What are rules of engagement in a red team engagement?: The document that authorises the testing and records its limits. It names the person consenting, the systems and windows in scope, permitted and forbidden techniques, stop conditions, the deconfliction contact and out-of-band channels, and how collected data is stored and destroyed. It is separate from the commercial statement of work because it needs to be short enough to read at speed during an incident.
Who can authorise a penetration test or red team?: Someone with authority over every asset in scope. That is straightforward for infrastructure you own and often impossible for a SaaS tenancy, a payment provider, a managed endpoint service or a shared datacentre, where the provider's contract decides whether you may authorise testing. Build a scope table with an owner column before signature, and turn every row you cannot complete into an exclusion.
Do you need cloud provider permission to test?: It depends on what you are testing, and red team activity is often the part that needs asking about. Major providers permit customer-initiated testing of resources you control, but AWS requires a Simulated Events form for covert adversarial simulation, command and control hosting, and simulated phishing or malware testing, filed at least two weeks before the start date. Microsoft no longer requires notification to test your own Azure tenant, though DDoS resilience testing must run through a Microsoft-approved simulation partner. No policy extends to the provider's control plane, other tenants, or managed services where your configuration and their platform blur, so read the current one during scoping rather than relying on a previous engagement.
How should container and Kubernetes scope be written?: In terms of namespaces, service accounts and objectives rather than IP ranges, because one cluster commonly hosts several teams. State whether the control plane API is a target or a boundary, whether escaping to the node is permitted, whether node cloud credentials may be used if obtained, and whether reaching another team's namespace is authorised or must be reported and stopped.
What is deconfliction in a red team exercise?: The process that lets defenders find out whether suspicious activity is the exercise without learning the scope. A single trusted contact can confirm or deny that a given indicator belongs to the test, logs every request, and shares that log at the debrief. The log is itself useful evidence, because each query records a moment when someone noticed something.
What happens to data a red team collects during testing?: It should be minimised, encrypted, inventoried and deleted on a stated schedule with written confirmation. Prefer proof of access, such as a directory listing and a file hash, over copies of files. Where staff or customer personal data is involved, the lawful basis and any consultation requirement depend on jurisdiction, so agree with counsel what may be processed and stored before the engagement begins.