i

Description

Un disque dur ouvert, plateau et bras de lecture visibles, posé sur une table de bois.

Source

ViveaLiyevi · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Normalcy bias

Because nothing serious has ever happened, we conclude that nothing serious will happen, and we do not prepare.

In brief

• What: a severe event we have never experienced is treated as impossible, or negligible, and we do not prepare for it.
• Why: past experience is treated as a guarantee; imagining it is costly, preparing for it costs even more.
• Detect: “it has never happened,” a recovery plan never exercised, a backup never restored.
• Avoid: run the exercise for real, restore regularly, imagine failure before it happens, keep backups separate from production.

On this page

1. Definition
2. The mechanism
3. Where it appears
   1. In project management
   2. In management
4. Famous cases
   1. GitLab.com: five backup mechanisms, none reliable January 31 - February 1, 2017
   2. The OVHcloud fire in Strasbourg March 10, 2021
5. Detection signals
6. Avoidance reflexes
7. With AI: detect, fix, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to integrate into your workflows
   5. How to integrate them
   6. Precautions
8. Limits
9. Sources and verification
10. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Normalcy bias (normalcy bias) is the tendency to underestimate the probability and effects of a disaster, and to keep acting as if the usual situation will continue. It is mostly described in studies of disaster response: when an alert occurs, some people do not move, interpret signs as harmless, or wait for confirmation. In 1994, psychologists Haim Omer and Nahman Alon framed it as a “principle of continuity”: when facing an event, people first try to preserve continuity with the known world, rather than accept a rupture.

In IT and management, the feared event is a fire, a total outage, an attack that encrypts everything, the loss of a vendor, the sudden departure of the only person who understands a system. The bias is not about ignoring risks (most teams have a list), but about not treating them as possible: no testing, no budget, no procedure.

The mechanism#

• The absence of events is treated as proof. Ten years without a major incident says almost nothing about the probability of a rare incident, but creates the feeling of zero risk. It is a form of faulty induction, close to Availability heuristic: what we do not remember does not exist.
• Imagination has a cost. Picturing a site completely destroyed is unpleasant. It is more comfortable to file the idea under “theoretical” scenarios.
• Preparation has no visible return. A tested restore produces nothing as long as nothing happens; it competes with tasks that visibly move forward. The cost is certain, the benefit hypothetical.
• The need for continuity. Faced with an ambiguous warning signal, people first look for the most ordinary explanation (“a false alarm,” “a temporary incident”), which delays response.
• Dilution of responsibility. The recovery plan belongs “to operations,” backup “to the hosting provider,” security “to the dedicated team”: no one checks the whole picture (see The bystander effect).

Where it appears#

In project management#

• Backups never restored. The scheduled task runs every night and reports “success”; no one has ever tried to bring a system back online from it.
• Backups in the same location. Copies, snapshots, and replicas are stored in the same data center, the same rack, the same account as production: they protect against a disk failure, not against fire, hacking, or account deletion.
• The recovery plan “on paper.” A document approved three years ago, never exercised, with contacts and passwords now changed.
• The single vendor, the single person. A component, provider, or expert whose failure would stop everything, with no plan B.
• Alerts classified as noise. A rare or unusual signal is filed with false alarms, because “it is always like this.”
• The production environment treated like testing. Destructive commands run without safeguards, because “it has always gone fine.”

In management#

• Continuity budget sacrificed. In cost-cutting periods, what produces no immediate output (exercises, redundancy, documentation) is cut first.
• Unexpected departure. The team works thanks to one key person; no knowledge transfer is organized, because they have “always been here.”
• Weak signals ignored. A team saying “we are at the limit” is not believed until an incident confirms it.
• Improvised crisis management. No one decided in advance who decides, who communicates, who calls the customer: the first hours are lost.

Famous cases#

Detection signals#

• “That has never happened” or “that cannot happen here” in a risk discussion.
• The recovery plan has not been exercised in the last twelve months, or ever under real conditions.
• No one can state the date of the last successful restore or how long it took.
• Backups are with the same provider, at the same site, or under the same credentials as production.
• “Extreme” risks are classified as “unlikely” without estimation and without measuring their impact if they occur.
• Alerts are routine: people have stopped reading them.

Avoidance reflexes#

1. Actually restore. At fixed intervals, rebuild an environment using only backups, measure the time, and note what is missing. That's the only proof a backup is useful.
2. Separate copies from production. A different site, a different account, a different provider, or at least a different failure domain. An immutable or offline copy also protects against an attack.
3. Run a pre-mortem. “Let's imagine that next year everything has been down for three days: what happened?” The exercise brings out scenarios we refuse to think about.
4. Quantify in impact, not probability. For a rare event, the question is “how much time, how much data, how much money?” If the answer is “the company stops,” the risk is addressed even if it is unlikely.
5. Practice the plan, including the human side. Who decides, who alerts customers, who has access? A crisis drill announced in advance, then a surprise drill.
6. Monitor the absence of signal. A backup that produces nothing, an alert that never triggers: treat silence as an anomaly to verify.
7. Make the result visible. A “last validated restore” date displayed on the operations dashboard, with a named owner.

With AI: detect, fix, mitigate#

Prompts to integrate into your workflows#

1. Pre-mortem of a major incident. To use in a risk committee or when preparing a recovery plan.

Here is a system architecture (anonymized description): [components, hosting, backups, access, dependencies].
Imagine that in twelve months this system has been completely unavailable for three days and data has been lost.
Propose six plausible and very different causes (physical, human, malicious, provider, organizational, technical).
For each one: what was missing to prevent it, what would have allowed faster recovery, and the concrete check to perform right now.
Do not reassure: point out what is not described in my text.

2. Critical review of a recovery plan. To use on an existing continuity or recovery plan.

Review this recovery plan like a skeptical auditor.
1. List, for each step, what has probably never been tested.
2. Identify backup copies that share a common point with the original (site, account, provider, credentials).
3. Indicate forgotten dependencies (access, keys, contacts, licenses).
4. Propose a two-hour restore drill, with what must be measured.
5. Say in one sentence what seems most fragile to you.

Plan: [plan text, without passwords or confidential data]

How to integrate them#

• Before the annual drill: prompt 1 prepares more varied scenarios than those the team chooses spontaneously.
• During the plan review: prompt 2 produces the list of checks to perform, which is turned into scheduled tasks.
• After the drill: compare what AI predicted with what the drill revealed, to improve future scenarios.

Precautions#

• AI proves nothing: only a real restore validates a backup.
• Never paste credentials, addressing plans, or security diagrams into an unauthorized tool.
• Verify the commands and technical references it proposes before using them on a real system.
• A “complete” plan written by AI has no value until it has been practiced.

Limits#

• Normalcy bias is more described than measured: statistics on disaster response are fragile, and some researchers believe crowd behavior in crises is less passive than is often said.
• Not preparing for everything is sometimes reasonable: you cannot protect against every scenario, and preparation has a cost. The bias begins when the decision is not made consciously, by comparing costs and effects.
• The hindsight bias points the other way: after the fact, the incident seems “obvious” (see Hindsight bias). Avoid harshly judging yesterday's decision with today's information.
• In the two incidents cited, attributing it to normalcy bias is an interpretation: published analyses describe technical and organizational failures, not people's mindset.

Sources and verification#

• Omer & Alon (1994), “The continuity principle: A unified approach to disaster and trauma”, American Journal of Community Psychology — the “continuity principle.”
• GitLab (2017), “Postmortem of database outage of January 31” — timeline, volumes, backup failure.
• Netcraft (March 2021), “3.6 million websites taken offline after fire at OVH datacenters” — 3.6 million sites, 464,000 domains.
• Siècle Digital (March 10, 2021), report on the Strasbourg fire

See also#