Sunk Cost Fallacy

What the sunk cost fallacy means in security decision-making

The sunk cost fallacy matters in cybersecurity because teams can keep funding, maintaining, or defending a failing approach simply because they have already invested in it. That bias can slow remediation, delay exit from unsafe dependencies, and make it harder to stop losses early when a control, project, or response path is no longer effective.

In practice, this is not just a budgeting error. It can influence security architecture, incident response, vendor relationships, and fraud recovery decisions, especially when reputational pressure or prior approval makes abandonment feel like a loss rather than a correction.

How sunk cost bias shows up in fraud and social engineering

Fraudsters exploit this bias by encouraging repeated payments or repeated disclosure of value, so victims feel they must continue in order to justify what they have already lost. The more a scam appears to be “almost resolved,” the easier it becomes to keep the target engaged.

This dynamic is especially effective when the victim has already committed money, time, credentials, or trusted relationship capital. Each new commitment can feel like a way to recover the earlier one, even though it usually deepens the loss.

Why the bias is dangerous for organisations

Organisations can fall into the same pattern with weak controls, legacy systems, and vendor relationships. A team may keep extending a compromised or low-value service because replacement feels wasteful, even when the ongoing exposure is higher than the original investment.

That creates a security problem because past spend becomes a hidden constraint on present decisions. The result can be prolonged exposure, delayed retirement of unsafe technology, and repeated exceptions that gradually normalise poor risk acceptance.

How to recognise and counter the pattern

The practical test is whether a decision still makes sense if prior investment is ignored. If the answer would be different without the historical spend, the current choice is being distorted by sunk costs rather than by expected future value.

Teams can reduce the bias by separating renewal decisions from prior approvals, defining exit criteria before a project begins, and reviewing whether a failing control is being kept only because it is familiar. In fraud response, the same discipline helps: once a payment path or engagement pattern is recognised as malicious, continuing rarely improves the outcome.

Risk and Threat Considerations

In security and fraud contexts, sunk cost bias can prolong exposure after the warning signs are already clear. Attackers and scammers benefit when a target keeps investing because every additional commitment increases the psychological cost of stopping.

Failure mechanism: A victim, team, or decision-maker treats prior spend as a reason to continue, so bad projects, unsafe relationships, or scam payments persist beyond the point where rational analysis would support stopping.

Impact: Losses compound, exposure lasts longer, and organisations may delay containment, retirement, or recovery actions that would have reduced total harm.

Practitioner Guidance

Why practitioners should care: Sunk cost bias often hides inside otherwise rational processes, especially when a team has publicly committed to a tool, vendor, or response path. The most useful countermeasure is to make the next decision depend only on future risk, future cost, and future value.

Common misunderstanding: People often confuse persistence with discipline. In security, continuing a failing control, integration, or recovery plan can be the less disciplined choice if it preserves avoidable exposure.

Practitioner takeaway: When the evidence says to stop, treat stopping as a control decision, not as an admission of failure.

Related resources from NHI Mgmt Group

• What is the difference between secure identity optimisation and simple cost cutting?
• How can organisations reduce AI cost without slowing adoption?
• Why does vendor access usually cost more to secure than employee access?
• What should teams do when a low-cost remote access product lacks vendor controls?