Assumed Breach Assessment
Skip the front door and answer the real question: if an attacker is already inside, how bad is it? We start from a foothold and measure lateral movement, escalation and data access.
What is Assumed Breach Assessment?
Rather than spend the budget getting in, we start inside — a plausible foothold — and measure the blast radius. How far does an attacker reach, how fast, and would you notice? It's the most efficient way to test real resilience.
Getting in is only the first step of a real attack, and often the least interesting one to test. An assumed-breach assessment skips it deliberately: we start from a plausible foothold and spend the whole engagement on what actually determines impact — how fast an attacker escalates, how far they spread, what they can reach, and whether your detection ever fires. It's the most efficient way to measure real resilience.
An assumed-breach assessment also gives you the most honest answer to the board's real question: 'if we get hit, how bad is it?' Rather than debating the probability of initial access, it measures the consequence — the thing you can actually control through segmentation, least privilege and detection — and proves how much those investments would limit a real incident.
Assumed Breach Assessment is a manual, exploit-driven assessment: real people attacking your target the way an adversary would, then proving each finding with a working proof of concept. It is not an automated scan with a logo on it — the point is to find and demonstrate the issues that actually put you at risk, and hand your team a clear plan to fix them.
Why it matters
Real adversaries don't follow a checklist — they pursue an objective and adapt. Testing controls in isolation tells you nothing about whether your people and detection would actually stop an intrusion in progress.
A assumed breach assessment engagement replaces guesswork with evidence. Instead of hoping your controls hold, you get a ranked, reproducible picture of where they don’t — before someone hostile finds the same gaps.
Industries & use cases
Assumed-breach testing suits organisations that have hardened their perimeter and want to test what's behind it, and any business whose nightmare scenario is ransomware or insider compromise.
What we test
Manual, exploit-driven coverage focused on real impact — not scanner noise.
- Lateral movement from a foothold
- Privilege escalation paths
- Credential theft and reuse
- Access to sensitive data
- Detection and response gaps
- Blast-radius mapping
Signs you should run a assumed breach assessment
If any of these apply, testing is overdue.
- You've hardened the perimeter and want to test what's behind it
- Ransomware or insider risk is a top concern
- You want to measure impact, not just probability
- You have sensitive data on internal systems
- You need evidence to justify segmentation investment
Common vulnerabilities we find
The issues that show up again and again in assumed breach assessment — and the ones that actually get exploited.
Rapid escalation
A foothold becoming admin within hours.
Sensitive data reach
Access to crown-jewel data from a low-privilege start.
Containment failure
No segmentation or detection to limit spread.
Excessive standing privilege
Everyday accounts with far more access than their role needs.
No lateral-movement detection
Credential reuse and pivoting that generates no alerts.
Path to crown jewels from any user
Sensitive data reachable from an ordinary starting account.
No containment between segments
Nothing to stop lateral movement once inside.
Detection blind to internal activity
Escalation and pivoting that generates no alerts.
Example attack chain
Real impact rarely comes from one bug — it comes from chaining several. A representative example:
Why choose webhook.press
Attacker mindset
We’re offensive security people who also build the free tools bug-bounty hunters use daily. We test the way real adversaries do — and prove it.
No scanner theatre
You get findings a human exploited and verified, ranked by real business risk — not an unfiltered tool dump padded to look thorough.
Fixed price, free retest
A clear quote after scoping, a report your team and auditors can use, and a free retest to confirm the fixes hold.
Our methodology
A structured, transparent process aligned to OWASP and PTES — with a named point of contact throughout.
Scoping & rules of engagement
We agree the exact targets, depth, timing and constraints for your assumed breach assessment, and set clear rules of engagement so testing is safe and predictable.
Reconnaissance & mapping
We enumerate the full attack surface — endpoints, roles, technologies and trust boundaries — and threat-model where an attacker would focus.
Manual testing & exploitation
We attack by hand, verifying and chaining weaknesses into real impact. Automated tooling supports coverage; humans find the logic and authorization bugs it can’t.
Analysis & risk rating
Each finding is validated, rated by real business risk rather than raw scanner severity, and de-duplicated so you get signal, not noise.
Reporting
You receive an executive summary for leadership and a technical section with reproducible PoCs, evidence and concrete, stack-specific remediation.
Free retest
After you remediate, we re-test the closed findings to confirm they are actually fixed — at no extra cost.
What you get
Reproducible PoCs
Every finding ships with a working proof and step-by-step reproduction your engineers can replay and verify.
Risk-ranked findings
Prioritised by real business impact, so you fix what matters first instead of drowning in low-severity noise.
Actionable remediation
Concrete, stack-specific fixes and guidance — not generic “apply best practice” filler.
Free retest
We re-check the closed findings after remediation and confirm they’re resolved.
The report is written for two audiences at once: an executive summary that a non-technical stakeholder can act on, and a detailed technical section — findings, evidence, CVSS and reproduction — that your developers and auditors can use directly.
Manual testing, not just a scan
Automated scanners are fast and useful for coverage, but they only find patterns they already know, and they flood you with false positives. They cannot understand your business logic, chain several small issues into a breach, or tell you which alert actually matters. Our assumed breach assessment is led by experienced testers who exploit findings by hand and rank them by the damage they’d really do — the difference between a 300-page tool dump and a short list of things worth fixing.
Standards & compliance
Our assumed breach assessment reports are written to support the frameworks your auditors and customers care about — including SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, and the EU’s NIS2 and DORA. Each engagement produces clear, independent evidence of testing with scope, methodology and findings documented the way assessors expect, so the same test both hardens your systems and helps satisfy your obligations.
Frameworks we follow
Recognised methodologies, adapted to your target — never a rigid checklist.
- OWASP — Web Security Testing Guide, ASVS and the API Security Top 10
- PTES — the Penetration Testing Execution Standard
- NIST SP 800-115 — technical guide to security testing
- OSSTMM — Open Source Security Testing Methodology Manual
- MITRE ATT&CK — to frame real-world adversary techniques
FAQ
Why assume breach?
Because prevention eventually fails. This measures resilience and containment, the things that limit real incidents.
What foothold do you start from?
A standard workstation, a low-privilege account, or a device on the network — your choice.
Why assume breach instead of testing the perimeter?
Because prevention eventually fails; this measures containment and detection, which decide how bad a real incident becomes.
What foothold do you start from?
A standard workstation, a low-privilege account or a device on the network — your choice, matched to your threat model.
Is this cheaper than a full external-to-internal test?
Often — by starting inside, budget goes to measuring impact rather than re-proving that initial access is possible.
What starting point do you use?
A standard user, a low-privilege account or a device on the network — matched to your threat model.
How long does a assumed breach assessment take?
Most focused engagements run one to two weeks depending on scope; we agree the exact timeline during scoping.
Is a retest included?
Yes — after you remediate, we re-check the closed findings to confirm they’re fixed, at no extra cost.
How do you price it?
Per engagement, based on scope and depth — you get a fixed quote after a short scoping call. No cookie-cutter packages.
Why teams trust our assumed breach assessment
Aligned to recognised standards
Testing follows OWASP, PTES, NIST SP 800-115 and MITRE ATT&CK, and reports support SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, NIS2 and DORA.
Every engagement includes
Reproducible PoCs, risk-ranked findings, concrete remediation, a named point of contact, a free retest, and a summary letter of attestation.
Confidential by default
Work is covered by an NDA, scoped with clear rules of engagement, and data is handled with care throughout — including residency requirements.
Sample report available on request — see our reporting format and depth before you commit. Ask for a sample →
Get a quote for Assumed Breach Assessment
Tell us about the target — we’ll come back with scope and a fixed price. Manual, exploit-driven testing with reproducible proof and a free retest.