Australian organisations have spent a decade hardening the perimeter: next-generation firewalls, multi-factor authentication, secure email gateways and endpoint protection on every device. Yet breaches keep happening. In 2026 the attackers are faster and better resourced, using AI-assisted phishing, ransomware-as-a-service kits and stolen identities that walk straight through the front door. When the perimeter is no longer a reliable wall, the honest question is not "can they get in" but "how quickly will we know, and what will we do about it". That is exactly what assumed breach testing answers.
Assumed breach testing, sometimes written as "assume breach", starts from the premise that an attacker already has a foothold inside your environment. Rather than spending days trying to break through the perimeter, the exercise begins with a controlled internal presence and measures how your people, processes and technology detect, respond to and contain a live intruder. It is one of the most practical ways to see your real security posture, not the posture you assume you have.
What Assumed Breach Testing Actually Is
Assumed breach testing simulates the post-compromise stages of a real attack. Testers are granted a starting position that mirrors a plausible initial access event, then behave like a genuine adversary working towards defined objectives such as reaching sensitive data, escalating to domain admin, or accessing a crown-jewel application.
The starting foothold might represent:
- A phished employee whose workstation is now under attacker control
- A set of valid credentials bought from an initial access broker
- A compromised third party or supplier with legitimate network access
- An insider, whether malicious or negligent, with normal user privileges
From there, the test focuses on the behaviours that decide whether an incident becomes a headline: lateral movement, privilege escalation, credential theft, persistence and data exfiltration. The point is not to prove a breach is possible. The point is to observe what your detection and response capability does while it happens.
Why Prevention-Only Security Fails
Prevention is necessary, but it is not sufficient. Betting everything on stopping the initial intrusion assumes your controls are perfect and your attackers are ordinary. Neither holds true in 2026.
- Identity is the new perimeter. Credential theft, session hijacking and MFA fatigue attacks let adversaries authenticate as real users, so preventive controls see legitimate logins rather than an intrusion.
- Supply-chain and third-party access mean a breach elsewhere can become access to you, with no perimeter to breach at all.
- AI-enabled attackers craft convincing lures and adapt quickly, raising the odds that someone eventually clicks.
- Ransomware-as-a-service has industrialised intrusion, so the volume and speed of attacks keep climbing.
The uncomfortable reality is that a determined adversary will eventually get in. Organisations that survive are the ones that detect the activity early and respond decisively. Assumed breach testing measures that capability directly, which prevention-focused testing simply cannot do.
How It Differs From a Standard Penetration Test
A traditional penetration test and an assumed breach test are complementary, not interchangeable. Understanding the difference helps you commission the right work.
- Starting point: A pen test typically works from the outside in, hunting for exploitable weaknesses in the perimeter, applications or external services. An assumed breach test starts from an internal foothold and works towards objectives.
- Primary question: A pen test asks "what vulnerabilities exist and can they be exploited". An assumed breach test asks "if an attacker is already inside, will we see them and can we stop them".
- Measure of success: A pen test is measured by the coverage and severity of findings. An assumed breach test is measured by detection rates, response times and how far an intruder can progress before being contained.
- Audience: Pen test output guides patching and configuration teams. Assumed breach output guides your security operations, incident response and executive risk owners.
If you are new to structured testing, our penetration testing services are the natural starting point, while assumed breach and red teaming build on that foundation to stress-test detection and response.
What an Assumed Breach Test Reveals About Detection and Response
This is where the value sits. Detection and response testing surfaces the gaps that only appear once an attacker is moving inside your network, the gaps that decide whether a minor incident becomes a company-wide crisis.
A well-run exercise typically exposes:
- Blind spots in logging and monitoring, where activity generates no alert at all
- Endpoint detection and response tooling that is deployed but poorly tuned, so genuine malicious behaviour is missed or buried in noise
- Weak network segmentation that lets an attacker move freely from a single foothold to critical systems
- Escalation paths through misconfigured Active Directory, over-privileged accounts and cached credentials
- Incident response playbooks that look complete on paper but stall under real pressure
These are the same pathways a ransomware crew would exploit, which is why assumed breach findings translate directly into ransomware resilience. For Australian organisations, the results also map cleanly onto the ASD Essential Eight, particularly the maturity of application control, privileged access management and monitoring. For entities covered by the SOCI Act or regulated under APRA CPS 234, demonstrating that detection and response has been independently tested is fast becoming an expectation, not a nice-to-have. And because the Notifiable Data Breaches scheme turns undetected exfiltration into a reporting obligation, knowing your true detection capability has real legal and financial weight.
How to Run an Assumed Breach Test
A successful exercise is deliberate and objective-led. The following sequence keeps it useful and safe.
- Define objectives. Agree what "compromise" would mean for your business, such as reaching a specific dataset, application or level of privilege. Realistic goals produce realistic findings.
- Choose a scenario and starting position. Select the initial access event that best reflects your threat profile, for example a phished finance user or compromised supplier credentials.
- Set rules of engagement. Confirm scope, timing, out-of-bounds systems, data handling and clear points of contact so the exercise is controlled and defensible.
- Decide who knows. Keeping the security operations team in the dark tests genuine detection. A collaborative, transparent run tends towards a purple team approach where attack and defence share findings in real time.
- Execute against objectives. Testers work through lateral movement, escalation and persistence while every action is logged for later comparison against what your tools detected.
- Debrief and remediate. Compare the attacker timeline with your detection timeline, quantify response times, and turn each gap into a prioritised action with an owner and a date.
Run this on a regular cadence, not once. Environments change, staff turn over and adversary techniques evolve, so detection and response capability needs continual validation.
Assumed breach testing is the natural evolution of offensive security because it measures what actually protects your organisation once prevention fails: the speed and quality of your response. If you want to know how your team would truly perform against a live intruder, StrikeCyber runs threat-led assumed breach and adversary simulation engagements for organisations across Australia from our Brisbane base. Call us on 1300 654 898 or get in touch to scope an exercise that reflects the way your business is genuinely attacked.