Assumed breach penetration testing is a security assessment that hands the tester a foothold inside your network before the test even starts. They don’t have to break in first. The tester might get a standard user account, a VPN login, or a laptop image, whatever a realistic attacker could already have. From there, the test asks one question: how much damage could they do, and would anyone notice?
It exists because that is how most real incidents begin. Attackers rarely need a clever zero-day when a phished password or an unpatched laptop gets them just as far. If your business has already had a normal penetration test, this is often the next sensible question to ask.
Table of Contents
How does assumed breach penetration testing work?
Rather than spending the engagement trying to breach the perimeter, the tester starts already past it. You provide the access, matched to a scenario that reflects a real risk to your business. The test then focuses entirely on what happens next.
Typical starting scenarios
- A phished set of Microsoft 365 or single sign-on credentials
- A standard domain user account with no special privileges
- A compromised or stolen company laptop
- A developer account with access to source code repositories
- A device connected directly to an internal network segment
From that starting point, the tester works through the internal network step by step. They hunt for wrong permissions and unpatched systems, then try to escalate access. From there, they move sideways toward whatever data or systems the business has flagged as most sensitive. This mirrors how the National Cyber Security Centre itself describes scenario-driven testing. Its guidance suggests scenarios such as a lost laptop, a rogue device on the network, or a compromised host. Pick whichever fits the incidents most relevant to your own past.
Why choose this over a standard penetration test?
A standard test still matters. It tells you where your perimeter and applications are weak. It remains the right starting point if you have never had an internal or external penetration test. But once the basics are covered, another engagement that just re-confirms the locked front door tells you less. Endpoint detection tools have made brute-force perimeter breaches harder for testers and attackers alike.
Assumed breach penetration testing shifts that budget instead. Rather than paying for time spent failing to get past a firewall, you pay for time spent on lateral movement, escalation and detection. That’s the part of a real attack that usually causes the actual damage. Want the getting-in stage tested too, end to end, without the tester or your team being told in advance? That’s what a red team assessment is built for. The two engagements answer genuinely different questions.
Assumed breach vs red teaming vs a standard pentest
| Test type | Starting point | Main question answered |
|---|---|---|
| Standard penetration test | Outside the perimeter | Where are our vulnerabilities? |
| Assumed breach test | Foothold already granted | What could an attacker reach from here? |
| Red team engagement | Outside, undetected | Could a determined attacker get in and act, end to end, without being noticed? |
Does this help with compliance?
It increasingly does, even where no framework names it outright. SOC 2’s monitoring and incident response rules expect a business to show it can detect and respond to security events. A locked perimeter alone doesn’t satisfy that. A standard pentest report cannot answer “would our monitoring have caught this attacker?” It rarely gets far enough to test that. An assumed breach penetration testing engagement is built to answer exactly that question. The tester is already inside from the first hour.
The same logic sits behind the Bank of England’s CBEST framework for the financial sector. It’s built around intelligence-led testing that mimics how a real attacker would move against a firm’s most important business services. That’s a sharper test than a generic vulnerability sweep.
Choosing a scenario that actually reflects your risk
The value of the test lives or dies on the scenario you pick. A generic “standard user account” scenario is a reasonable default. But naming a scenario built around your actual risk tells you far more. Consider a firm that handles client financial data: it might want to test what a phished finance-team account can reach. Or take a software company, which might care more about what a compromised developer account exposes in its code repositories. Name the scenario before scoping starts, rather than leaving it to the provider to guess. That’s what turns a generic assumed breach penetration testing exercise into one that actually answers your question.
What should you expect from the engagement?
- Scoping – agreeing the scenario, the starting access, and the systems or data considered “the crown jewels” for this test.
- Execution – the tester works from the granted foothold through reconnaissance, escalation and lateral movement.
- Detection check – your security team or managed detection provider is (usually) kept blind, so the test can measure whether the activity gets spotted.
- Reporting – a plain account of how far the tester got, what let them get there, and what would have stopped or slowed them.
What drives the cost of an assumed breach engagement?
Pricing depends on the scenario you choose, how large the internal environment is, and how many scenarios you want covered. A single scenario, such as a phished standard user account, is narrower and cheaper. Testing three separate entry points across a large estate costs more. Ask any provider to build the price from an agreed scope. A flat fee quoted before they understand your environment is a warning sign, not a bargain.
It also helps to be clear about whether you want your security team told in advance. Testing detection blind, where your team doesn’t know, gives a more honest read on response time. It does need a bit more planning up front with the testing provider, though, so alerts don’t cause confusion.
Frequently asked questions
Is assumed breach penetration testing suitable for a smaller business?
Yes, provided you have already covered the basics: patching, a firewall, and at least one earlier penetration test. Size matters less than whether you’re ready to ask what happens after a breach. That’s a different question from whether one can happen at all.
Do we have to give up an active credential?
No. Testers typically use a dedicated test account or device configured to match the scenario. Nothing from a real employee’s access is put at risk.
How is success measured?
Success comes down to how far the tester got, how long it took, and what controls slowed or stopped them. Crucially, it also comes down to whether your detection tools or team noticed. A clean detection record is as valuable a result as finding no way through.
Can this replace our annual penetration test?
It shouldn’t. Treat it as a complement that answers a different question. Most mature security programmes run both over time rather than choosing one permanently.
What size business typically commissions this?
Most commonly, firms that have grown past their first one or two penetration tests, and want a more realistic view of their exposure. There’s no strict size cut-off.
What do we get at the end of the engagement?
A written report, covering the path the tester took from the initial foothold and what let them progress at each stage. It also covers whether and when detection tools or staff picked up the activity, plus ranked recommendations for closing the gaps found. A good provider will also talk you through the findings rather than just emailing a PDF.
Weighing up whether an assumed breach penetration testing engagement or a standard penetration test is the right next step? Aardwolf Security can talk you through the scoping and help pick a scenario that actually reflects your risk. Get in touch and we’ll help you work out what fits.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
