When is an organisation ready for a red team?
When someone would be embarrassed by the result. A red team measures response, so it needs a response function to measure, and running one against an organisation that has no alerting produces a report saying the obvious thing at a high price. The readiness bar is lower than vendors imply and higher than most buyers assume, and it is testable in an afternoon.
What has to exist before a red team is useful?
Four things. Someone whose job includes looking at security alerts, whether in-house or outsourced. Logs that are actually retained and queryable, covering identity, endpoints and your cloud control plane. A written incident process, however short, that says who decides to isolate a machine at two in the morning. And a patching cadence good enough that the red team will not simply walk in through something six months old.
The reason all four are prerequisites rather than outcomes is that a red team generates its value at the comparison stage. Its report contains a timestamped list of actions. Yours contains what your people saw and when. Subtract one from the other and you have the finding. With no logs and no watcher, there is nothing to subtract, and the exercise degrades into an expensive penetration test with worse coverage.
A fifth prerequisite is rarely listed and often missing: somebody who can say yes. A red team forces decisions at awkward moments, about whether to isolate a production host or let activity continue for observation, and those decisions need a named person with standing authority. Organisations where every containment action requires a change board have a response time measured in days, which is worth knowing before you pay someone to measure it.
None of this requires a large team or a named platform. Plenty of organisations with one security person, an outsourced monitoring contract and ninety days of log retention get real value. What does not work is buying the exercise in the hope that it will create the capability.
When is a red team a waste of money?
When you already know the answer. If nobody is monitoring outside office hours, if endpoint alerts route to an unread mailbox, or if you have never rehearsed isolating a host, a red team will confirm it and you will have paid for the confirmation. Spend the money on the gap instead and test it next year.
It is also wasted when the organisation is mid-transition. A cloud migration in flight, a merger integration where two identity estates are being joined, or a platform rebuild all mean the thing you test will not exist in six months. Test after the change lands, and use the intervening time on the design decisions the red team would have criticised anyway.
The third waste is procedural: buying it as evidence. If a customer questionnaire or an auditor is driving the purchase, they almost certainly want scoped testing with stated coverage, not an objective-based exercise that deliberately leaves most of your estate untouched. Buying the wrong artefact means buying the right one afterwards.
The fourth is buying an exercise to confirm a decision already taken. If everyone involved knows the identity estate needs rebuilding, or that the cluster has no audit logging, a report saying so changes nothing except the cost of the project. Use testing to find out what you do not know, and use engineering time on what you do.
What readiness test can you run this week?
Execute one benign, well-documented attacker technique on one machine and time the response. Create a scheduled task with an unusual name, dump a harmless file from a process that never normally reads it, or run a discovery command sequence a real intruder would run. Then wait, and record three timestamps: when telemetry appeared somewhere, when a human looked at it, and when anyone contacted you about it.
Do the same in your container platform, because the answer is usually different. Exec into a running pod in a non-production namespace, list secrets with the pod's own service account, and call the cloud metadata endpoint. Then go looking for evidence in your Kubernetes audit log and your runtime sensor. Teams with mature endpoint detection are commonly blind here, because the agent lives on the node and nobody wrote rules for the control plane.
The result tells you which exercise to buy. If nothing was recorded, you need telemetry, not adversaries. If it was recorded but nobody looked, you need an owner and an alerting path. If someone rang you within the hour, you are ready for the real thing.
Which exercise fits which stage of maturity?
The ladder below is deliberately unflattering about the lower rungs, because the common failure is skipping two. Each stage has an exercise that returns information and one that returns a document nobody acts on.
| Where you are | Buy this | Not this | What it should teach you |
|---|---|---|---|
| No asset inventory, patching ad hoc | Vulnerability management and an external test | Anything adversarial | What you own and what is exposed |
| Testing happens, no monitoring | Logging and alerting work, then a config review | Covert red team | Whether the events you need are even recorded |
| Alerts exist, nobody owns triage | An owner, then a tabletop exercise | Red team | Who decides, and how fast they can be reached |
| Monitoring runs, coverage unknown | Purple team sessions per technique | Full covert engagement | Which techniques produce no telemetry at all |
| Detection working, response untested | Assumed-breach test with objectives | Perimeter-only testing | How long from first detection to containment |
| Response rehearsed, want the real measure | Covert red team, threat-led scenario | More scanning | Whether the whole chain holds under a quiet attacker |
Does cloud and container maturity change the answer?
It splits it. Readiness is not one number, because most organisations are several years further along on endpoints and email than on their container platform and cloud control plane. You can have credible detection on laptops and none at all inside a Kubernetes cluster that runs your revenue-generating services.
The specific gaps are consistent. Audit logging on the cluster is off, sampled, or shipped nowhere queryable. There is no runtime sensor on nodes, so process execution inside containers is invisible. Nobody alerts on a pod created with a privileged security context, a host path mount, or a service account suddenly listing secrets across namespaces. Workload identity is broad because narrowing it was fiddly during the migration and never revisited.
The useful reframing is that readiness is per surface rather than per organisation, so plan a rolling programme instead of seeking a single verdict. Endpoints and identity this year because the telemetry exists, the cluster next year once audit logs are shipped and a node sensor is running, the build system after that. Each cycle then tests one area properly, rather than producing one report that finds the least instrumented corner and stops there.
The practical consequence is that scope should follow capability, not the other way round. If your cluster has no telemetry, a red team objective inside it teaches you one thing you could have learned from a configuration review. Fix the telemetry, then make the cluster the objective, because that is where an attacker will go and where the interesting detections have to be written.
What if leadership wants a red team anyway?
Reframe rather than refuse, because the underlying request is usually reasonable. Leadership wants to know whether the security spend works, and there are honest ways to answer that which do not need six weeks of covert operations. Say which one you are buying and why.
The three substitutes, in ascending cost: a tabletop exercise where the scenario is read out and decisions are recorded, which finds the authority and communication gaps that dominate real incidents; a purple team programme where techniques are executed openly with the defenders watching their own tooling, which produces detections rather than findings; and an announced assumed-breach test, where a foothold is granted and the team knows testing is happening in the window but not what or when.
Whichever substitute you choose, agree what would make the answer change. A tabletop that produces three named actions and a date is an exercise; one that produces a feeling of alignment is a meeting. Write the actions down at the end of the session while everyone is still present, because the reason these things fail to compound is almost never the exercise itself.
The announced assumed-breach option is the one to argue for when a full red team is premature. It keeps the technical depth, removes the weeks spent on initial access, and does not require an organisation that can keep a secret. Reserve the covert version for the year after, when the question is genuinely about response and not about whether response exists.
Common questions
- What do you need in place before a red team engagement?
- Four things: someone whose job includes reviewing security alerts, retained and queryable logs covering identity, endpoints and your cloud control plane, a written incident process naming who can authorise containment out of hours, and patching current enough that the exercise is not decided by a six-month-old vulnerability. Without logs and a watcher, there is nothing to compare the red team timeline against.
- Is a red team worth it for a small company?
- It can be, and size is the wrong variable. What matters is whether someone monitors alerts and whether logs are retained. A company of fifty with an outsourced monitoring contract and ninety days of retention will learn something. A company of five thousand with unread alert mailboxes will only learn what it already knew, at red team prices.
- How can we test our detection capability cheaply?
- Run one documented, benign attacker technique and record three timestamps: when telemetry appeared, when a human looked at it, and when anyone contacted you. Repeat inside your container platform by exec-ing into a pod, listing secrets with its service account and calling the cloud metadata endpoint. The gap between the two environments is usually large and tells you where to spend next.
- Should we red team during a cloud migration?
- No. Testing an estate that is being rebuilt produces findings about a configuration that will not exist by the time anyone acts on them. Use the migration window for design review of identity, workload permissions and audit logging, which is where the red team would have found its path anyway, and schedule the exercise once the target state is carrying real traffic.
- What is the alternative to a red team if we are not ready?
- In ascending cost: a tabletop exercise, which exposes decision and communication gaps; purple team sessions, where techniques are executed openly and detections are written and retested; and an announced assumed-breach test, where a foothold is granted and the team knows a test is happening but not what or when. The last keeps the technical depth and removes the need to run a covert operation.
