Assumed Breach Testing: What It Is, How It Works & Why SOC 2 Auditors Require It

What Is Assumed Breach Testing?

Assumed breach testing is a type of penetration test that starts from the premise that an attacker has already gained access to your environment. Instead of testing whether someone can break in, it tests what they can do once they're inside — how far they can move laterally, what systems they can reach, what data they can access, and whether your security controls would detect them. It simulates the post-compromise phase of a real attack using a provided internal foothold, such as a low-privilege user account or a position on the internal network.

In 2026, it's the fastest-growing category of offensive security testing because organizations are finally accepting the evidence: perimeter security alone doesn't stop breaches, and most post-incident investigations reveal that attackers were inside for weeks or months before detection.

1. What Assumed Breach Testing Means
2. Why "Assume You're Already Breached" Is the 2026 Operating Model
3. Assumed Breach vs Traditional Pentest
4. When Compliance Frameworks Recommend Assumed Breach Testing
5. What Assumed Breach Testing Covers
6. How SecurityWall Conducts Assumed Breach Engagements
7. What a Complete Assumed Breach Report Looks Like
8. Book an Assumed Breach Assessment

What Assumed Breach Testing Means

In a traditional penetration test, testers start outside your environment and attempt to get in probing firewalls, testing login pages, hunting for exposed services. The question being answered is: can an attacker breach the perimeter?

Assumed breach testing starts one step later. Testers are given an initial foothold a set of low-privilege credentials, a compromised endpoint, or a position on the internal network and the question becomes: given that an attacker is already inside, what can they do?

That initial foothold simulates what happens after any of the following:

• A phishing email successfully harvests credentials
• A contractor's laptop is compromised and connected to the corporate VPN
• An exposed service is exploited and a reverse shell is established
• An insider threat a disgruntled employee or one whose access was never revoked takes action

The goal isn't to test whether the front door locks. It's to test what happens after someone walks through it.

This is sometimes called purple team testing, post-compromise simulation, or internal threat modeling but the core premise is the same: the attacker is in. What can they reach, and who would know?

What Does Assumed Breach Testing Actually Test?

Starting from a low-privilege internal position, testers attempt to:

• Move laterally across the internal network to higher-value systems
• Escalate privileges — from a standard user account to domain administrator
• Steal credentials from memory, credential stores, or poorly secured accounts
• Access sensitive data — customer records, source code, financial data, ePHI
• Simulate exfiltration to map viable data theft paths
• Measure detection — which of these actions your SIEM, EDR, or security team actually catches

That last point is what makes assumed breach testing uniquely valuable: it tells you not just what an attacker could do, but whether you'd know they were doing it.

How Is It Different from a Regular Pentest?

A traditional penetration test starts outside your environment and attempts to get in testing firewalls, login pages, and externally exposed services. The question being answered is: can an attacker breach the perimeter?

Assumed breach testing skips that question entirely. Testers are handed a starting foothold and the question becomes: given access, what's the blast radius?

That foothold typically simulates one of the most common real-world scenarios: a phishing email that harvested credentials, a compromised contractor laptop connected to the VPN, or an insider threat. All of these give an attacker internal access without ever touching the perimeter which is exactly why perimeter-only testing misses them.

Why "Assume You're Already Breached" Is the 2026 Operating Model

The case for assumed breach testing is built on incident data, not theory.

Attacker dwell time remains measured in weeks. The median time between initial compromise and detection has decreased in recent years but not because organizations got better at detecting intrusions. Primarily because ransomware operators moved faster. Advanced persistent threats (APTs) targeting sensitive data still maintain access for 30–90+ days before triggering any alert. That's 30–90 days of lateral movement, data exfiltration, and credential harvesting invisible to perimeter-focused defenses.

Most breaches start with valid credentials. Compromised credentials are the leading initial access vector across all major incident categories. When an attacker logs in with a legitimate username and password, there is no perimeter breach to detect they're an authenticated user. Traditional perimeter testing doesn't model this scenario at all.

Ransomware kill chains are internal problems. Ransomware operators have refined their playbook to exploit exactly what assumed breach testing measures: weak internal segmentation, over-privileged accounts, unmonitored lateral movement paths, and accessible backup systems. Organizations that invest heavily in perimeter security but never test internal defenses are exactly the target profile ransomware groups look for.

Detection and response capabilities are untested. A traditional pentest tells you whether you have vulnerabilities. It doesn't tell you whether your SIEM would catch the exploit, whether your EDR would flag the lateral movement, or whether anyone on your security team would notice. Assumed breach testing does because it generates real attacker behavior in your environment and measures whether your detection and response controls fire.

The operating assumption in 2026 for any organization with meaningful data assets is not "we'll try to prevent every breach" but "when a breach happens, how quickly do we know, and how much can the attacker reach before we do?" Assumed breach testing is how you get an honest answer.

Assumed Breach vs Traditional Pentest

These aren't competing approaches they answer different questions. Understanding when to use each determines whether your security testing program reflects actual risk.

When to use assumed breach testing vs traditional pentest:

Use a traditional pentest when you need to assess external attack surface, satisfy a first-time compliance requirement, or evaluate a specific new system before deployment. Use assumed breach testing when you've already hardened the perimeter and want to know how far an attacker could move internally or when a compliance assessor asks how your organization would detect and contain an insider threat or post-compromise scenario.

Many mature security programs run both annually: a traditional external pentest for perimeter assurance and compliance reporting, plus an assumed breach engagement to validate internal defenses, detection controls, and segmentation.

When Compliance Frameworks Recommend Assumed Breach Testing

No major compliance framework explicitly mandates assumed breach testing by name yet. But auditors and assessors across all three major frameworks are increasingly asking questions that only assumed breach evidence can answer.

SOC 2 (CC7.1, CC7.2 — System Monitoring and Incident Response)

SOC 2's monitoring criteria require organizations to demonstrate that they detect security events and respond effectively. CC7.1 requires ongoing monitoring for threats. CC7.2 requires evidence that security incidents are identified, responded to, and recovered from.

Assessors evaluating these criteria for mature organizations are increasingly asking: "How do you know your monitoring would catch a real threat?" A traditional pentest that finds externally exploitable vulnerabilities doesn't answer that. An assumed breach engagement that generates real lateral movement behavior and measures whether your SIEM, EDR, and SOC team detected it does.

For more on what SOC 2 auditors expect from pentesting broadly, see our SOC 2 Penetration Testing Requirements guide.

HIPAA (§164.308(a)(6) — Security Incident Procedures)

HIPAA's Security Rule requires covered entities to implement policies and procedures to address security incidents. The natural question from an OCR auditor: "Have you tested whether you'd actually detect an incident involving ePHI?" Assumed breach testing specifically simulating post-compromise behavior in environments that handle protected health information produces the most direct evidence that incident detection and response capabilities work.

ISO 27001 (Annex A.16 — Information Security Incident Management)

ISO 27001 Annex A.16 requires incident management processes to be established, documented, and tested. "Tested" is the operative word. Tabletop exercises satisfy the documentation requirement. Assumed breach testing satisfies the technical validation requirement demonstrating that detection capabilities actually fire and response procedures actually work when a real attack pattern is generated in the environment.

What Assumed Breach Testing Covers

The scope of an assumed breach engagement depends on the specific threat scenario being simulated. Most engagements cover some combination of the following:

Lateral Movement

Starting from the initial foothold typically a compromised user workstation or low-privilege service account testers attempt to move through the internal network to higher-value targets. This includes: network scanning from the internal perspective, exploitation of unpatched internal systems, abuse of trust relationships between systems and services, and pivoting through network segments that should be isolated.

Lateral movement findings reveal whether your internal segmentation is effective, which internal systems are over-exposed to each other, and how far a real attacker could travel from a single compromised endpoint.

Privilege Escalation

From a low-privilege starting position, testers attempt to obtain domain administrator access, local admin rights on sensitive systems, or access to service accounts with elevated permissions. Common paths include: misconfigured Group Policy, exploitable local vulnerabilities on unpatched systems, Kerberoasting and AS-REP roasting attacks against Active Directory, abuse of over-permissioned service accounts, and token impersonation techniques.

Privilege escalation findings are among the most critical outputs of assumed breach testing because domain administrator access is typically game over for most organizations.

Credential Theft

Testers harvest credentials from the foothold environment and attempt to use them to expand access. This includes: extracting credentials from memory using tools and techniques analogous to Mimikatz, accessing credential stores and password managers, harvesting browser-saved credentials, and identifying accounts with weak or reused passwords that allow password spraying.

Credential theft findings directly inform password policy, MFA adoption, and privileged access management (PAM) gaps.

Data Exfiltration Simulation

Testers identify the paths an attacker would use to extract sensitive data customer records, source code, financial data, ePHI and simulate exfiltration using techniques that bypass common DLP controls. The goal isn't to actually exfiltrate production data but to map the viable paths and measure whether any alerting fires.

Detection and Response Measurement

Throughout the engagement, testers document which actions generated alerts, which were silently executed without detection, and how quickly if at all the security team responded. This produces one of the most valuable outputs of assumed breach testing: a clear picture of your actual detection coverage versus your assumed detection coverage.

Many organizations discover that their SIEM has significant blind spots, their EDR is not deployed uniformly across endpoints, or their SOC team's response time to real attack patterns is far longer than their documented SLAs suggest.

Active Directory and Identity Security

Active Directory remains the primary target in the vast majority of enterprise breaches. Assumed breach testing specifically targets: AD misconfiguration (ACL abuse, unconstrained delegation, AdminSDHolder issues), BloodHound attack path analysis to identify shortest paths to Domain Admin, abusable trust relationships between domains and forests, and legacy protocol exposure (NTLM, NTLMv1, LDAP unsigned).

How SecurityWall Conducts Assumed Breach Engagements

SecurityWall's assumed breach testing service is structured around three phases: scoping the threat scenario, executing the engagement, and producing actionable output.

Phase 1: Threat Scenario Definition

Before any testing begins, we work with you to define the specific threat scenario being simulated. The most common options:

• Compromised user workstation — Testers start as a standard domain user on a corporate endpoint, simulating a successful phishing attack or drive-by compromise
• Compromised service account — Testers start with credentials for a service account with network access, simulating a credential theft or insider scenario
• DMZ foothold — Testers start on an internet-facing system within the DMZ, simulating a successful exploitation of an external service
• Vendor/contractor access — Testers start with third-party access credentials, simulating a supply chain or partner compromise

The scenario choice should reflect your actual threat model the types of initial access your organization is realistically exposed to.

Phase 2: Engagement Execution

Our testers operate using real attacker tooling and techniques the same tools, frameworks (Cobalt Strike, Sliver, Metasploit), and methodologies that actual threat actors use. This is intentional: testing with sanitized or simulated tools produces sanitized results. Your detection capabilities need to be tested against the actual signatures and behaviors they'll encounter in a real incident.

Throughout the engagement, testers document every action taken, every system accessed, and every credential obtained building the complete attack path narrative that becomes the foundation of the final report.

Engagement duration is typically 5–10 business days for most environments. Complex environments with large Active Directory estates or multiple network segments may require longer.

Phase 3: Detection and Response Measurement

At the conclusion of active testing and optionally during we compare the attack timeline against your security team's alert and response records. This reveals: which attack phases generated no alerts, which alerts were generated but not actioned, and which detections fired and led to actual response. This comparison is frequently the most operationally valuable output of the entire engagement.

Related: if you're evaluating a continuous approach to post-compromise visibility, SLASH provides ongoing assumed-breach-style assessment as part of its PTaaS model, rather than as a point-in-time engagement. For more on continuous testing models, see our PTaaS Buyer's Guide.

What a Complete Assumed Breach Report Looks Like

An assumed breach report is structured differently from a traditional vulnerability report because the findings aren't just a list of vulnerabilities. They're a narrative of what an attacker could accomplish and what your organization would have done about it.

A complete SecurityWall assumed breach report includes:

Executive Summary A concise narrative of the engagement: starting position, key milestones reached (lateral movement, privilege escalation, data access), and overall assessment of internal security posture. Written for a CISO or board audience clear, non-technical, and focused on business risk.

Attack Path Narrative A chronological walkthrough of the full attack chain from initial foothold to furthest point of access achieved. Each step includes the technique used, the evidence captured, and the business impact if a real attacker had taken that path.

Technical Findings Individual findings for each exploited vulnerability, misconfiguration, or control gap with severity ratings, technical evidence, proof-of-concept details, and remediation guidance. Structured identically to a traditional pentest report for any findings that overlap with vulnerability assessment scope.

Detection Coverage Analysis A breakdown of which attacker actions were detected by existing security controls (SIEM rules, EDR alerts, network monitoring) and which were executed without generating any alert. This section directly measures the gap between assumed and actual detection capability.

Active Directory Attack Path Map A visual representation of the privilege escalation paths identified, from starting user to Domain Admin showing exactly which misconfigurations enabled the escalation and what the fix is for each step.

Remediation Roadmap Prioritized remediation recommendations ordered by impact addressing both the technical vulnerabilities exploited and the detection gaps exposed. Includes specific configuration changes, policy updates, and tooling recommendations.

Compliance Mapping For organizations using the report to satisfy SOC 2 (CC7.1, CC7.2), HIPAA (§164.308(a)(6)), or ISO 27001 (Annex A.16) requirements, findings and recommendations are mapped to the relevant control references.

The perimeter-first security model is broken not because perimeter defenses don't matter, but because no perimeter is perfect and attackers know it. The relevant question for any organization with real data assets isn't "can we stop every attack?" It's "if something gets through, what can they reach, and would we know?"

Assumed breach testing answers that question directly. It's faster than a full red team engagement, more operationally valuable than a traditional pentest for mature environments, and increasingly expected by compliance assessors who want to see evidence that your detection and response capabilities actually work not just that you have them.

Related reading:

• Assumed Breach Testing Service
• Red Team Operations
• SOC 2 Penetration Testing Requirements 2026
• Penetration Testing Services
• PTaaS: The Complete Buyer's Guide