Assumed breach testing

When assumed breach testing answers the question your auditor or customer is asking

Assumed breach testing answers one question directly: if an intruder were already inside, could they move laterally, escalate privileges and be detected in time? Frameworks, customer security reviews, product launches, insurers and due diligence requests often ask this in some form, even when they do not use the term. The test starts from a foothold that the testers are given, such as a standard user account or a workstation, so the budget goes to measuring what happens next rather than to finding a way in. That makes it a direct answer to questions about internal segmentation, identity controls and the ability of the security operations team to notice and respond.

The risks it addresses sit in the middle of an intrusion. Testers look at whether a low-privilege identity can reach file shares, directory services, management interfaces or cloud control planes it has no business reaching, whether local administrator credentials or service accounts can be reused across machines, and whether privileged paths such as domain administration can be reached from ordinary workstations. Equally important is the detection side: whether authentication anomalies, credential access, new remote services and unusual administrative activity generate alerts, and whether those alerts reach someone who acts on them. Gaps here are often more costly than any single misconfiguration, because they decide how far an incident spreads before anyone responds.

Before commissioning this test, confirm with your auditor or customer exactly what evidence they expect, such as the starting account type, the target systems in scope, the logs they want reviewed and the form of the final report. Ask the provider how the foothold is provided, which boundaries stop the exercise, and how findings will be validated against your own logging and alerting. Agreeing these points in writing turns a general request for assurance into a defined test with results you can show and act on.

What can be in scope for an assumed breach test

An assumed breach test is only as useful as its boundaries. The starting foothold, the systems in bounds, the privilege level that counts as success and the stop conditions all need to be agreed in writing before testing begins. The cards below cover the decisions that shape the engagement and the limits the client must confirm for its own environment.

Choosing the starting foothold

The foothold is the account or device the testers begin with, such as a standard domain user, a workstation under a user's control, a service account or a cloud identity with limited rights. The choice sets the question being answered: a standard user tests whether a common compromise can climb, while a service account tests whether automation credentials expose more than their owners intended. Agree the foothold, how it is issued, and whether it is rotated or revoked at closure.

Network segments and identity systems

Define which network segments, domain controllers, identity providers and management planes are in bounds for lateral movement. Ask whether production, backup and recovery networks are included, and whether the test may touch identity infrastructure that other services depend on. Name the systems explicitly in the statement of work so that testers and the control team work from the same map.

Endpoints and cloud tenants

Decide which endpoints, servers and cloud accounts or subscriptions the testers may reach from the foothold. Cloud tenants often carry their own provider rules and shared responsibility boundaries, so confirm that each target is permitted under the provider's published testing policy. Note any systems hosted by third parties that need separate authorization before they are touched.

Target roles and privilege objectives

Name the outcomes that count as meaningful progress, such as domain administrator rights, access to a named data store, or control of a privileged management tool. Objectives tied to business impact give the report a clear measure of what an adversary could reach. Record which roles are off limits, for example individuals' personal mailboxes or payroll data, so that objectives do not create data handling issues.

Stop conditions and rules of engagement

The rules of engagement set when testers must stop or escalate, such as detection of live customer harm, access to regulated personal data beyond the objective, or instability in a production service. NIST SP 800-115 describes covert testing that usually stops at defined boundaries, such as a certain level of access. Confirm with your own teams the environment-specific limits, the named contacts for emergencies, and the time windows for testing.

How an assumed breach engagement runs, phase by phase

The sequence turns a provided foothold into a measured test of lateral movement, privilege escalation and detection, with each phase producing a written record the client can act on. Scope, rules of engagement and objectives are fixed before any testing starts, so every later finding can be traced back to an agreed question.

Agree scope and rules of engagement
The client and DeployOpen agree in writing which systems, networks and data are in bounds, what the starting foothold is, which actions are off limits and how testers will stop if something breaks. NIST SP 800-115 describes planning as the stage where the test's purpose, boundaries and authorization are documented before technical work begins. The step is complete when the signed scope names the foothold, the boundaries and the escalation contacts. Ask for the timing and the notice period in that written scope rather than assuming a standard duration.
Provision the agreed foothold
The client supplies the starting access, typically a standard user account or a workstation, through a method it chooses and records. The purpose is to skip initial access so budget and attention go to lateral movement, privilege escalation and detection. Testers confirm the foothold works from the agreed position and that the client's logging and identity controls are in the state the scope expects. The step closes with a short handover record listing what was provided, when and to whom.
Map objectives to ATT&CK tactics
Testers and the client translate business-relevant goals, such as reaching a particular data store or domain administration, into objectives mapped to MITRE ATT&CK Enterprise tactics. The Enterprise matrix lists 15 tactics, from Reconnaissance to Impact, and this mapping gives both sides a shared vocabulary for planning and reporting. The step closes when each objective has a named tactic set, the systems it touches and the success condition that will be recorded.
Test against objectives in controlled stages
Testers pursue the objectives from the foothold, moving laterally and escalating privileges within the defined boundaries. NIST SP 800-115 frames this as the execution stage, where testers validate suspected weaknesses and record evidence. A control or coordination function tracks activity, pauses testing when a boundary is at risk and keeps a timestamped log. The stage is complete when each objective is either achieved, blocked or stopped at a defined boundary, with the path and evidence recorded for each.
Validate detection and response
Because assumed breach testing measures what the defenders see, the client's security operations team checks whether the activity was logged, alerted on and triaged. Where the client agrees, a purple teaming style session walks through each technique so detection gaps are confirmed rather than guessed. The output is a per-technique record of telemetry present, alerts raised and response times observed, which shows where detection held and where it did not.
Deliver the findings report
DeployOpen issues a written report that separates attack paths, the weaknesses they exploited, the detection results and the remediation priorities. Each finding carries its evidence, the affected assets and a recommended fix that the client's engineers can implement. The step is complete when the client has accepted the report at a readout meeting and the rules of engagement for data handling have been honored in what the report contains.
Retest and close remediation
After the client fixes the issues it has chosen to address, DeployOpen retests the same paths and confirms whether each fix holds and whether detections now fire. This matters because CIS Controls v8.1 Safeguard 18.4 expects security measures to be validated after a penetration test, with rulesets and capabilities adjusted to detect the techniques used. The step closes with a retest record per finding. Confirm in the written scope whether retest is included or quoted separately.

Weakness categories an assumed breach test uncovers

This table compares the weakness categories an assumed breach test typically surfaces in an identity-centred environment, showing how each appears in the target, why it matters to the buyer and which defensive control addresses it. Read each row as a question to ask your own environment before and after the test, since findings usually cluster across several categories at once.

Weakness category	How it shows up in the target	Defensive control that addresses it
Excessive group membership	A standard user account inherits rights through nested or legacy groups that grant access to systems the user's role never needed.	Periodic access reviews of privileged and nested groups, with least-privilege role design and documented owners for each group.
Weak network segmentation	Workstations and user segments can reach server, management or identity subnets that should be restricted to specific sources and ports.	Documented segmentation rules between tiers, enforced with host and network controls, and verified against the intended flow matrix.
Credential reuse across tiers	The same local or service credentials appear on workstations and servers, so one compromised tier exposes the next.	Unique local administrator credentials per host, managed secrets storage and separation of administrative accounts from daily-use accounts.
Unmonitored lateral movement	Movement between hosts generates few or no events that reach the security operations team, or the events are not correlated.	Logging of authentication and remote administration on each tier, forwarded to a monitored platform with detection rules mapped to ATT&CK techniques.
Overly broad trust between identity systems	Trust relationships between directories or federated identity providers accept more principals or claims than the business case requires.	Reviewed trust scopes, selective authentication where supported, and periodic validation of federation claims and trust paths.
Missing alerting on privilege changes	Additions to privileged groups, role assignments or changes to policy objects occur without an alert or ticket reaching responders.	Alert rules for changes to privileged groups and directory objects, with tested escalation paths and documented response steps.

Choosing assumed breach testing over a full red team

Assumed breach testing starts the exercise after an attacker already has a foothold, such as a standard user account or a workstation. The tester skips initial access and spends the effort on what happens next: lateral movement, privilege escalation, reaching sensitive segments and whether the security operations team notices. This fits organizations whose main question is whether internal segmentation and detection work once a phishing email or stolen credential has succeeded. A full red team also tests how the adversary gets in, which is useful, but it can consume much of the engagement before any post-compromise control is exercised.

Post-compromise focus: Testers concentrate on identity, network paths, endpoint controls and logging from the foothold onward.
Detection measurement: The exercise shows which techniques are logged, alerted on and investigated, and where the gaps sit.
Segmentation proof: It tests whether a compromised workstation can reach domain controllers, backups or production data.
Purple team follow-on: Findings map to ATT&CK techniques, so detections can be tuned and retested.

Before you commit, confirm the starting account, its privileges and the boundaries the tester must respect, as NIST SP 800-115 describes for covert testing that stops at defined access levels.

What drives the cost and duration of assumed breach testing

This table compares each driver of assumed breach effort, who carries the cost, whether it is paid once or recurs, and what to request in a quote. Read it before comparing proposals, because two quotes for the same nominal test can differ mainly in the footholds, identity scope and reporting cycles they assume.

Cost driver	Who is paid for what	One-time or recurring	What to request in a quote
Number and role of starting footholds	Testers spend time establishing and documenting each foothold, then testing movement from it. Each additional role (standard user, helpdesk, developer, service account) adds a separate movement path to assess.	One-time per engagement, with added effort for each extra foothold or role	The list of footholds, the privilege level of each, and whether the client or the provider supplies the accounts and workstations
Size and segmentation of the environment	Larger estates and more network zones mean more hosts to map, more boundaries to test and more paths to document. Heavily segmented networks add validation work for each boundary the team tries to cross.	One-time, scaled to the environment in scope	Host and subnet counts, number of security zones, and which segments are excluded and why
Identity platforms in scope	Active Directory, hybrid identity sync and cloud tenants each require separate review of trust, delegation and privilege paths. Cloud tenant testing must stay within the provider's published testing rules.	One-time, with separate effort for each identity platform added	Named directories, tenants and synchronization links, and written approval from each tenant owner
Test depth and objectives	Deeper objectives, such as reaching a named crown-jewel system or a domain administrator tier, require more time per path. Broad coverage of many objectives costs more than a few well-defined ones.	One-time, set by the objective list agreed in the rules of engagement	Agreed objectives, stop conditions, and the boundaries testers must not cross
Detection validation and purple teaming effort	Confirming what is logged, alerted and investigated requires testers to run techniques alongside the defenders and review telemetry. Tuning detections after findings adds joint working sessions with the blue team.	One-time for the exercise, with possible recurring effort if detections are retested	Which log sources and SIEM or EDR tools are in scope, who on the blue team takes part, and whether tuning support is included
Reporting cycles and progress updates	Written status reports, control or debrief meetings and the final report each take provider time. Frequent updates on a longer test add cost even without new testing.	Recurring within the engagement, then one final report	Number and format of progress reports, final report content, and whether an executive summary is included
Retest after remediation	Retesting checks that the agreed fixes close the paths found and that detections now fire. It is priced separately because it repeats only part of the original work.	Recurring, after each remediation round	Retest window, number of retest rounds, and which findings are covered
Client-side preparation and access	The client pays internal staff time to provision accounts, approve access and support testers. Gaps here extend calendar time even when tester effort is unchanged.	One-time setup, with ongoing staff time during the test	A named internal contact, provisioning lead times, and the client tasks that the quote assumes

Frameworks that expect internal adversary testing

Several frameworks ask for testing that goes beyond finding vulnerabilities and checks whether controls, staff and detection hold up once an attacker is already inside. The cards below cover the frameworks most often raised in assumed breach scoping, what each expects in plain terms, and what your evidence needs to show to an assessor or regulator.

NIST SP 800-53 CA-8 penetration testing

CA-8 is the control that asks for penetration testing as part of a federal-style control baseline. Its enhancements add independent testers and red team exercises, so a program built on CA-8 can justify an assumed breach engagement as a form of red team testing. SP 800-53B selects CA-8 and CA-8(1) for the high baseline. Confirm with your assessor which enhancement they will map your evidence against, and agree in writing whether the starting foothold, its privilege level and the boundaries are documented in the rules of engagement.

CIS Controls Safeguard 18.4 validation

Safeguard 18.4 in CIS Controls v8.1 expects you to validate security measures after a penetration test and to adjust rulesets and capabilities so that the techniques used during testing are detected. For assumed breach work, this means the output is not only a findings list but a documented check that logging and alerting caught the lateral movement and escalation steps. Ask the provider to map each finding to the detection that should have fired and to retest that detection after your changes.

DORA threat-led penetration testing

DORA defines threat-led penetration testing as an intelligence-led, bespoke red team test of a financial entity's critical live production systems. Delegated Regulation (EU) 2025/1190 sets minimums for scenarios, test length and team composition. Assumed breach can form part of a TLPT programme, but it does not replace the threat-led scenarios that start from threat intelligence. Confirm with your competent authority which scenario types count toward your obligations and how the starting foothold is justified.

TIBER-EU closure and purple teaming

The TIBER-EU framework, as updated in January 2025 to align with DORA, makes purple teaming mandatory. Its closure phase includes red and blue team reports, a replay, a test summary report, a remediation plan and an attestation. Tests do not produce a pass or fail result. For an assumed breach exercise run under TIBER-EU, the replay and purple teaming steps are where detection gaps are confirmed. Ask who acts as the control team and how the foothold is agreed with the authority overseeing the test.

CBEST intelligence-led assessment

CBEST is a threat intelligence-led assessment used in the UK financial sector by the Bank of England, the PRA and the FCA since 2014. Its current implementation guide is the 2024 edition. Assumed breach can be a suitable scenario within a CBEST programme where the threat intelligence supports starting inside the network. Confirm with your supervisor how the intelligence provider, the testing provider and the scope boundaries are documented before the foothold is provided.

Covert testing expectations in NIST SP 800-115

NIST SP 800-115 describes covert testing as work done without the IT staff's knowledge but with upper management's permission. It tests technical controls, staff response to perceived incidents and policy knowledge, and usually stops at defined boundaries such as a certain level of access. This is the closest guidance to how assumed breach is commonly run, with a defined starting account and clear stopping points. Agree in writing who knows about the test, who can stop it, and how the boundaries are enforced.

How assumed breach testing differs across Active Directory, cloud and hybrid estates

On-premises assumed breach tests usually start from a standard domain user on a workstation or a segment of the internal network. The central question is how far that identity can travel once it is inside. Directory services concentrate trust, so the tester's attention goes to how group memberships, delegated administration, service accounts and domain trusts connect a low-privilege account to tier 0 assets. The output is a map of paths and the detections that did or did not fire along them, not a list of every misconfiguration in the domain.

Tiering model: whether administrative accounts are kept off user workstations and whether privileged sessions are restricted to designated administration systems.
Delegation and ACLs: how permissions on organizational units, groups and sensitive objects allow indirect control of privileged accounts.
Service accounts and credential exposure: where long-lived secrets are stored, who can read them and whether they are rotated.
Domain trusts and segmentation: which network zones, forests or trusts let the foothold reach management planes and backup infrastructure.
Logging and alerting: whether domain controller events, authentication anomalies and endpoint telemetry reach the security operations team in a usable form.

Confirm with the client which accounts are in scope, which domain controllers are production assets, and whether any test activity can be run against them during business hours.

What your team prepares before the test starts

Before an assumed breach test begins, your team owns several preparations that the testers cannot make for you. The most important is provisioning the agreed foothold: the standard user account, the workstation or the set of credentials the scope names, built to match the configuration of a real employee device, including its endpoint agent, group memberships and network placement. Your team also documents the in-scope systems and the boundaries that stop the test, such as production databases, identity providers that cannot be changed, or third-party services whose owners must be consulted first. Write these down in the statement of work, because the boundaries are what keep the exercise inside the authorization you signed.

Your team also decides who knows about the test, and that decision sets the design. NIST SP 800-115 describes covert testing as work performed without the IT staff's knowledge but with upper management's permission, which tests the technical controls, the staff's response to perceived incidents and policy knowledge. An overt or partly informed design changes what the detection team sees and how the result should be read, so choose it deliberately and record it. Whichever design you select, name a single escalation contact with authority to halt the test, and name a control team that holds the true timeline, can confirm activity to testers, and can resolve questions without tipping off the defenders being measured.

Finally, agree stop conditions and deconfliction in writing before day one. Stop conditions define when testers must pause, for example if a system shows signs of a real incident, if business operations are affected, or if an unrelated attacker appears in the logs. Deconfliction is the process by which the control team distinguishes testers' activity from genuine malicious activity, and it needs a contact who can answer quickly at any hour the test runs. Schedule change freezes for the testing window so that patches, firewall edits or identity changes do not alter the environment mid-exercise. Confirm these arrangements with your cloud and hosting providers as well, since their own testing rules may require advance notice.

What to check when choosing an assumed breach testing provider

An assumed breach test is only as useful as the team running it, so the provider's method, people and paperwork matter more than their pitch. The checks below connect a documented approach to the controls that protect the client's data and the test itself. Ask for evidence of each one before you sign.

Documented methodology mapped to standards

Ask for a written methodology that states how each phase maps to NIST SP 800-115 and to the MITRE ATT&CK Enterprise tactics used to plan and report the work. The document should explain how the provider chooses techniques from the starting foothold, how it records evidence, and how it decides when to stop. A provider that cannot show this in writing is asking you to trust its process without seeing it.

Named testers with relevant experience

Ask who will do the work, not only who will sell it. Request named testers with hands-on experience in Active Directory, identity, endpoint and detection engineering, and confirm whether the lead tester will be on the engagement from start to finish. Ask how the provider verifies that staff keep their skills current, and whether any subcontractors will touch your environment.

Rules of engagement practice

The rules of engagement should name the starting account or workstation, permitted and prohibited actions, systems and data in scope, testing windows, escalation contacts and the conditions for stopping. Confirm the provider will not move beyond the agreed boundary without written approval. Also check how the provider handles accidental impact on production services, which is a common gap in assumed breach work.

Data handling and retention

An assumed breach test collects credentials, hashes, directory data and host details, so the provider's handling of that material is a control in its own right. Ask where evidence is stored, who can access it, how it is encrypted, when it is destroyed and whether any client data leaves your environment. Get these terms in the contract, not only in a policy link.

CREST accreditation where required

Where your regulator, customer or insurer requires it, confirm that the provider and the individual testers hold current CREST accreditation or certification for the relevant discipline. CREST is a not-for-profit company registered in the UK that accredits and certifies across security testing, red teaming, threat intelligence and incident management. Check the register directly rather than relying on a logo, and confirm the accreditation covers the exact service you are buying.

Verifiable references and a sample report

Ask for references you can contact directly, and for a sample report with sensitive data removed. Read the sample for the things that matter in this test: the attack path narrative, the detection gaps identified, the evidence for each finding and the prioritized remediation advice. A report that lists generic vulnerabilities without explaining what the blue team did or missed will not help you tune detection.

Written fixed scope and deliverables

Most credible providers agree scope, deliverables and timelines in writing before work starts. Check that the statement of work lists the starting foothold, objectives, exclusions, testing windows, the reporting cadence, the retest terms and what happens if scope changes mid-test. Ask for the scope in writing before you request a quote, so price differences can be compared on like-for-like terms.

Questions buyers ask before commissioning assumed breach testing

How much effort does assumed breach testing take, and what drives it?

Effort depends mainly on how many systems are in scope, how many starting footholds the test uses, and how much of the environment the testers must map before they can move laterally. A single standard user account on one workstation, with a defined list of target systems, is a narrower job than several footholds across cloud tenants, on-premises directories and remote access. Other drivers include the number of identity sources, how much segmentation exists, and how much time the client's team needs to coordinate change windows and monitoring. Ask the provider to break the quote into planning, testing, reporting and any purple teaming, and to state the number of testers and their roles. No effort figure should be accepted until the written scope is agreed.

How long does an assumed breach engagement run?

The timeline is set by the number of target objectives, the size of the environment, and whether the test includes a debrief, a replay of attack steps, or purple teaming sessions with the blue team. Scheduling also matters: some hosting providers require advance notice before simulated attacks against their platforms. For example, AWS requires a simulated events request at least 2 weeks in advance for red, blue or purple team testing against AWS-hosted assets. Ask for phase-by-phase dates in the written scope, including preparation, testing, reporting and closure activities, and confirm which dates depend on the client's access approvals.

What does the client's team need to provide for the test?

The client needs to supply a foothold, meaning a defined standard user account or workstation, along with the rules of engagement, named contacts, and clear stop conditions. Architecture diagrams, asset inventories, network segmentation details and a list of critical systems help testers focus on what matters. A control or coordination contact should be able to answer questions during the test without alerting the wider security team, depending on whether the exercise is covert. Expect to confirm backup and rollback procedures for any system testers may touch, and to agree how sensitive data found during testing will be handled. Confirm each dependency in the written scope so delays are visible early.

Can our internal team run assumed breach testing without an external provider, and what is lost?

An internal team can run lateral movement and privilege escalation exercises, especially if it already has offensive security skills and an independent reviewer for findings. What an external provider usually adds is separation of duties, an outside view of attack paths the internal team has become used to, and documentation that auditors and customers may accept more readily. Internal teams also find it harder to test detection objectively, because they know the environment and may be tempted to avoid alerting their own colleagues. If you keep the work in-house, define the rules of engagement, record every action for later analysis, and have someone outside the test team validate the findings. Confirm with your auditor or regulator which independence expectations apply.

Is a retest included after assumed breach testing?

A retest is not automatically included, so check the written scope and quote for it. Retesting usually confirms that agreed fixes block the attack paths found during the original test and that detections now fire for the techniques used. Ask whether the retest covers only the findings or also repeats selected attack steps, how many retest windows are included, and how results are reported after remediation. CIS Controls v8.1 Safeguard 18.4 expects security measures to be validated after each penetration test, with rulesets and capabilities modified where needed to detect the techniques used. Build the retest into the plan from the start so the remediation cycle is funded and scheduled.

Does assumed breach testing replace a red team or a penetration test?

Assumed breach testing does not replace a red team or a penetration test. It answers a narrower question: once an attacker has a foothold, how far can they move, what do they reach, and does the defense notice. A penetration test aims to find and validate as many weaknesses as possible across a defined scope, while a red team exercise is objective-based, covert and includes initial access. NIST SP 800-53 Rev. 5 control CA-8 treats penetration testing, red team exercises and related testing as distinct enhancements. Choose assumed breach testing when initial access is already well covered by other work, when budget should focus on detection, or as a lower-cost step before a full red team. Where a regulator sets a threat-led testing standard, such as DORA TLPT, the required scope may not be met by assumed breach testing alone.

What should the written scope and quote include before work starts?

A useful quote lists the foothold and its privileges, the target systems and business objectives, the testing window, the rules of engagement, and the deliverables with their formats. It should also name the roles involved, state how emergencies and out-of-scope discoveries are handled, and explain how data is stored and destroyed. Ask whether the price covers reporting, a debrief, purple teaming and retesting as separate items. DeployOpen plans and runs security testing under fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. Ask for the same level of detail from any provider you compare.

What evidence does assumed breach testing produce for auditors and customers?

The core evidence is a report that maps each attack path to the techniques used, the systems affected, the detections that fired or failed, and the remediation steps agreed. Many buyers ask for mapping to MITRE ATT&CK, which lists 15 Enterprise tactics from Reconnaissance to Impact and is used to plan and report adversary emulation. Ask for timestamps, log references and the raw record of testing actions so your team can reproduce findings and check detections. The report does not replace an audit opinion or certification. Confirm with your assessor which artifacts they need and whether the provider's report format fits them.

How DeployOpen scopes, tests, reports and retests assumed breach engagements

DeployOpen treats each assumed breach engagement as a fixed-scope exercise agreed in writing before any testing starts. We set the starting foothold, the boundaries and the detection questions with your team, then document what was tested, what was detected and what needs remediation.

How we scope

Agree in writing which foothold is provided, such as a standard user account or a specific workstation, and who supplies it.
Define the objectives, for example lateral movement paths, privilege escalation routes and detection coverage to be measured.
Set boundaries on systems, data, times of testing and any actions that are off limits, so the engagement stops where the agreed scope ends.

How we build

Map the agreed objectives to MITRE ATT&CK Enterprise techniques so the planned activity and the later report use the same vocabulary.
Prepare the test accounts, access and logging needed so that the exercise measures your controls rather than our setup.
Agree a communication plan and an escalation path for the exercise, including who on your side knows the test is running.

How we hand over

Deliver a report that records each technique attempted, the controls that stopped or slowed it, and the detections that did or did not fire.
Walk through the findings with your security operations team and agree which detection rules or hardening changes to pursue.
Provide a remediation plan with owners and priorities that your auditors or customers can review alongside the test evidence.

How we support

Retest the agreed findings once remediation is in place, and confirm in writing which items are closed and which remain open.
Offer ongoing support and continuous testing as a retainer if your environment changes often enough to need repeat assumed breach exercises.
Ask your team to confirm the testing rules, evidence requirements and any regulatory expectations before the scope is signed off.