Who should own the minimum viable business decision in a crisis?

Why This Matters for Security Teams

The minimum viable business decision in a crisis is not a technical choice alone. It is the point where continuity, risk tolerance, and recovery sequencing meet. Business leadership owns the question of what must return first because that answer reflects revenue protection, legal exposure, patient or customer impact, and operational dependency. IT can design the recovery path, but it cannot credibly decide business priority in isolation. Security then determines whether the restored environment is safe enough to re-enter service, particularly when credentials, access paths, or trust boundaries may have changed. This division of responsibility aligns with the governance expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats contingency, access control, and incident response as managed controls rather than ad hoc judgments.

Teams often get this wrong by assuming the “most technical” system should recover first, when the real decision is which capability creates the fastest safe return to operations. In practice, many security teams encounter the ownership gap only after a major outage has already forced them to restore the wrong things first.

How It Works in Practice

A workable model starts before an incident. Business leadership defines the critical service or capability, the acceptable outage window, and the point at which a degraded service is still useful. IT translates that into recovery time objectives, recovery point objectives, dependency maps, and restoration order. Security validates whether restoration introduces unacceptable exposure, such as unpatched hosts, stale credentials, broken segmentation, or suspicious persistence. This is where the decision becomes operational rather than theoretical.

In mature environments, the minimum viable business decision is documented as a short, named decision path. That path answers three questions: what capability returns first, what conditions must be true before it returns, and who can overrule a default restore sequence. The point is not speed alone. It is speed with control. Guidance from CISA's Known Exploited Vulnerabilities Catalog is useful here because recovery often intersects with actively exploited weaknesses that should block immediate reintroduction to production.

• Business owns prioritisation of customer, revenue, legal, and safety impact.
• IT owns the recovery architecture, dependencies, and sequencing.
• Security owns the risk decision on whether the restored state is trustworthy.
• Incident commanders coordinate the decision, but should not replace accountability.

Where identity is involved, the same pattern applies to privileged access, service accounts, and emergency access. Restoring the application without restoring trust in credentials or administrative paths often recreates the incident in a new form. Alignment with CISA Zero Trust guidance helps teams preserve access validation even during emergency recovery. These controls tend to break down when ownership sits inside a single technical team and recovery is driven by ticket queues rather than pre-agreed business impact criteria.

Common Variations and Edge Cases

Tighter recovery governance often increases coordination overhead, requiring organisations to balance rapid restoration against the risk of bringing back a compromised or irrelevant service. That tradeoff is especially sharp in regulated environments, where uptime pressure can conflict with evidentiary preservation or supervisory obligations.

Current guidance suggests that the ownership model should shift slightly by environment, but not by principle. In a regulated financial services crisis, business leadership may be more constrained by legal and operational thresholds, while security may have a stronger veto on restored access until validation is complete. In healthcare, clinical safety can override pure uptime considerations. In cloud-native and identity-heavy estates, the minimum viable decision may hinge on which tenant, trust boundary, or privileged control plane must return first, not which application is most visible.

There is no universal standard for this yet, but the recurring pattern is clear: when the business decision is not explicit, recovery becomes a technical debate after the fact. That delay creates two common failure modes, restoring low-value systems first and re-enabling unsafe access paths too early. The most reliable operating model is to define the decision owner, the backup approver, and the safe-to-restore criteria before a crisis begins, then rehearse it alongside incident response and continuity playbooks. In identity-centric recovery, this includes emergency access, service account custody, and privileged session validation so that restored services do not inherit the same compromise.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Who should own access governance when business applications affect audit and licensing?
• Who should own the decision when identity governance is central to GRC?
• How should security teams structure crisis decision rights before an incident happens?