The Penetration Test That Starts With You Already Inside
The typical penetration test follows a familiar arc. External reconnaissance, enumeration of exposed services, exploitation of something left open, a foothold somewhere inside, and then the lateral movement chain that ends at domain admin or a database of customer records. You get a report. You remediate the findings. You schedule next year's test.
What this arc assumes is that the interesting question is whether an attacker can get in. For organizations that have spent real money on perimeter security - firewalls, web application firewalls, email filtering, endpoint protection, MFA on external access - this is not actually the most interesting question. The interesting question is what happens when all of that fails, because eventually some of it will.
Assumed breach testing answers the question the standard pentest does not ask.
What Assumed Breach Actually Means
The name is slightly misleading. An assumed breach engagement does not assume that you have already been breached. It assumes that an attacker has already achieved initial access and asks what they can do from there.
In practice, this means the tester starts the engagement with an initial foothold that is agreed upon with the client. That foothold might be a standard user account on a domain-joined workstation, representing the scenario where a phishing email resulted in credential theft. It might be a shell on a server in the DMZ, representing a compromised internet-facing application. It might be a contractor account with legitimate remote access, representing a supply chain compromise or a vendor credential that got leaked.
The scope is defined by the objective, not by the starting point. The question might be: can an attacker with this level of access reach the production database environment? Can they access HR systems? Can they exfiltrate documents from executive file shares? Can they deploy ransomware on more than fifty endpoints before anyone notices?
What You Learn That Standard Tests Do Not Show
The most valuable finding from most assumed breach engagements is not a specific vulnerability. It is the detection gap.
When a tester running a standard external pentest gets inside the network, they are usually already past most of the monitoring. Internal east-west traffic is logged differently than external traffic, if it is logged at all. EDR tools may be deployed inconsistently - the servers in the test environment that nobody updated, the legacy endpoints that cannot run the agent, the workstations in the field offices that are not managed through the standard process.
An assumed breach engagement starts in that environment and tries to move laterally, escalate privileges, and reach sensitive systems. The tester keeps notes on every step. After the engagement, the client can correlate the tester's timeline against their security tooling to answer a specific question: did any of this generate an alert?
The answer, in most organizations that have not specifically tuned their detection for internal movement, is mostly no.
This finding changes the conversation. Instead of remediating individual vulnerabilities in firewall rules or web application logic, the organization now has evidence that their detection capability has a large blind spot for post-compromise activity. That is a different remediation strategy, involving SIEM tuning, behavioral analytics, decoy credentials and honeypots, and investment in detection engineering rather than perimeter hardening.
When to Use This Instead of a Standard Pentest
Assumed breach testing is not a replacement for perimeter security assessment. If you have not tested your external attack surface recently, that is the right starting point. Perimeter assessment catches the low-hanging fruit that attackers exploit before they do anything sophisticated.
The case for assumed breach testing comes when an organization has reached a level of perimeter maturity where the external test does not produce many findings. At that point, the annual pentest starts to feel like a checkmark exercise: tester comes in, finds a few medium-severity issues, report gets filed, nothing fundamentally changes. The findings stop being surprising.
Assumed breach is also appropriate when the specific threat the organization is most worried about involves initial access through a method that bypasses perimeter controls entirely. Phishing with malware attached bypasses your WAF. A malicious insider does not come through the external attack surface. A supply chain compromise starts with a trusted vendor connection that already has access. If these are the scenarios that keep you up at night, a test that starts from inside gives you more relevant information.
Scoping the Engagement Properly
The scenario definition is where assumed breach engagements either work well or collapse into something less useful than a standard test.
A vague assumed breach engagement - "start as a user on the network, try to get to sensitive data" - produces a report that tells you a sophisticated attacker could move laterally, escalate privileges, and reach sensitive data. You probably already knew that. The specificity of the starting scenario and the objective determines whether the findings are actionable.
Good scoping defines the initial access scenario in enough detail to make the foothold realistic. A standard user on a domain-joined workstation should have the level of access that a real user in that role has, not more. The objective should be a specific system or data type, not "anything sensitive," so that the tester's path is bounded and the findings map to a credible threat model.
The engagement should also include explicit discussion of what happens when the tester is caught. In some assumed breach engagements, the detection and response team does not know a test is happening. The tester is caught, the IR team starts responding, and the table turns into an interesting conversation about how the response was handled. This is more realistic. It is also more organizationally complex to set up.
The Uncomfortable Finding
Most organizations that run their first assumed breach engagement discover that an attacker with a standard user account and a phishing-delivered payload could have moved through their environment for weeks before anyone noticed.
This is not a failure of the security team. It is an accurate picture of what detection tooling looks like before it has been specifically tuned for post-compromise behavior. The finding is valuable precisely because it is uncomfortable.
The standard pentest generates a vulnerability list. Assumed breach generates a detection coverage map. Both are useful, but for mature security programs, the second one is often where the real gaps are hiding.