Assumed breach testing skips the question of whether an attacker can get in — because eventually, one will — and answers the question that actually determines the size of your incident: what can they do once they're inside? The testers start with a foothold you deliberately provide, such as a standard user account or a workstation, and work outward from there.
It's one of the highest-value engagement types we run, because it tests the controls that separate a contained phishing incident from a company-wide breach.
What Assumed Breach Testing Is
In an assumed breach engagement, you grant the testers a realistic starting position up front instead of making them earn it. Common starting points:
- A standard corporate laptop and a low-privilege domain account, simulating a phished employee
- VPN or SSO credentials, simulating a credential-stuffing or infostealer victim
- A low-privilege cloud role or CI token, simulating a leaked key
- A compromised workstation image, simulating successful malware delivery
From that foothold, the testers behave like a post-compromise attacker: escalate privileges, move laterally, access sensitive data, and head for whatever objectives you've agreed — the finance share, the production database, domain or cloud admin, the crown jewels.
The premise isn't pessimism; it's arithmetic. Initial access is the cheapest part of any real attack. Phishing, infostealer logs, password reuse and third-party compromise mean the perimeter will fail occasionally no matter how good your controls are. Assumed breach measures what that failure costs you.
Why 'What Happens After a Phish' Is the Question That Matters
Most organisations spend heavily on stopping the first click and comparatively little on what the click leads to. But the difference between a bad day and a disclosure event is almost never the phish itself — it's everything after:
- Could the attacker escalate from one user's access to many?
- Did lateral movement trigger any alert, or was the environment silent?
- Was sensitive data reachable from a standard workstation?
- How long from foothold to domain admin, or to the production cloud account?
These are empirical questions, and assumed breach testing answers them with evidence rather than architecture diagrams. If the honest answer is 'one phished marketing account leads to the customer database in a day', you want to hear it from us, not from an incident-response retainer.
The same logic applies in cloud environments: a single leaked access key in a well-segmented AWS organisation is an annoyance; in a flat one with over-privileged roles it's a full compromise. Our cloud penetration testing frequently uses an assumed-breach starting position for exactly this reason.
How It Differs From External Penetration Testing
External network penetration testing answers a different question: what can an attacker reach and exploit from the internet with no access at all? It exercises your perimeter — exposed services, VPNs, mail, forgotten hosts.
The two differ in almost every dimension:
- Starting point: external starts from zero; assumed breach starts from a granted foothold.
- Question answered: 'can they get in?' versus 'what happens when they do?'
- Controls exercised: perimeter hardening and exposure management, versus internal segmentation, privilege management, detection and response.
- Time economics: external tests can burn most of their budget on initial access; assumed breach spends the entire budget on the post-compromise phase, which is where the expensive findings live.
They're complementary, not competing. A mature programme runs both, because a hard perimeter around a soft interior — still the most common architecture we see — passes an external test and fails catastrophically in a real incident.
Assumed breach also differs from a full red team, which typically includes gaining initial access covertly (often via social engineering) and testing the blue team's detection end-to-end. We've compared those models in red team vs penetration test. Assumed breach is the pragmatic middle: red-team-style post-exploitation depth at penetration-test cost, without spending budget re-proving that phishing works.
What You Get Out of It
A good assumed breach report gives you:
- The concrete attack paths from foothold to objective, step by step, with evidence
- The specific misconfigurations enabling each hop — excessive privileges, weak segmentation, credential sprawl, legacy protocols
- Which steps generated alerts and which happened in silence, if detection is in scope
- A prioritised fix list where one change often breaks multiple paths
That last point is why these engagements tend to be efficient: attack paths in real environments converge on a handful of chokepoints, and fixing a chokepoint collapses many paths at once.
FAQ
Is assumed breach testing the same as a red team?
No. A red team earns its own access covertly and tests detection and response across the full kill chain, usually over weeks. Assumed breach grants the foothold up front and focuses the entire budget on post-compromise impact.
What access do we actually hand over?
Whatever matches the scenario you care about — typically a standard user account and a build-standard laptop or VM, or a low-privilege cloud role. It's always agreed in scoping, created fresh for the engagement, and removed afterwards.
Does assumed breach replace external testing?
No — it answers a different question. External testing validates your perimeter; assumed breach validates your blast radius. Organisations with any internet-facing footprint generally need both, though not necessarily in the same year.
If you want to know what a single phished account actually costs your organisation, talk to us. We'll scope an assumed breach engagement in a free call and have a fixed quote to you within one business day.
Need cybersecurity expertise?
Drop your email and we'll be in touch within one business day.