Ownership should reflect the scope of the environment and the skills needed to run simulations well. Some organisations assign a dedicated BAS lead with development and blue team experience, while smaller teams distribute the work across security functions. In both cases, the key is clear coordination with stakeholders so findings are actionable across IT, cloud, OT, and leadership.
Who Should Own a Breach and Attack Simulation Program?
Ownership decisions work best when they follow the program’s purpose rather than a single team’s title. breach and attack simulation is not just a tooling exercise, because it touches detection engineering, response readiness, environment coverage, and remediation follow-through. That means the right owner is usually the function that can turn simulation results into sustained control improvement, while still coordinating with infrastructure, cloud, application, and leadership stakeholders. For many organisations, that is security operations or a dedicated security engineering function; in others, it is a cross-functional service with a clearly named accountable lead.
For the underlying attack-path context, many teams map simulation findings to the techniques they are trying to validate using MITRE ATT&CK Enterprise Matrix. In practice, ownership breaks down when the program is treated as a one-off test rather than a recurring control-validation function with explicit remediation authority.
How Program Ownership Changes Across Security, Operations, and Business
The practical question is not whether security “uses” the platform, but who is responsible for the decisions the program produces. A mature breach and attack simulation program usually needs three layers of ownership:
Program owner: sets scope, cadence, priorities, reporting, and escalation rules.
Technical operators: run simulations, tune scenarios, validate telemetry, and confirm whether detections or controls behaved as expected.
Business and service owners: approve business-critical tests, interpret operational impact, and ensure fixes are applied where the risk actually sits.
Security should normally own the technical integrity of the program because the work depends on understanding attacker techniques, control coverage, and signal quality. Operations should own the parts that affect service continuity, change windows, and environment stability. Business teams should not own the simulation mechanics, but they often need to own the acceptance of risk, the priority of remediation, and the decision to test critical workflows that could interrupt production. Where the organisation has cloud, OT, or heavily outsourced services, ownership also needs explicit coordination boundaries so simulations do not stop at the edge of one team’s remit.
The clearest operating model is usually a RACI-style split with one accountable lead and several consulted stakeholders. That avoids the common failure mode where everyone is informed, no one is accountable, and findings sit in a report queue. If the team that discovers a control gap cannot also drive the remediation conversation, the program tends to produce insight without measurable hardening. That is where ownership becomes a governance issue, not a tooling issue.
Teams that already run detection or purple-team activities may place BAS inside security engineering or threat emulation because the work requires control knowledge and repeatable test design. Smaller organisations often distribute execution across security functions, but they still need a single owner for prioritisation, evidence retention, and follow-up. Where the environment is especially regulated or operationally sensitive, ownership often shifts from “who runs the test” to “who is authorised to change the environment based on the test result,” which is a more important distinction than job title alone.
When Shared Ownership Helps and When It Creates Drift
Tighter shared ownership often improves coverage, but it also increases coordination overhead, so organisations need to balance broader stakeholder input against a single line of accountability.
Shared ownership works well when the simulation program spans multiple estates, such as identity, endpoint, cloud, and business applications, because no single team sees the full control path. It also helps when the objective is to validate whether detections and response playbooks still work after platform changes. The tradeoff is that shared ownership can become ambiguous ownership if decision rights are not explicit. A steering group can help, but it should not replace an accountable owner who can set scope and close the loop on remediation.
There is also a genuine consensus gap across organisations about whether BAS belongs in security operations, security engineering, or resilience teams. The better answer depends on what the organisation is trying to optimise. If the primary goal is detection validation, security operations usually makes sense. If the primary goal is attack-path modelling and control hardening, security engineering may be a better fit. If the primary goal is business resilience and continuity under simulated attack conditions, the owner may need to sit closer to enterprise risk or operational resilience. The important point is that ownership should follow the main outcome the programme is meant to produce, not the most convenient reporting line.
Where this guidance breaks down is in organisations that want simulation results but will not delegate remediation authority, because then the program cannot translate findings into durable change.
Risk and Threat Considerations
A breach and attack simulation program creates governance risk when ownership is vague, because test results can be accepted as “security knowledge” without triggering corrective action. It also creates operational risk if simulations are run by teams that do not understand change control, service dependencies, or business-critical process timing.
Failure mechanism: The program fails when responsibility for scenario design, execution, detection validation, and remediation is split without a single accountable lead. That allows gaps to persist between simulated findings and actual control improvements, and it increases the chance of unsafe testing in production environments.
Impact: Organisations can end up with false confidence, unaddressed exposure, repeated control failures, and avoidable disruption to live services when tests are run without the right operational guardrails.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 18 — Penetration Testing | BAS operationalises attack simulation and control validation. |
| Recommendation — Use CIS 18 to structure recurring simulation tests and verify control effectiveness. | ||
| NIST CSF 2.0 | GV.RM-03 — Risk Management Strategy | Ownership should align simulation outcomes with enterprise risk decisions. |
| DE.CM-08 — Vulnerability and Exposure Monitoring | BAS checks whether exposure and detection coverage are visible and working. | |
| Recommendation — Assign program accountability so simulation findings drive risk treatment decisions. Measure whether simulated attacks expose gaps in monitoring and control coverage. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Simulation programs often validate defensive coverage against ATT&CK techniques. |
| Recommendation — Map scenarios to ATT&CK techniques and use results to tune detections and defenses. | ||
| NIST IR 8596 | IR-4 — Incident Handling | BAS findings should feed response readiness and handling improvements. |
| Recommendation — Use incident-handling ownership to convert simulation findings into response improvements. | ||
Practitioner Guidance
Decision rule: Assign ownership to the team that can both run credible simulations and compel follow-through on remediation. If the main purpose is control validation, keep accountability with security; if the main purpose is service resilience, pair security execution with operational ownership of change and recovery decisions.
What to verify: Confirm that the named owner can answer four questions without escalation: who approves scenarios, who interprets results, who accepts temporary risk, and who closes remediation. If any one of those answers is unclear, the ownership model is too diffuse to be reliable.
Practitioner takeaway: The best ownership model is the one that preserves technical credibility while giving someone real authority to turn findings into action; without that authority, BAS becomes a reporting exercise instead of a control-improvement program.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- How should organisations build an insider risk management program that works across security, HR, legal, and executive teams?
- How should security teams implement least privilege access across hybrid identity environments without breaking business operations?
- How do security teams decide whether an attack surface management program is mature enough for executive reporting?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
