Operating model risk

The risk that a security service structure no longer matches the organisation’s control, staffing, and decision-making needs. In MDR, this shows up when AI changes provider economics faster than the buyer changes governance, contracts, and internal oversight.

Expanded Definition

operating model risk is a governance and delivery risk, not a tool risk. It appears when the way a security function is organised no longer fits the way threats, workloads, and decision rights actually move through the business. In managed detection and response, cloud security, and identity operations, that mismatch can be caused by outsourcing, automation, AI-assisted triage, or rapid service expansion that outpaces oversight. NHI Management Group treats the term as a practical signal that structure, process, and accountability have drifted apart.

This risk is often confused with generic control weakness, but the distinction matters. A control may be technically sound while the operating model still fails because approvals are too slow, ownership is unclear, escalation paths are fragmented, or staff cannot validate what a service is doing. The NIST Cybersecurity Framework 2.0 is useful here because it frames cybersecurity as an organisational capability, not just a product stack. Definitions vary across vendors, especially in MDR and AI operations, where some use the phrase to mean commercial delivery risk and others use it to mean governance drift. The most common misapplication is treating operating model risk as a procurement issue, which occurs when leaders assume contract renewal alone will fix misaligned control ownership and escalation design.

Examples and Use Cases

Implementing a resilient operating model often introduces coordination overhead, requiring organisations to weigh faster automation against tighter governance and clearer human oversight.

• A security team adopts AI-assisted alert triage, but incident commanders still expect manual review for every high-severity case, creating slow handoffs and duplicated effort.
• An MDR provider shifts to more autonomous detections, while the customer contract still requires human approval for containment actions, leaving authority unclear during active response.
• An identity program adds more machine identities and service accounts, but the approval workflow remains built for employee joiner-mover-leaver processes, so ownership checks are missed.
• A cloud security operation centralises policy decisions, yet local engineering teams retain separate exception paths, which makes enforcement inconsistent across environments.
• An organisation begins using an OWASP Top 10 for Large Language Model Applications-informed agentic workflow, but no one defines who can pause, override, or audit the agent’s tool use.

In practice, operating model risk often becomes visible when a service performs well in steady state but struggles during exceptions, escalations, or major incidents. The issue is not only speed; it is whether the people, approvals, and evidence trails are designed for the actual service shape. That is why frameworks such as NIST Zero Trust Architecture and NIST-aligned identity assurance thinking can be relevant when access, delegation, and automation cross organisational boundaries.

Why It Matters for Security Teams

Security teams need to understand operating model risk because many failures are created by friction between authority and execution, not by missing controls alone. When ownership is vague, teams over-escalate routine decisions, under-escalate urgent ones, or rely on informal workarounds that are hard to audit. That becomes especially important in AI-enabled security services, where autonomous workflows, shared tools, and delegated actions can outpace policy updates and change control.

For identity-heavy environments, the same pattern appears when human and non-human identities are managed under different assumptions. If service accounts, API keys, and agent credentials are governed as if they were ordinary employee identities, oversight gaps grow quickly. NHI Management Group sees this as a sign that identity governance, service delivery, and incident authority must be designed together, not separately. The NIST Cybersecurity Framework 2.0 reinforces that point by tying security outcomes to organisational governance and continuous improvement. Organisations typically encounter operating model risk only after a major incident, a vendor transition, or an AI rollout exposes who can act, who can approve, and who is accountable becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does a legacy ERP controls model become a governance risk?
• Why does Model Context Protocol create identity risk for enterprises?
• When does a no-call-home model create more risk than it removes?
• Why do AI pipelines and model registries create governance risk?