Breach and attack simulation vs red teaming

Breach and attack simulation vs red teaming: which one to choose first

If you are a security leader who must show that controls work, start with the question you need answered. Choose breach and attack simulation (BAS) when you need repeatable evidence that known ATT&CK techniques are detected and blocked across your estate on a schedule. Choose a human red team when you need to know whether a determined attacker can reach a defined objective, such as access to a payment system or customer records, by chaining techniques you did not anticipate. Automated emulation answers the first question well and the second poorly; a scoped red team does the reverse. BAS fits when your controls change often and you want to confirm that detections still fire after each change. Its useful outputs are per-technique results that map to MITRE ATT&CK, which you can compare run over run. MITRE Caldera, an Apache-2.0 licensed platform built on ATT&CK, is one open-source option for automating adversary emulation, but you still need people to design the plans, interpret gaps and decide what to fix. A human red team fits when you need creative, objective-driven attack paths, social engineering, or a test of whether anyone notices at all. Confirm with any provider whether the engagement includes covert operations and how it will be scoped in writing. The two are usually combined rather than chosen once. NIST SP 800-115 describes a layered approach: regularly scheduled scanning, interspersed with periodic penetration testing, and it notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. Treat BAS as the frequent layer that protects your detection coverage between exercises, and the red team as the periodic test that checks the chains that automation cannot reproduce. Neither replaces the other, and the budget decision is about how often each runs, which you should set against your change rate and the findings from your last exercise.

How the two approaches differ across scope, method and output

This table compares breach and attack simulation (BAS) with a human red team across goal, scope, method, operator, tempo, social engineering, validation and reporting. Read the rows marked as dependent on engagement terms as the points to settle in writing, because a red team contract can narrow or widen them.

Factor	Breach and attack simulation	Human-led red team
Primary goal	Confirm that specific ATT&CK techniques are prevented or detected by current controls	Test whether an adversary can reach a defined objective and whether defenders notice
Scope	Named techniques, assets and control points agreed in advance; typically narrower and repeatable	Objective-based, with the path chosen by testers; boundaries set in the rules of engagement and may change if agreed in writing
Method	Scripted or agent-driven emulation of known techniques, run in sequence or on a schedule	Chained techniques chosen creatively, adapted to what testers find, including custom tooling where agreed
Operator	Security or platform team configures and runs the tool; vendor or open-source maintainers supply the techniques	Experienced testers under a written authorization, often with a control group or white cell for oversight
Tempo	Can run continuously or at scheduled intervals against production-like controls; cadence depends on your change process	Episodic campaigns with fixed windows; duration depends on the engagement terms and objectives
Social engineering	Usually out of scope; some tools simulate email or endpoint lures, which is not the same as a human pretext	Included only when the rules of engagement and legal review allow it, such as email, phone or physical attempts
What is validated	Whether specific detections, blocks and alerts fire for the techniques tested	Whether the combined people, process and technology chain stops or detects an objective-driven attack
Reporting	Technique-by-technique results, often mapped to ATT&CK, showing pass, partial or missed detections	Narrative attack path, evidence of objectives reached, detection timeline and recommended fixes
Typical use	Frequent regression checks after control changes, and building a detection baseline between human tests	Board or regulator-facing assurance, or testing against a specific threat actor profile
Who decides the result	Pass or fail is defined by the detection criteria you set before the run	Interpretation depends on the objectives and rules agreed; confirm how success and failure are defined in your contract

What breach and attack simulation validates that red teaming does not

Breach and attack simulation (BAS) checks whether specific security controls still detect and stop specific adversary techniques, and it can do this again after every change. A BAS platform runs discrete ATT&CK techniques against endpoints, network segments and email paths, then records whether the EDR, SIEM rule, firewall or mail gateway alerted or blocked. CISA, NSA, FBI and partner agencies make this the core of their guidance in joint advisory AA22-257A (14 September 2022). It recommends selecting a technique, testing the relevant controls against it, and tuning people, processes and technologies based on the result, then repeating that testing at scale in a production environment. A red team cannot produce that loop on a weekly or per-change basis, because each engagement is bounded in time and cost.

The validation BAS provides is narrow by design. Each simulated technique is usually run in isolation, so the output tells you whether a detection fired for that step, not whether an intruder moving through your estate would have been stopped at the objective. BAS does not chain creative paths across identity, cloud and business processes, does not find the misconfiguration nobody modeled, and does not test whether a help desk analyst or employee would be persuaded by a pretext. Those are the questions a human red team answers. Before you buy a BAS tool, ask the vendor which ATT&CK techniques it covers, how it verifies that a telemetry source received the event, and whether it can run safely in production under your change process.

For open-source options, MITRE Caldera is built on ATT&CK to automate adversary emulation and can assist manual red teams, and it is licensed under Apache-2.0. Caldera gives you control over the emulation plans and the agents, but your team carries the work of writing abilities, scoping safe execution and reviewing results, which is effort that a commercial BAS product often packages. Confirm with the project and your own environment which plugins, agents and reporting features you need before you commit to it as the basis for recurring validation.

What each approach finds and misses

Breach and attack simulation (BAS) and human red teaming answer different questions about the same controls. The cards below set out where each approach gives reliable evidence and where it leaves gaps, so you can decide which blind spots matter most for your environment.

Detection gaps

BAS runs known ATT&CK techniques on a schedule and reports whether each one was logged, alerted on or blocked, which makes it well suited to checking that detection content still fires. A red team finds detection gaps too, but only for the techniques its operators happen to use. Ask whether the BAS library covers the techniques your SIEM rules claim to detect, and whether results are tied to specific detection logic. CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used.

Configuration drift

Repeated automated runs are the strongest tool here, because a control that passed last quarter can quietly stop working after a policy change, agent update or console migration. CISA's joint advisory AA22-257A recommends continual testing at scale in a production environment for this reason. A one-time red team engagement captures drift only if it happens to occur during the test window. Confirm how often the BAS platform reruns each technique and who is alerted when a previously blocked action succeeds.

Chained attack paths

A red team that moves from a phished user to a service account and then to a domain administrator tests how individual weaknesses combine, which a technique-by-technique BAS run does not do by default. BAS tools can chain steps only if the operator builds the chain, so their results usually show single controls rather than paths. Ask the provider whether the platform supports multi-step operations and whether results map each step to the control that should have stopped it.

Social engineering exposure

Human red teams can run pretexting by phone, email and in person, and NIST SP 800-53 control CA-8(2) recognizes these methods as part of red team exercises. BAS platforms emulate technical behavior and generally do not test whether a person will hand over credentials. If your risk includes help desk impersonation or executive targeting, plan a scoped social engineering exercise and confirm that the red team has written authorization covering each method.

Decision-making under pressure

A human red team can test whether analysts escalate, contain and communicate well when an attacker changes course, which a scripted BAS run cannot reproduce. Neither approach measures the full incident response process alone. For that, pair an exercise with a tabletop or functional exercise, and use the red team's timeline to judge whether the response matched the plan. Ask the red team to record defender actions and timing so the debrief has evidence rather than recollection.

Blind spots in coverage

Each approach has coverage that the other will not provide. BAS only tests techniques in its library, so novel or environment-specific attacks fall outside its results. A red team samples a small number of paths within a limited window, so a clean result does not prove the absence of weaknesses. Document the scope of each test, list the techniques or systems not covered, and treat those as open risk until another method, such as scheduled penetration testing or vulnerability scanning, addresses them.

How each approach runs in practice

A breach and attack simulation (BAS) platform runs predefined or configured emulations of ATT&CK techniques against agents or test hosts placed in your environment, then reports which steps were blocked, detected or missed. The platform does the repetitive execution, so the work shifts to deployment, scoping and interpreting results. Security engineering or the detection team usually owns the platform, with the platform or infrastructure team handling agents and network access. Scenario selection is driven by the techniques that matter most to your threat model, mapped to ATT&CK, and by the controls you want to re-test after each change.

Setup and ownership: Someone must deploy agents, define safe execution boundaries and agree on which systems may be targeted, usually with change control in place.
Scenario choice: Teams pick techniques from a catalog or build chains that reflect known adversary behavior, then rerun them on a schedule.
Caldera as an option: MITRE Caldera, licensed under Apache-2.0, is built on ATT&CK to automate adversary emulation and can also assist manual red teams. Your team must still write or select adversary profiles, host the server and maintain the agents.
What still needs supplying: Analysts to triage results, tuning effort for detections and a process for turning gaps into fixes.
Limits: Automated runs test known techniques in a repeatable way and do not show whether a skilled attacker would find a novel path.

Confirm with the vendor or project which techniques, cloud platforms and endpoint types a platform covers in your environment, and which safety controls it provides.

How often to run each one

This sequence sets a cadence that starts with routine scanning and periodic penetration testing, adds breach and attack simulation runs tied to control changes, and reserves red team exercises for defined objectives. The result is a calendar that shows which control each activity validates and who agreed to run it.

Establish the baseline with scheduled scanning
Start by setting a recurring schedule for network and vulnerability scanning. NIST SP 800-115 suggests regularly scheduled scanning as the foundation, interspersed with periodic penetration testing. Your security operations or vulnerability management team owns this schedule and records each scan cycle in the same calendar used for change management. You know this step is done when every in-scope asset has a named scan cadence and the results feed a tracked remediation queue.
Schedule annual penetration tests
Next, book external and internal penetration tests on a fixed annual cycle. CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, so the test dates should be written into the security program plan. Your security lead sets the scope and the provider confirms the rules of engagement, using the NIST SP 800-115 template as a starting point. The step closes when signed scope documents exist and each test has a named owner for remediation.
Map each control to its validation method
Before adding automated runs, list the controls that matter most and the ATT&CK techniques each one should detect or block. CISA, NSA, FBI and partner agencies recommend testing controls against ATT&CK techniques in advisory AA22-257A. Your detection engineering lead and the BAS provider build this mapping together. The output is a control-to-technique register that shows which controls have been validated, when, and by which method.
Trigger BAS runs after control changes
Add repeatable breach and attack simulation runs that follow control changes, such as new EDR policies, SIEM rule updates, firewall changes or identity configuration updates. The change calendar drives these runs, so each change ticket includes a validation task. Your operations team and the BAS provider agree which changes trigger a run. The step is complete when each material change has a linked BAS run and a recorded result against the control register.
Re-test after remediation
When a BAS run or penetration test shows a gap, schedule a targeted re-run once the fix is in place. CIS Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques the testers used. Your detection team makes the fix and the provider repeats the specific techniques. You know the step is done when the original finding is closed with evidence that the technique is now detected or blocked.
Define objectives before each red team exercise
Red team exercises run less often than BAS and are scheduled against defined objectives, such as reaching a specific system or testing a particular detection and response process. The CISO or security leadership sets the objectives and the rules of engagement, and the red team provider confirms feasibility and legal authorization. The exercise is ready when objectives, escalation contacts and stop conditions are documented in writing and approved.
Agree the BAS frequency with your provider
The frequency of BAS runs is a design decision, not a fixed rule. Agree it with your provider based on the number of controls in scope, how often your environment changes, and the staff available to act on results. Your procurement lead and the provider document the agreed cadence in the statement of work and review it against your own change calendar each year. Confirm the cadence, run volume and any production safety limits in writing before the first run.

What you receive from each approach

This table compares the typical outputs of a breach and attack simulation run with those of a human red team engagement. Read it to decide which evidence your board, auditors and detection engineers will actually need, and to write the deliverable format into scope before work starts.

Deliverable	BAS platform run	Red team engagement
Run logs and execution records	Timestamped logs of each emulated ATT&CK technique, its outcome and the agent or host it ran on	Operator logs and command history, usually summarized in the report rather than delivered raw
Technique coverage mapped to ATT&CK	Coverage matrix by technique and sub-technique, produced directly from the run	Techniques observed during the engagement, mapped after the fact, often fewer and more chained
Detection gap list	Techniques that ran without an alert or block, listed for tuning and retest	Points where defenders did or did not notice activity, described in narrative form with timestamps
Attack path diagrams	Usually not produced, since steps are independent technique runs	Diagrams of the chained route from initial access to the objective
Objective narrative	Generally absent; the report describes control results rather than a story of the attack	Core output: what the team attempted, what it achieved and what it would mean for the business
Retest evidence	Repeat runs of the same techniques after changes, which is the main reason BAS is run repeatedly	Targeted retest of confirmed findings, scoped separately and usually a smaller effort
Debrief workshop	Optional, often a walkthrough of dashboards with the security operations team	Standard part of the close-out, with attacker and defender sides reviewing the timeline together
Remediation tracking	Tracked as tuning actions against failed techniques, often inside the platform	Findings register with owners and due dates, which the client or provider must maintain

What drives cost and effort for each approach

Breach and attack simulation and red teaming are paid for in different places. One is mostly a platform and tuning investment that recurs, the other is mostly scoped tester time that is bought per exercise. The cards below name the components that move the total, which parts are one-time and which recur, and what to ask for in a written quote.

Platform fees and licensing

A BAS product is usually bought as a platform, so the license or subscription is a recurring cost tied to the product's terms, and open-source options such as MITRE Caldera (Apache-2.0) carry no license fee but still need hosting and staff. Ask whether the price scales with agents, endpoints, simulated techniques or environments, and whether content updates for new ATT&CK releases are included. Confirm the license terms and what the subscription covers before comparing totals.

Techniques and environments in scope

Cost rises with the number of ATT&CK techniques emulated and the number of environments tested, such as production segments, cloud accounts, branch sites and endpoint builds. CISA's joint advisory AA22-257A recommends continual testing at scale in a production environment, which means the recurring run volume is the cost driver to plan for. Ask the vendor or DeployOpen how techniques are selected, how many environments are covered, and how often each runs.

Tester hours and red team scope

A red team is paid mainly for skilled tester time over a defined engagement, so cost follows the objectives, the depth of the attack chain and how much adaptive work the testers do. A threat-led test under TIBER-EU carries a minimum active testing period and mandatory purple teaming, which raises effort beyond a voluntary exercise. Request the team composition, expected hours by phase and the criteria for ending the test early.

Rules of engagement and legal authorization

Both approaches need written rules of engagement that set permitted techniques, testing windows, stop conditions and points of contact. NIST SP 800-115 provides a rules of engagement template in Appendix B, and a human red team also needs signed authorization that covers the people and systems it will touch. Legal review time is one-time per engagement but can be large when cloud providers, third-party hosts or shared services are involved. Ask who drafts and signs the rules and who pays for the legal review.

Social engineering scope

Adding phishing, phone pretexts or physical access attempts increases cost because it needs its own approvals, pretext design, and handling of staff data and HR concerns. NIST SP 800-53 control CA-8 guidance lists email, telephone, shoulder surfing and personal conversation as possible channels, and each channel adds planning and oversight. BAS tools rarely cover this path, so it is usually a separate line item in a red team quote. Ask which channels are included and how staff reactions are recorded without exposing individuals.

Reporting depth and internal tuning time

Reporting depth changes the total because a BAS run produces detection and prevention results that need triage, while a red team report needs narrative attack paths, evidence and remediation advice. The largest recurring internal cost is often staff time to tune detections and controls after each run, which NIST and CIS both link to validating detections against the techniques that were tested. Ask what the report contains, how many review sessions are included, and whether retesting after fixes is priced in.

When compliance frameworks call for each approach

Compliance frameworks rarely name breach and attack simulation (BAS) directly, so the first decision is whether your obligation asks for a human-led test, a scenario-based exercise, or a control validation process that you run continuously. BAS alone is not named by the facts that govern these frameworks, and you should confirm with your assessor or regulator whether automated emulation counts toward a required test. Do not assume a tool report satisfies a requirement that is written in terms of a test.

NIST SP 800-53 Rev. 5 control CA-8 Penetration Testing has enhancements for an independent penetration testing team and for red team exercises, and CA-8 and CA-8(1) are selected only in the high baseline (SP 800-53B Release 5.2.0). If you are assessed against a moderate or low baseline, ask your assessor which controls apply to you and whether they expect an independent team at all. DORA Article 25(1) lists scenario-based tests and penetration testing among the resilience tests a financial entity must run, and Article 26 requires threat-led penetration testing at least every three years for entities their competent authority identifies. Automated emulation may support the Article 25 tests, but it does not by itself meet the threat-led requirement.

TIBER-EU, dated January 2025, sets a different bar: at least 12 weeks of active testing and mandatory purple teaming, with the ECB stating that these tests produce no pass or fail result. A continuous BAS program cannot replace that active, human-led test, but it can supply the repeatable technique coverage that your purple team builds on. Before you commit budget, ask your regulator or assessor three questions: which control or article the evidence must satisfy, whether they accept automated emulation as evidence, and who must perform the work.

Questions buyers ask before hiring outside help

Can breach and attack simulation replace a red team?

No, not as a full substitute. Breach and attack simulation repeats known ATT&CK techniques against your controls on a schedule, which shows whether those specific detections and blocks still work. A human red team chains techniques in ways a fixed library does not anticipate, picks its own path to an objective, and can include social engineering. NIST SP 800-53 control CA-8(2) describes red team social engineering as interactions by email, telephone, shoulder surfing or personal conversation. TIBER-EU goes further for the regulated firms it covers: its tests require at least 12 weeks of active testing and mandatory purple teaming. If your question is whether defenders would notice a determined adversary, you need the human exercise. If your question is whether known techniques are still caught after each configuration change, simulation is the better tool for that job.

What does a breach and attack simulation program need from our team?

It needs named owners, not only a tool. Someone must choose which ATT&CK techniques to run, approve where they execute, and read the results. The joint advisory AA22-257A from CISA, NSA, FBI and partner agencies recommends six steps, from selecting a technique through tuning people, processes and technologies, and testing continually at scale in a production environment. In practice, your team must:

Map each technique to the control expected to catch it and to the log source that proves the outcome.
Agree safe execution rules, change windows and a way to stop a run immediately.
Confirm that SIEM and endpoint telemetry feeding the tests is complete and retained.
Assign someone to tune detections and close gaps after every run.

If nobody owns tuning, results accumulate as reports and no control improves.

How long does each approach take to run?

Duration depends on scope, environment size and approvals, so no general figure applies to either approach. Simulation effort sits mostly in setup and tuning, then recurs as scheduled runs. A red team engagement is a project with preparation, active testing and reporting phases. The only minimum duration supplied for a threat-led exercise is in TIBER-EU, where the January 2025 framework sets at least 12 weeks of active testing for its regulated tests, which is a floor for those programs and not a typical commercial length. DORA Article 26 requires threat-led penetration testing at least every 3 years for entities their competent authority identifies. Ask any provider for the full schedule in writing, covering preparation, active testing, reporting and any retest window, and confirm which milestones depend on your own approvals.

Can an internal team run MITRE Caldera without outside help?

Yes, an internal team can run it, but it needs ATT&CK fluency and a controlled lab before any production use. MITRE Caldera on GitHub is built on ATT&CK to automate adversary emulation, assist manual red teams and automate incident response, and it is licensed under Apache-2.0, so the software carries no license fee. Your costs are staff time, infrastructure and the work to build and review operations. Before any run, confirm the version you deploy, which plugins you enable, and how agents are isolated from production systems. Read what each ability does, plan cleanup, and decide who approves each operation. Caldera shows what executed. It does not tell you whether your controls should have caught it, so an analyst must still compare results with detection logic and logs.

What drives the cost of red teaming and simulation?

Most of the cost is people's time, and the components differ by approach. Tooling can be free to license for open-source options, but staff time is not. Simulation costs usually include setup, scenario selection, execution, analysis, detection tuning and reporting. A red team adds scoping, rules of engagement, legal authorization for any social engineering or physical attempts, and testers' time to chain techniques toward an objective. One-time costs include the initial build and baseline. Recurring costs include scheduled runs, tuning and retests. Costs rise with the number of environments, the controls in scope, test frequency and the depth of the adversary objective. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, so the mix you choose sets the total. Ask any quote to itemize setup, each run type, reporting, retests and who performs each task.

How do we combine both approaches within one budget?

Split the budget by question: frequent automated checks for control drift, and periodic human-led tests for adversary depth. NIST SP 800-115 suggests regularly scheduled scanning interspersed with periodic penetration testing, and it describes combining techniques as common practice. CIS Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques testers used. That links the two approaches: red team findings should feed the simulation library, and simulation results should show whether fixes held. Illustrative example: a financial firm might run simulations on a steady schedule between red team exercises, then commission a human-led engagement after a major architecture change. Set the frequencies from your own risk assessment. Ask providers to price simulation and red team work separately, so you can see what each buys and whether one written scope can cover both.

What will a regulator or auditor expect to see from testing?

Expect evidence of method, scope, findings and follow-up, not a pass or fail certificate. The ECB states that TIBER-EU tests produce no pass or fail result, and the framework requires purple teaming. CIS Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, and Safeguard 18.4 asks that controls be validated after each test. NIST SP 800-53 control CA-8 covers penetration testing and offers enhancements for independent teams and red team exercises, and SP 800-53B selects it only in the high baseline. PCI SSC guidance says simply running an automated tool does not satisfy its penetration testing requirement, so simulation alone may not meet that expectation. Ask your regulator or auditor which evidence they accept. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the reports and attestations.

Does DeployOpen run breach simulation or red team engagements?

DeployOpen plans, implements, runs and documents security testing inside your own infrastructure, including penetration testing, red teaming, and AI and agent security testing. It can also set up private cyber ranges and training that help teams practice detection and response. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins, so the choice between simulation and a red team belongs in the scoping conversation. Ongoing or continuous testing can be arranged as a retainer. Two limits matter. DeployOpen does not publish a price list, so a quote follows from the written scope, and it does not issue audit reports, attestations or certifications. Ask for the proposed mix of simulation and human-led work, who on your team will own tuning, and how results will map to your controls.

What it costs to switch or add the other approach later

The cheapest time to plan for the other approach is at the start, because ATT&CK technique mappings are the portable layer between breach and attack simulation (BAS) and a human red team. A BAS scenario that is tagged with ATT&CK technique IDs can be reused as a starting point for a red team scope, and a red team report that maps each observed step to a technique ID can seed new BAS scenarios. That only works if the report is written for reuse. Ask your red team provider to record the technique ID, the tool or manual method, the affected asset, the detection result and the timestamp for every step, not only a narrative of the attack path. Without those fields, the findings stay in prose and someone has to rebuild them by hand.

Lock-in risk sits mostly in proprietary BAS platforms, where scenarios, agent configurations, and result histories are stored in the vendor's data model and may be exportable only in part. Before you buy, confirm in writing what can be exported, in what format, and whether the export includes the scenario logic and the execution records, not just a summary. MITRE Caldera is open source under Apache-2.0, so its operations, abilities and adversary profiles can be stored, versioned and reviewed in your own repository. That gives you more control over migration, though it moves the cost to the team that maintains the deployment and writes the abilities. Confirm the Caldera version you run and check its documentation before you rely on any specific plugin.

Rules of engagement and evidence formats need the same discipline. A written rules of engagement document should name the systems in scope, the permitted techniques, the time windows, the stop conditions and the people who can halt the exercise, and it should not depend on a particular tool's configuration screen. Keep the evidence format under your control as well: store raw execution logs, detection outputs and sign-off records in open, documented formats so that a change of provider or platform does not erase your history. NIST SP 800-115 includes a rules of engagement template in Appendix B that you can adapt for either approach. Agree with your provider which artifacts you own at closure, and write that into the statement of work.

How DeployOpen scopes and delivers control validation and red team work

DeployOpen plans, runs and documents control validation and red team work inside your own infrastructure, whether the goal is repeatable ATT&CK technique testing or a covert objective-driven exercise. Each engagement starts from a written scope that sets what is tested, what is off limits and how results reach your team.

How we scope

Engagements are fixed-scope, with objectives, target systems, techniques and rules of engagement agreed in writing before work starts.
For simulation work, the scope names the ATT&CK techniques to emulate and the security controls expected to detect or block them.
For red team work, the scope defines the objective, permitted social engineering methods, escalation contacts and the stop conditions.

How we build

Emulation plans are prepared against your environment, with any automation such as MITRE Caldera configured on your own systems.
Test activity is run in the environments and time windows agreed in the scope, with logging kept so each step can be traced to a detection.
Findings are mapped to the techniques tested so that detection gaps and control weaknesses can be read against the attack path.

How we hand over

Deliverables include a written report of tested techniques, observed outcomes, detection results and prioritized remediation actions.
Each finding is documented with the evidence needed for your team to reproduce it and to confirm the fix.
Results are prepared as control and evidence material for your own assessors. DeployOpen does not issue audit reports or certifications.

How we support

Ongoing support, periodic re-testing and continuous testing are available as retainers, with terms agreed in writing.
Retesting after remediation can confirm that controls now detect the techniques that previously went unnoticed.
Ask your DeployOpen contact to confirm the retainer scope, cadence and handover format before signing.

Breach and attack simulation vs red teaming