Key takeaways
- An assumed-breach engagement is not a replacement for a perimeter test: it answers what an attacker can do once inside, not whether they can get in.
- Three scoping decisions drive everything: the type and privilege of the granted foothold, the objectives the operator must reach, and the permitted depth of lateral movement.
- A credible proposal names the technique families the operator will use, maps them to MITRE ATT&CK, and states which controls the engagement is designed to test.
- Engagement duration runs from five to fifteen days of operator time; the main cost driver is the number of distinct objectives and the complexity of the target environment.
- Findings that the operator reaches undetected are a detection backlog: each one is a SIEM rule that does not yet exist.
When an assumed-breach exercise belongs in your programme
A penetration test answers whether an attacker can get in. An assumed-breach exercise asks what happens after that question is settled: starting from a foothold you grant, an operator works through your environment toward a named objective. The two complement each other; they do not duplicate.
The exercise belongs in your programme when you have enough baseline detection to make it meaningful. Running one against a network with no EDR, no SIEM and no logging baseline produces a finding list rather than a detection test. NIST SP 800-115 frames technical testing as part of a continuous assessment cycle rather than a one-off event, and an assumed-breach engagement is the step that answers whether the programme is working after the baseline is in place.
A secondary trigger is a significant architecture change: a cloud migration, a merger or a new privileged-access model. These alter the attack surface in ways a perimeter test will not reach, and an operator starting from a known internal position can traverse the new boundary before production traffic does.
Baseline
External pentest
What is exposed and reachable from outside
Infrastructure pentest
Internal hosts, segmentation and privilege
Assumed breach
Granted foothold
Workstation, service account or cloud token
Objective-led traversal
Lateral movement, credential access, exfiltration
Detection-led
Purple team
Tune rules against confirmed technique gaps
Retest
Verify the fixes held
The three scoping decisions that determine what you get
Every assumed-breach engagement is defined by three choices made at scoping. The first is the foothold: what type of access the operator starts with and at what privilege level. A standard-user workstation, a service account, a compromised developer laptop and a cloud token each produce a different test. How foothold selection sets the bounds on objectives is covered in detail in a companion article in this cluster.
The second is the objective set. Reached objectives are the measure of a successful engagement, not hours billed. Common objectives include reaching a named file share, obtaining domain credentials, accessing a target application as a privileged user, or pivoting from an on-premises workstation into a cloud tenant. The MITRE ATT&CK framework provides the vocabulary for expressing objectives as tactic-level targets rather than freeform descriptions, which makes the scope unambiguous on paper and reviewable after the fact.
The third is depth: whether the operator should stop at the first route to each objective or map all viable paths, and whether post-exploitation collection is in scope. A wider depth produces a richer finding set and a longer engagement. Define this explicitly rather than leaving it to be interpreted at runtime, because an operator who finds a second path to the crown jewel should know whether to document it or stop. A missing depth definition is the most common source of scope disputes on delivery.
How to read a proposal: five things to check before signing
A proposal that does not name the techniques to be used is a proposal for a generic pentest with a different title. The five checks below distinguish a scoped exercise from an undifferentiated service description. Compare these against a red team engagement proposal to understand the difference in scope and intent: a red team starts from zero access and includes initial access phases the assumed-breach engagement deliberately skips.
Use this checklist as a baseline. A vendor who cannot answer all five points at proposal stage is unlikely to scope the work precisely once it starts.
| # | What to look for | Why it matters | What to ask if it is missing |
|---|---|---|---|
| 1 | Named technique families mapped to MITRE ATT&CK tactics: credential access, lateral movement, collection, exfiltration | Scope ambiguity shifts cost risk to the buyer and leaves the objectives undefined | Ask for a technique table by tactic; if the vendor cannot produce one, the engagement is not scoped |
| 2 | Specific foothold type and privilege level | Foothold privilege determines which objectives are reachable and sets the exercise difficulty | Provide two or three foothold options and ask the vendor to price each: the price spread tells you how well the scope is understood |
| 3 | Named objectives with a pass or fail criterion for each | An engagement without measurable objectives cannot be retested or compared across years | Ask for a one-line success definition per objective before signing |
| 4 | Rules of engagement covering out-of-scope systems, evidence handling and notification thresholds | Assumed-breach operators traverse production systems; a missing rule causes a real incident | Demand a signed rules-of-engagement document, not a paragraph inside the statement of work |
| 5 | Deliverable format and remediation guidance | A finding list without remediation steps produces a second engagement to answer the first one | Ask for a sample report from a comparable engagement with client details redacted |
Evaluating vendors: what a strong answer looks like
The proposal checklist tells you what should be present. The table below gives you the next layer: for each criterion, what a credible answer looks like versus a weak one, and how to verify it before you commit. A fixed rubric makes vendor assessments faster because the same four columns apply to every response rather than a different question per conversation.
Two criteria recur in every real evaluation. The first is the operator's ability to explain technique selection in plain terms. The second is a documented process for exiting cleanly without leaving persistence on production hosts. Both are easy to ask for, easy to verify and predictive of engagement quality.
| Criterion | Strong answer | Weak answer | How to verify |
|---|---|---|---|
| Technique breadth | Covers credential access, lateral movement and at least one cloud or identity-layer tactic | Focuses only on network-layer movement with no identity or cloud coverage | Ask for the last three ATT&CK technique IDs used in a comparable engagement |
| Operator background | Operators have documented assumed-breach or red team experience and can name engagements by sector | Generalist pentesters rotated onto the engagement at scheduling time | Request CVs; ask which named team member leads the work |
| MITRE ATT&CK mapping | Finding table includes tactic, technique ID and sub-technique for each step taken | Findings reference a tactic name without naming a technique | Ask for a sample finding with the ATT&CK reference filled in |
| Detection reporting | Report includes a per-finding column on whether the technique was detected, by which control and at which stage | Report lists what was reached but not what was visible to defenders | Ask whether the deliverable includes a detection-gap analysis or only a finding list |
| Rules of engagement | Produces a standalone RoE document signed before work starts, with a pause-and-notify protocol | Rules of engagement is a paragraph in the statement of work with no defined stop conditions | Ask to see the RoE template before scoping; if none exists, write one into the contract |
| Cloud and identity coverage | Includes token theft, conditional access bypass or role escalation in the cloud tier if the environment uses one | Stops at the domain boundary with no cloud pivot | Ask whether the engagement covers Azure AD, AWS IAM or similar if your environment includes them |
| Remediation guidance | Each finding includes a specific remediation step tied to the control it tests | Finding names the gap without naming the fix | Request a sample remediation section from a previous engagement |
| Retest policy | Includes a defined retest window and a pass or fail retest report in the base price | Retest is quoted separately at full engagement price | Ask for the retest scope and timeline in writing before signing |
What drives duration and cost, and what to challenge
Assumed-breach engagements run from five to fifteen days of operator time measured against production. Five days is a focused single-foothold exercise with two or three objectives in a bounded on-premises environment. Fifteen days reflects a complex scope: multiple foothold types, cloud and on-premises traversal, and an objective set that includes crown-jewel access across two or more systems. An engagement quoted below five days for a non-trivial scope is almost certainly under-scoped. An engagement quoted above fifteen for a standard enterprise environment is worth challenging for scope clarity.
The main cost drivers, in order of impact, are the number of distinct objectives, the complexity of the cloud footprint, the number of operator days required, and whether the rules of engagement require daily check-ins with a control team. Ask the vendor to break the quote into these components. A line item for operator time with no further breakdown is a sign the pricing is not tied to the scope.
The most common unnecessary cost is a generic external reconnaissance phase included in an engagement that starts from a granted foothold. An assumed-breach exercise does not need to re-establish the external perimeter: that work belongs in a penetration testing or infrastructure pentest engagement. If the proposal includes two days of external reconnaissance at the start of a foothold-led exercise, ask what it delivers that the foothold brief does not already assume. The NIST Cybersecurity Framework identifies identify and protect controls separately from detect and respond controls, which is exactly the distinction an assumed-breach engagement is designed to test.
The technique difference between a cloud-tier pivot and an on-premises lateral movement chain also matters for pricing. Cloud token theft and tenant traversal add a distinct phase with its own tooling and operator time. LSASS memory dumping and credential extraction follow a different hour profile. A vendor quoting both at the same day rate has either bundled them without modelling the time or has not thought through the scope. Ask which phases are included and what each one tests.
Connecting findings to your detection programme
The finding report from an assumed-breach engagement has a second use that most buyers do not extract: it is a detection backlog. Every technique the operator used without triggering an alert is a rule that does not exist in your SIEM. What your SIEM should catch during an assumed-breach exercise maps the technique categories to the signals your logging pipeline should be producing. If the engagement found a gap, the gap has a name, a MITRE technique ID and a log source: that is enough to write a detection rule without running a second exercise.
The exercise makes most sense in a programme that continues with purple teaming after the findings are in. Purple teaming replays the techniques in a controlled setting where the detection team is watching in real time. The assumed-breach engagement tells you which techniques reached the objective undetected; the purple team builds and validates the rules that would have stopped them. One without the other is half a cycle. Running the assumed-breach exercise first gives the purple team a verified technique list to work against rather than a generic ATT&CK tier to sweep.
Detection maturity
Purple team
Tune and verify existing rules. Detection is in place; confirm it fires on real
Red team
Full campaign from zero access. Detection is mature enough to be tested under real
Pentest first
Establish what is exposed before testing what detection catches.
Assumed breach
Find what reaches the crown jewel undetected. Detection has gaps; map and close them.
Known internal attack
Assumed-breach testing in the UAE: what buyers in Abu Dhabi and Dubai need to know
Buyers in Dubai and Abu Dhabi approach assumed-breach procurement from two different regulatory contexts. Entities regulated by the Central Bank of the UAE under Circular 8 of 2020 are required to conduct scenario-based red team exercises for their most critical systems. An assumed-breach engagement satisfies that requirement when the objectives are tied to the systems named in the circular and the rules of engagement are documented. The CBUAE does not prescribe the exact format of the exercise, which means the scoping decisions above apply in full: the buyer chooses the foothold and the objectives, and the vendor is accountable for technique coverage and reporting.
In Dubai, entities subject to the Dubai Electronic Security Centre standards, including government bodies and their technology suppliers, face requirements under the DESC Cyber Security Standards framework for advanced threat simulation proportionate to the criticality of the system under test. The DESC framework applies to Dubai government entities directly and extends to their technology suppliers through contractual requirements. A free-zone entity operating in Dubai Silicon Oasis or DIFC is not directly subject to DESC, but a supplier to a DESC-regulated entity may be required to demonstrate assumed-breach testing as part of supplier assurance.
In Abu Dhabi, healthcare entities regulated under ADHICS and government entities subject to the Abu Dhabi Information Security Standards both require technical security testing at a level of depth appropriate to the classification of the data processed. Assumed-breach testing at the higher-classification tiers satisfies this requirement. The DoH Abu Dhabi publishes ADHICS guidance separately from the federal UAE Information Assurance Standards published by TDRA, and both apply to their respective entity types.
Procurement cycles in both emirates tend to require a statement of work rather than a purchase order, which means the proposal checklist above applies directly to the tendering process. UAE-based buyers should include a requirement for a signed rules-of-engagement document in any tender, because the rules of engagement is the document that separates a contracted exercise from an unauthorised intrusion under UAE cybercrime legislation. This is not a formality: an operator traversing a production network without a signed document naming the scope is exposed, as is the entity that authorised the work verbally.
Frequently asked questions
What is an assumed-breach engagement?
An assumed-breach engagement is a security exercise in which the operator starts from a foothold you grant rather than attempting to breach the perimeter from outside. The foothold is typically a standard-user workstation, a service account or a cloud token. The exercise tests what an attacker can do once inside: lateral movement, credential access and reaching named objectives. It does not test whether the perimeter holds.
How does an assumed-breach exercise differ from a red team engagement?
A red team engagement starts from zero access and includes the full kill chain: reconnaissance, initial access, execution, persistence and lateral movement. An assumed-breach exercise skips the initial access phase and begins from a granted foothold. This makes it faster, more focused and less dependent on perimeter defences. The trade-off is that it does not test whether an attacker can gain access in the first place.
How does an assumed-breach exercise differ from a penetration test?
A penetration test typically works from the outside in, testing whether known vulnerability classes are present and exploitable. An assumed-breach exercise starts from inside and works toward named objectives, testing what an attacker who already has a foothold can reach. A penetration test is usually the right starting point; an assumed-breach exercise is the right follow-on once the external surface is understood.
What foothold types are used in an assumed-breach exercise?
The most common foothold types are a standard-user domain workstation, a privileged service account, a developer laptop with cloud credentials, and a valid cloud token for Azure AD, AWS IAM or a similar identity plane. The foothold type should match your threat model: a supply-chain risk calls for a developer-privilege foothold, while an insider threat scenario calls for a standard-user one.
How long does an assumed-breach engagement take?
Operator time runs from five to fifteen days depending on the number of objectives, the complexity of the cloud footprint and the depth of lateral movement in scope. Five days covers a focused single-foothold exercise with two or three objectives in a bounded on-premises environment. Fifteen days reflects a multi-foothold exercise with cloud and on-premises traversal and a wider objective set.
What should an assumed-breach report contain?
A credible report contains a finding for each technique used, mapped to a MITRE ATT&CK tactic and technique ID, with a description of the step, evidence of execution, the detection status at the time of the exercise, and a specific remediation step. It should also include a detection-gap summary: which techniques were not seen by any monitoring control and which log source would have caught them.
Does an assumed-breach exercise require active monitoring to be in place?
Not as a technical prerequisite, but as a practical one. An exercise run against a network with no EDR, no SIEM and no logging produces a finding list rather than a detection test. The value of the exercise is in knowing which techniques were visible to your defences and which were not. Without monitoring, the detection-gap analysis is empty and the exercise answers only whether objectives were reached, not whether they would have been noticed.
What UAE regulations ask for assumed-breach testing?
No UAE regulation currently mandates assumed-breach testing by name. CBUAE Circular 8 of 2020 requires banks and financial institutions to conduct scenario-based red team exercises aligned with international standards; an assumed-breach engagement satisfies that requirement when scoped against named objectives. DESC Cyber Security Standards for Dubai government entities include requirements for advanced threat simulation. NESA's UAE Information Assurance Standards require technical testing proportionate to the risk profile of the system.
How do assumed-breach findings connect to SIEM tuning?
Each technique the operator used without triggering an alert represents a missing or misconfigured detection rule. The finding report maps each technique to a MITRE ATT&CK ID, which in turn maps to a log source: process creation events for credential-dumping techniques, network flows for lateral movement, API call logs for cloud pivots. The finding list is a detection backlog: each undetected finding is a rule to write.
Can an assumed-breach exercise be run in a cloud-only environment?
Yes. A cloud-native assumed-breach exercise starts from a compromised identity, such as a stolen access token or a misconfigured service principal, and tests lateral movement within the cloud control plane: privilege escalation through misconfigured roles, access to storage or secrets, and pivots between subscriptions or accounts. Confirm the vendor has specific cloud-tier experience before scoping; cloud and on-premises assumed-breach work require different tooling and technique knowledge.
How many objectives should an assumed-breach engagement have?
Two to four objectives is the typical range for a focused engagement. Fewer than two produces a narrow finding set that does not justify the cost; more than four tends to dilute operator focus and extend the timeline without a proportionate increase in findings. Each objective should be specific enough to have a clear pass or fail criterion: reaching a named system, obtaining a credential class or exfiltrating a defined file type rather than a generic goal like demonstrating lateral movement.
