Deterrence should be shared across security, legal, fraud, IAM and incident response, because the objective is to disrupt attacker economics rather than only restore systems. That means escalation paths, evidence quality and business impact need to be coordinated before an incident, not improvised after one.
Why cyber deterrence cannot sit with one team
cyber deterrence is not a single control or a standalone policy function. It works only when the enterprise can credibly raise the cost of attack through legal escalation, fraud disruption, identity controls, incident response, and evidence handling. That makes ownership a coordination problem: one team may lead the programme, but multiple functions must own the parts that make deterrence believable.
In practice, the owner has to be able to translate attacker friction into business action. If the enterprise cannot preserve evidence, validate impact, identify accounts or payments in scope, and decide when to escalate externally, the deterrence posture looks strong on paper but weak in a real incident.
Deterrence also depends on the quality of the response path. Security can spot activity, but legal may be needed to preserve privilege and notice obligations, fraud may need to freeze transactions, and IAM may need to cut off the access path. That means the programme owner should coordinate authority across those functions rather than try to absorb all decisions into one silo.
What enterprise ownership should look like in practice
The most workable model is shared ownership with a named lead, usually in security or risk, and defined decision rights across adjacent functions. Security should normally coordinate the operating model because it sees the threat, the telemetry, and the incident timeline. Legal should own external escalation guardrails, fraud should own financial-loss disruption, IAM should own identity containment, and incident response should own operational execution.
The key distinction is between programme ownership and task ownership. Programme ownership means maintaining the deterrence strategy, playbooks, thresholds, evidence requirements, and escalation matrix. Task ownership means each function commits to specific actions when the threshold is met. If those responsibilities are not explicit, deterrence becomes advice instead of action.
This is where a broader security governance baseline helps. ISO/IEC 27002:2022 Information Security Controls is useful because it reinforces that control ownership, incident handling, and evidence management need to be defined, not assumed. For response coordination, NIST Cybersecurity Framework 2.0 also fits well because deterrence depends on govern, protect, detect, respond, and recover working as a sequence rather than as isolated teams.
For enterprises dealing with identity-driven intrusion paths, the account and secret layer matters as much as the human process. OWASP Non-Human Identity Top 10 is relevant when deterrence depends on reducing misuse of machine credentials, service accounts, and long-lived access. In those environments, the deterrence owner must ensure identity teams can revoke, rotate, and contain quickly enough to change attacker economics.
Which decisions make deterrence credible to attackers
Deterrence is credible only when the enterprise can prove that misuse will be detected, contained, and escalated. That means the programme needs good evidence quality, clear thresholds for action, and a believable ability to disrupt the attacker’s next step, whether that is data theft, fraud, privilege expansion, or public leverage. Without that credibility, deterrence statements are just messaging.
Two practical signals matter most. First, can the organisation link an incident to a named actor, account, system, or transaction with enough confidence to act? Second, can it take a materially painful step fast enough to matter, such as disabling access, freezing funds, preserving logs, or referring the matter for legal or law-enforcement action? If the answer to either is no, ownership is too diffuse or the playbook is too vague.
For threat-informed defence, MITRE ATT&CK Enterprise Matrix is useful because it helps teams describe what adversaries are trying to do after initial access. When deterrence planning is tied to actual adversary behaviour, not generic response slogans, the enterprise can pick actions that change attacker cost rather than merely restore normal operations.
CISA Known Exploited Vulnerabilities Catalog is also relevant where deterrence includes reducing easy exploitation paths before they are abused. Closing the most actively exploited routes does not create deterrence by itself, but it lowers the number of cheap attack options and makes the rest of the programme more credible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Deterrence depends on preplanned incident escalation and coordination. |
| Recommendation — Define incident escalation and decision rights before an attack occurs. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Cyber deterrence is a cross-functional risk strategy with defined decision ownership. |
| Recommendation — Assign accountable ownership for deterrence as part of the enterprise risk strategy. | ||
| NIST SP 800-53 Rev 5 | IR-8 — Incident Response Plan | Deterrence relies on a response plan that coordinates security, legal, fraud and IAM actions. |
| Recommendation — Document escalation paths and coordinated response actions in the incident response plan. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Deterrence against identity abuse improves when long-lived secrets are reduced. |
| Recommendation — Reduce long-lived secrets to limit attacker persistence and reuse. | ||
| MITRE ATT&CK | TA0008 — Lateral Movement | Deterrence must interrupt post-compromise attacker movement and escalation paths. |
| Recommendation — Map disruptive controls to likely lateral-movement paths. | ||
Practitioner Guidance
Ownership model: Assign one accountable programme owner, but require standing co-ownership from security, legal, fraud, IAM, and incident response. The programme owner should manage the escalation matrix and decision thresholds; the partner teams should own the concrete actions they will take when those thresholds are met.
What to verify: Before you trust the deterrence model, verify that each function can act within the same incident timeline. If legal needs days to approve action, fraud cannot freeze in time, or IAM cannot revoke access without manual workarounds, the programme is not actually deterrent.
Practitioner takeaway: Cyber deterrence should be owned as a coordinated operating model, not as a message or a policy statement. The best test is simple: whether the enterprise can quickly raise cost for the attacker through aligned escalation, evidence, and containment decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org