Building an in-house purple team: a 90-day playbook

Every board that has been through an incident asks the same question in the quarter after: “should we build this in-house?” The answer is almost always yes, and almost never done well. The failure mode isn’t lack of intent — it’s that the program is treated like a hire (“get us a red teamer”) instead of an operating capability.

This is the 90-day playbook we hand training clients — the in-house red team programme is essentially this playbook, delivered on their own infrastructure. It’s opinionated. It’s compressed. And it works.

Prerequisites: what you need before day 1

• Executive sponsorship. Not just approval — an explicit understanding that the purple team will find things that make people look bad, and that finding them is the point. Without air cover, the first uncomfortable finding kills the program.
• A defined blue team. SOC, incident response, detection engineering. Someone who cares whether alerts fire. If there’s no blue team, you’re building a red team, not a purple team.
• A safe target. A production-like environment where the team can act with realism without breaking billing systems. Some orgs stand up a shadow environment; others carve out a controlled slice of prod.
• A charter. One page. Scope, rules of engagement, escalation paths, out-of-scope systems, disclosure norms. Signed by security leadership.

If any of these are missing, spend two weeks fixing them before day 1. Skipping this is the most common way the program fails.

Weeks 1–2 — Foundations

Hire pattern: One senior operator plus one detection engineer minimum. Two operators plus one detection engineer if budget allows. Do not build “the purple team” as a group of red teamers — the detection engineer is half the point.

Tools:

• Endpoint EDR / XDR (whatever the org already has)
• Log pipeline: SIEM, syslog aggregator, or cloud-native (Sentinel, Chronicle, Splunk)
• Attack simulation platform — Atomic Red Team, Caldera, or a commercial equivalent
• One C2 framework the team is comfortable with (Sliver, Havoc, or Cobalt Strike if licensed)
• MITRE ATT&CK Navigator with a live coverage matrix

Deliverable at end of week 2:

• Written charter, distributed
• ATT&CK Navigator showing 0% coverage as the starting baseline
• One documented scenario (see week 3)

Weeks 3–4 — The first scenario

Pick one MITRE ATT&CK technique. Not five. Not “we’ll cover a tactic.” One technique. Preferably one you have reason to believe is exploitable in your environment based on public breach data for your sector.

Suggested first: T1078.004 — Valid Accounts (Cloud). Every org runs cloud. Almost every org has service accounts with over-broad permissions. It’s a technique with high real-world exploitation.

The scenario:

1. Operator plans the test. Which specific procedure will they use? Which log source should catch it? What’s the expected alert?
2. Blue team reviews the plan. Detection engineer says whether they think it will fire, and if not, what would need to change.
3. Test runs live. Operator executes, both sides watch the SIEM in real time.
4. Post-mortem within 24 hours. What fired? What didn’t? What was the response time? What tuning is required?

The output is not a red team finding. It’s a coverage matrix entry. That’s the shift from red to purple.

Month 2 — Cadence

By the start of month 2 the team runs weekly scenarios. Each scenario:

• One technique or one small chain (2–3 techniques)
• Planned Monday, executed Wednesday, retrospective Friday
• Documented in a shared tracker: what was tested, what fired, what changed, what regressed

By the end of month 2, the ATT&CK Navigator should show ~15% coverage — 15–20 techniques tested, alerts confirmed, and tuning done. Coverage is not “we have a detection for it.” Coverage is “we tested the detection with a live technique and it fired within our SLA.”

Scenario order we recommend:

• Week 5: T1078.004 cloud valid accounts (see above)
• Week 6: T1552.005 cloud IMDS access
• Week 7: T1055.012 process injection (test EDR baseline)
• Week 8: T1218.011 regsvr32-based execution (LOLBAS)
• Week 9: T1550.002 Pass-the-Hash — a Windows-lateral classic that most SIEMs still miss

Each of these has been used in real incidents against orgs your size in the last 24 months. If your defenders can’t catch them, that’s the priority.

Month 3 — Chain scenarios and metrics

The move in month 3 is from atomic techniques to chains. A chain scenario walks 4–6 techniques end-to-end, mirroring an actual breach path. This tests not just individual detections but the response: did the alert fire, did the analyst investigate, did the escalation happen, did containment work?

Example chain (public breach template): initial access via phishing (T1566.001) → credential access via LSASS dump (T1003.001) → lateral movement via SMB (T1021.002) → persistence via scheduled task (T1053.005) → collection from file shares (T1039) → exfiltration via HTTPS (T1041).

Run this chain against your production-like environment. Time from initial access to detection is the number you’re now optimising. If it’s over 4 hours in a modern SOC, you have a design problem, not a detection tuning problem.

Metrics to publish (weekly to the CISO, monthly to the board):

• ATT&CK Navigator coverage percentage (with the “tested” bar clearly distinct from the “we have a detection theoretically” bar)
• Median time from technique execution to alert fired
• Median time from alert to analyst acknowledgement
• Detection regressions (things that were passing and now aren’t)
• Coverage gaps by tactic (which tactics have under 10% coverage — those are the next quarter’s targets)

Common failure modes

Ten years of watching organisations attempt this, the recurring failures:

1. Hiring one red teamer, no detection engineer. They produce findings. Nothing gets fixed. Program dies in 8 months.
2. No charter. Legal or a business unit blocks a scenario mid-execution. Team burns political capital.
3. Testing in production without safety rails. Something breaks. Program gets shut down for a quarter.
4. Metrics without a baseline. No before/after story. Program can’t defend its budget at renewal.
5. Chasing novelty instead of coverage. Fun techniques get tested; boring high-impact ones don’t. Coverage matrix has holes shaped like your actual risk.
6. No cross-team calendar. Red does a thing, blue’s not watching, no learning happens. Purple only works if both sides are present.

When to bring in external red teams

Internal purple teams are for continuous coverage. External red teams are for:

• Adversarial validation — did the internal purple team miss a class of technique because they don’t know it exists?
• Regulatory and audit needs — external assessment for MAS TRM, DESC, SOC 2, PCI, etc.
• New technology sprints — you just deployed an LLM assistant. Your internal team is 6 months from being able to test it seriously.
• Fresh eyes on the coverage matrix — every internal team develops blind spots. Every 6 months, an external run catches them.

The two capabilities are complementary, not competitive. Any internal purple team that hasn’t been externally validated in the last 12 months is at risk of measuring its own homework.

The 90-day exit criteria

At the end of the third month, you should be able to say:

• The team runs a scenario per week without external help.
• ATT&CK Navigator shows ≥ 20% coverage tested (a realistic number — 100% is not a real target).
• Detection SLAs are measured and reported.
• The next quarter has a written plan for coverage expansion.
• Two chained scenarios have been run end-to-end and post-mortem’d.
• The blue team has said “we’d have missed that” at least twice — with a documented fix.

If you can say all six, the program is real. If you can’t say any of them, it’s still theatre.

Where an external partner accelerates this

The 90-day playbook can be run internally. Most organisations that try to run it internally without help take 6–9 months to reach the same point, because they burn time on tool selection, scenario design, and figuring out what “good” looks like.

Our in-house red team training is this playbook, delivered on your infrastructure, by operators who’ve run this program at other orgs. We stand up the capability with your team, run the first month of scenarios alongside them, then hand over the operating rhythm. By month 3, they’re running solo.

Whether you build it with us or without, build it. Point-in-time testing does not scale to the rate at which your environment changes. The purple team is the only pattern we’ve seen that does.