Traditional penetration testing starts at the perimeter and asks whether an attacker can get in. That was the right question when the perimeter was the primary control and most organizations had not thought hard about it.
It is a less useful question now, because most security teams have already answered it. Given a workforce of any size and an attacker with time, someone will eventually click something, a supplier will be compromised, or an exposed service will be found. The interesting question is what happens next.
Assumed breach testing starts there.
Starting Where the Damage Starts
An assumed breach engagement begins from a position of compromise: a standard user account, or a foothold on an ordinary corporate endpoint. Nothing is spent on getting in, because getting in is stipulated.
The value of that reallocation is considerable. An engagement that spends two weeks on initial access and one week on what follows has spent most of its budget confirming something the client suspected. Reversing that ratio produces findings about lateral movement, privilege escalation, data reachability and detection, which is the material that determines whether an incident is an inconvenience or a catastrophe.
It also reflects how intrusions actually work. Initial access is a commodity. There are people whose entire business is obtaining footholds and selling them to whoever wants them, which means the attacker who ends up in your environment may have had nothing to do with getting there.
What It Measures
Blast radius. From one ordinary account, what is reachable? This is usually the finding that changes behavior, because the answer is routinely much larger than expected. Ordinary users can frequently enumerate the entire directory, read file shares holding operational documentation and credentials, and reach internal applications unrelated to their role.
Escalation paths. How does an attacker get from that starting position to privilege? In most environments the answer is a chain of four or five ordinary misconfigurations, none individually alarming. We have documented a representative example in domain admin in a day.
Segmentation, in practice rather than in diagram. Network segmentation is one of the most commonly claimed and least commonly verified controls. Assumed breach tests it directly by attempting to cross it.
Detection where it matters. Perimeter detection is generally the best-developed part of a monitoring program. Detection of lateral movement, credential access and privilege escalation is consistently weaker, and those are precisely the stages an assumed breach exercises.
Data reachability. Not where the data is documented to be, but what is actually retrievable from the starting position. These frequently differ.
Covert or Announced
Both variants are useful and they answer different questions, so the choice should be deliberate.
Covert means the security team is not told. This measures detection honestly, including the parts of it that depend on someone noticing at three in the morning. It is the right choice when you want to know whether your monitoring works.
Announced, run within a known window, lets the response process itself be evaluated. Who escalates, how quickly, with what authority, and can they contain a system without breaking operations? Response process failures are extremely common and largely invisible in a covert exercise, where you only see whether an alert fired.
Organizations with a mature detection capability tend to run covert. Organizations that already know detection is weak get more value from announced, because measuring a process they can improve beats confirming a gap they have already identified.
Where It Fits
Assumed breach sits between penetration testing and red teaming and borrows from both.
It is broader than a red team, which pursues one objective by one route and deliberately leaves most of the environment untested. It is more focused than a general internal penetration test, because it pursues objectives from a defined position rather than enumerating everything.
For many organizations it is also the better first serious exercise. A red team requires detection maturity to be worth its cost, since without it the exercise simply confirms nobody was watching. Assumed breach produces actionable findings regardless of maturity, which makes it a more reliable investment for a team still building.
What Changes Afterward
The remediation that follows an assumed breach engagement tends to be structural rather than a list of patches, which is a good sign about the exercise.
Common outcomes are reducing what a standard account can enumerate and reach, removing credentials from shares and scripts, implementing tiered administration so privileged credentials are not cached on ordinary systems, introducing meaningful segmentation around the systems that matter, and redirecting detection engineering toward internal movement rather than the perimeter.
None of those are quick. All of them reduce blast radius permanently, which is the durable form of security improvement.
The Premise Worth Accepting
Assume the phishing email works, because eventually one does. What determines the outcome is not whether you were breached but how far the breach reached and how quickly you contained it.
Rehearsing that under controlled conditions, with operators who will tell you exactly what they reached and how, is considerably cheaper than discovering it during an actual incident.
To discuss an assumed breach engagement, get in touch.
Frequently asked questions
What is assumed breach testing?
An engagement that begins from a position of existing compromise, typically a standard user account or a foothold on a corporate endpoint, rather than attempting to break in from outside. It skips initial access deliberately and concentrates the entire budget on the question of what an attacker achieves once inside, which is where the damage actually occurs.
Why skip initial access?
Because for most organizations it is not genuinely in doubt. Given a workforce of any size, a determined attacker will eventually succeed through phishing, a supplier, or an exposed service. Spending half an engagement proving that leaves less to spend on the part you do not know, which is how far they get afterward.
How is this different from an internal penetration test?
They overlap substantially and the terms are used loosely. The useful distinction is framing: an internal penetration test typically enumerates weaknesses across the internal environment, while an assumed breach engagement pursues an objective from a defined starting position and measures blast radius. In practice, many engagements sensibly combine both.
Does the security team know it is happening?
It depends on what you want to measure. Covert assumed breach measures whether detection notices unannounced activity. Announced assumed breach, run within a known window, lets you evaluate the response process itself: escalation, decision-making and containment. Both are valuable and they answer different questions, so decide which one you need before scoping.
What starting position should we use?
The most realistic one, which is usually a standard user account with no special privilege, on a managed endpoint, with typical group memberships. Starting with elevated access tests something less useful. If a specific scenario concerns you, such as a compromised contractor or a compromised developer, use that instead, since blast radius differs considerably by starting point.