Red Team Readiness Assessment

Hiring a red team before your SOC can see them is an expensive way to confirm what you already suspected: there are gaps. Run the operation too early and you get a thick report of attack paths your telemetry never registered, a defence team that feels ambushed rather than trained, and a remediation bill inflated by the fact that you’re now fixing everything at once instead of the few things that mattered. The exercise was supposed to sharpen the SOC. Run prematurely, it just demoralises it.

The Red Team Readiness Assessment is the diagnostic you run before the live-fire exercise. We evaluate people, process, identity controls and detection coverage against one question: can your SOC actually detect and learn from a red team operation? If the answer is no, you get a roadmap to yes — which is far cheaper than discovering the answer halfway through a real engagement.

Which Assessment Do You Need?

Security testing isn’t one product, and buying the wrong one for your maturity level is a common, costly mistake — a Level 2 org that commissions a full red team is paying premium rates to be told things a vulnerability scan would have surfaced for a fraction of the cost. These four get conflated constantly:

Type	Purpose	How It Works	Who It’s For
Vulnerability Assessment	Find known security flaws.	Automated scanning, broad and systematic.	Compliance teams, IT operations.
Penetration Test	Confirm flaws are exploitable.	Manual testing in a defined scope.	Engineering, application security, compliance.
Red Team Readiness	Check if your SOC is ready.	Collaborative review, no actual attacks.	Security leadership, SOC managers.
Red Team Operation	Full simulated adversary attack.	Stealthy, multi-phase, real testing.	Mature SOCs ready for the challenge.

The Four Pillars We Evaluate

A red team engagement that actually teaches you something rests on four foundations. We assess each:

1. Scope & Rules of Engagement Can you cleanly define what’s in bounds and what isn’t? We check for clear, legal testing boundaries — which infrastructure is fair game, which third-party or cloud-hosted systems are off-limits (testing an asset in someone else’s tenancy without their consent is a real legal problem, not a technicality), and what hours or systems are too fragile to touch.

2. Asset & Identity Inventory A red team’s whole edge is exploiting what you don’t know you own. We review visibility into Tier 0 assets, service accounts, forgotten AD domains, and cloud identity sprawl across AWS and GCP. The uncomfortable pattern: the organisations most confident in their inventory are frequently the ones with the largest blind spots, because confidence is what stopped them looking.

3. Telemetry & Visibility If an attacker uses a legitimate signed Windows binary to live off the land, does anything fire? We check endpoint logging — Sysmon, PowerShell script-block and transcription, Event ID 4688 with command-line capture — and EDR coverage on the servers that matter. Coverage on paper isn’t coverage; a policy that says logging is enabled and a log that actually arrives in the SIEM are different claims, and only the second one helps you.

4. Incident Response Maturity When an alert fires, is there a process, or a scramble? We review escalation, triage and who owns legal and communications — because a simulated intrusion that trips a real, uncoordinated crisis response tells you your IR maturity as loudly as any technical finding.

How We Validate—Safely

You don’t need to be exploited to find out whether you’d detect exploitation. We use a purple-team approach — controlled, non-destructive, mapped to MITRE ATT&CK — which is lower-risk precisely because nothing actually breaks. The trade-off, stated honestly: this tells you whether the conditions for detection exist, not whether your team performs under the adrenaline of a live intrusion. That second question is what the real red team, once you’re ready, is for.

• Endpoint Logging Check — We confirm the critical logging is on (Event ID 4688 with command-line auditing, Sysmon) so lateral movement would be visible — without running the movement.

• Identity Analysis — Instead of executing Kerberoasting, we inspect Active Directory for the weak service-account passwords and over-long ticket lifetimes that make it possible. Same finding, none of the risk of cracking a live credential.

• Tabletop Attack Chains — We walk the SOC through a scenario — phishing lands, attacker runs PowerShell — and watch them investigate it in their real SIEM dashboards. This is where “we have Sysmon” meets “can the analyst actually find the process tree”, and the two often diverge.

• Phishing & Email Review — We assess the gateway controls (DMARC, SPF, DKIM) and past awareness metrics without running a live credential-harvesting campaign, which spends employee trust you may want intact for the real exercise later.

What You Get

Not a CVE list — a strategic blueprint for becoming ready.

• Readiness Scorecard — Where you stand across people, process and technology, scored so progress is measurable rather than felt.

• Detection Coverage Heat Map — A MITRE ATT&CK map of your blind spots. Read it with the standard caveat in mind: a technique shown as “covered” usually means a rule exists for it, not that anyone tested whether the rule fires. A green 70% heat map often means someone counted rules, and the honest version of this deliverable distinguishes “we have a detection” from “we proved it works”.

• Tabletop Scenario Library — Real attack scenarios the team can rehearse year-round, so readiness is maintained between assessments rather than decaying quietly after one.

• Executive Brief — Plain-language risk and the budget needed to close the biggest gaps first, written so leadership can prioritise instead of being handed a wall of technical findings.

Where Do You Stand? The Maturity Model

We place you on a five-level scale. The point isn’t the number — it’s the honest answer to whether a red team is worth your money yet:

Level	Status	What This Looks Like	Red Team Ready?
1	Ad-Hoc	No consistent logging; no dedicated security staff.	❌ No
2	Developing	Some EDR running; no central SIEM; IR is reactive.	❌ No
3	Defined	Central SIEM exists; basic alerts tuned; IR playbooks written.	⚠️ Maybe (purple team only)
4	Managed	Active threat hunting; behavioral alerts; full SOC in place.	✅ Yes
5	Optimized	Automated response; continuous red team exercises; metrics tracking.	✅ Absolutely

The 60-Day Roadmap (If You’re Not Ready Yet)

Score below Level 4 and this is the path up. The order is deliberate — telemetry before identity before process before rehearsal — because each stage is what makes the next one meaningful.

Days 1–15: Logging & Telemetry Standardise logging across critical infrastructure, enable PowerShell script-block logging, tune EDR. The one thing to verify rather than assume: that the alerts actually arrive in the SIEM. A logging policy enabled locally that never reaches the console is the most common silent gap, and it looks identical to working until the day you need it.

Days 16–30: Identity & Access Close the AD weak spots, rotate stale service-account passwords, enforce MFA on external gateways, and map who holds Tier 0 access and why. Expect the “and why” to have no good answer for several accounts — finding those is the point.

Days 31–45: Incident Response Write the IR playbook you’ll actually use, name who escalates to whom, and document the legal and comms procedures before an incident forces you to invent them live.

Days 46–60: Purple Team Exercise Run a guided tabletop against specific ATT&CK techniques and confirm the new logging catches them in practice, not just in policy. This is the proof step that turns “we have coverage” into “we watched it fire”.

Clear this and you’re ready — and the red team you then commission spends its budget teaching your SOC rather than just cataloguing what you already knew was missing.