Practitioner Guide
Most assumed breach exercises fail before they start — because the scope was wrong. Here's how to set one up so it actually answers the question you're asking.
An assumed breach exercise starts from a position of internal access — a workstation, a user account, or a foothold on an endpoint — and asks: what can an adversary do from here, and would we detect them doing it?
The name comes from the assumption that perimeter defenses have already failed. Not hypothetically. Practically. The exercise is built on the premise that someone is already inside, and the question is what happens next.
This is a different question than "can an attacker get in?" That's what a penetration test answers. An assumed breach exercise answers "once they're in, what can they reach, and do we know they're there?"
These are equally important questions. They require different setups.
The Hard Part
Three decisions dominate the scoping conversation. Getting any one of them wrong produces an exercise that doesn't answer your actual question.
The most common mistake is giving the red team too little access and calling it assumed breach. Starting with a domain user account on a managed workstation with EDR is appropriate for testing lateral movement and privilege escalation. Starting with a local admin account on an unmanaged laptop is closer to a full red team with a head start.
The starting position should reflect the most realistic compromise scenario for your organization. If your threat model is a phishing-susceptible employee, start with a standard user account on a managed endpoint. If your concern is a malicious insider or a compromised contractor, adjust accordingly. Be explicit about what compromise scenario the starting position is meant to simulate.
What is the attacker trying to reach? "Everything" is not an objective. Neither is "crown jewels" unless you have defined what those are and why they matter to an adversary.
Good objectives are specific and business-relevant: reach the customer database, access the CFO's email, achieve code execution on the OT network, access the M&A deal room in SharePoint. These objectives mirror what a real adversary would target, and they give the exercise a clear success condition that your detection team can evaluate against.
Defining the objective also forces a useful internal conversation about what actually matters. That conversation has value independent of the engagement itself.
This is the most politically loaded scoping decision. Running an assumed breach exercise without telling the SOC (a "blind" exercise) tests detection capability under realistic conditions — analysts respond to alerts they don't know are synthetic. Running it with the SOC informed (a "purple team" mode) enables real-time feedback and faster iteration on detection content.
Neither is wrong. They answer different questions. Blind exercises measure current detection performance. Purple team exercises build detection capability. The mistake is running a blind exercise when what you actually needed was detection engineering — and ending up with a report full of findings and no roadmap for what to do about them.
The rules of engagement document is where engagements go wrong at 2am when an analyst actually detects something and doesn't know whether it's authorized. It needs to answer two questions without ambiguity: who can authorize the exercise to stop, and how does the red team confirm their activities are permitted?
The ROE document is not a legal formality. It is an operational document. It should be readable under pressure, at night, by someone who just escalated an incident.
Deliverables
A good assumed breach exercise produces three things. Most engagements from less experienced operators produce only one.
The report should read like a story — here is what we did, in sequence, what we found at each step, and why it mattered. A list of CVEs and CVSS scores is a penetration test report. An assumed breach report should explain how the pieces connected.
Every technique used should be evaluated against your EDR, SIEM, and network detection tooling — not against theoretical detection capability. "NTLM relay is detectable" is not useful. "NTLM relay is not detected by your current Splunk detection content, and here is a detection rule" is useful.
Ordered by what an adversary would actually exploit first, not by CVSS score. The finding that enabled lateral movement from a standard user to a domain admin in 30 minutes is more important than the medium-severity misconfiguration that required a rarely-exploited condition to trigger.
If your organization does not have a SOC, active detection content in a SIEM, and an EDR deployed across managed endpoints — assumed breach will not tell you anything you couldn't learn from a vulnerability assessment. There needs to be something to test.
If you have never done a penetration test and you're trying to understand your basic vulnerability posture, start there. Assumed breach is a test of your response capability, not your patching hygiene. Both matter. They're different questions.
If your primary driver is compliance — a checkbox for SOC 2 or PCI — a penetration test will satisfy the requirement at lower cost. Assumed breach is the right engagement when you genuinely want to know what an adversary would do, not when you need a signature on a form.
Read more about how we structure adversary simulation engagements →Next Step
The scoping conversation is where we figure this out together. Tell us what you're trying to learn, what your environment looks like, and what's happened recently that made you want to do this — and we'll tell you what the right engagement is and whether we're the right fit.
Tell Us About Your Situation →