An assumed breach test deliberately skips the initial intrusion phase. We start from an agreed foothold, such as a standard user account or a workstation, and test which privileges can be gained and which systems and critical assets can be reached from it. We also assess how much of that activity your defensive controls and your team pick up, where this is part of the test objective.
The test starts from the assumption that a compromise has already happened, and we define that compromise in advance. Rather than spending testing time on getting in from outside first, we are given an agreed starting point and concentrate on what can happen next. That lets us run a focused test of identity security, privilege boundaries, segmentation, the internal attack surface and how well your defences detect specific actions.
An assumed breach test is not a real incident, and it does not try to predict every action an attacker could take. It is a controlled scenario with defined objectives and boundaries, and it shows which attack paths can be followed from that starting point during the test.
We test whether the initial identity or device can be used to gain wider privileges, access other systems or exploit trust relationships between accounts, services and infrastructure components. The aim is to identify specific paths that increase the impact of the initial compromise.
Before the test, we work with you to define which assets matter in the scenario, such as privileged identities, administration systems, sensitive data or critical business services. We test whether they can be reached from the starting point, and through which attack chain, without going beyond the agreed boundaries.
Where detection and response are part of the test objective, we document the actions that should generate telemetry or alerts and, after the scenario, compare them with what your defenders saw. That lets us find gaps in logging, detection logic, triage and escalation. We assess these results against objectives agreed in advance, rather than assuming that any unnoticed command automatically means your defences have failed.
It is the right test when the most important question is about post-compromise risk, that is, what an attacker can do once they already have initial access, and where your defences stop them. It is not necessarily the next step after a pen test, and it is not a full red team operation. A pen test, an assumed breach test and a wider attack simulation answer different questions, so we choose the method to suit the security objective.
We define the starting point, the test objectives and the critical assets, the systems in and out of scope, the permitted methods, data handling, testing windows, points of contact, the escalation route and the stop conditions. Active testing starts only once the necessary authorisation is in place.
We document the validated paths from initial access to the privileges gained and the objectives reached. For each significant step we keep the technical evidence your team needs to see which controls in the chain have to change.
We summarise which privileges could be gained and which assets could be reached, and what that would mean in your environment. If the test also covers your defenders, we compare the timeline of our actions with your logs, your alerts and your team's response, to pinpoint weaknesses in visibility and detection.
We prioritise the changes that break the most significant attack chains. They may concern identity and privilege management, segmentation, configuration, credential protection, logging, detection or other controls evidenced in the scenario.
Find out how far an attacker would get
Tell us which post-compromise risk you want to test and what your environment looks like. We will reply within one working day and pin down the starting point, the objectives and the information we need to scope the test.
Assumed breach testing is active testing in an internal environment, so we cannot promise that it carries no operational risk at all. We reduce that risk through the rules of engagement. We restrict actions that could affect availability or data, agree sensitive targets in advance, and make sure there is a point of contact and a stop procedure in case something unexpected happens.
We also control how far we take the proof. If we can adequately prove, without copying sensitive data or taking destructive action, that a target can be reached, we go no deeper at that point. The aim is to get enough evidence to support a decision, at a proportionate level of risk.