A submarine’s life-support system is critical for an obvious reason: failure threatens the people inside, and the crew cannot simply open a window.
As the old engineering joke goes: there are more airplanes under water than submarines in the sky. The joke works because operating context matters. A minor fault in one environment can be catastrophic in another.
The same principle applies to business technology. Boards keep asking the wrong first question.
They ask: “Is this technology critical?”
They should ask: critical to what, for whom, and how fast?
The Same Outage, Different Harm
An unavailable marketing page may be inconvenient. The same class of outage affecting an online payment service, a hospital workflow, an emergency communication channel or an authentication platform can stop critical operations.
The server does not know the difference. The business does. Or it should.
Criticality does not live inside the application, the cloud region or the supplier’s brand name. It comes from the business context and the consequences of failure. That is why a small technical component can deserve board attention: it may be the hidden pump keeping the whole submarine habitable.
Identity is the usual hidden pump. So is the one network path nobody mapped. So is the specialist who is on leave, and the runbook that only exists in their head.
Questions That Locate the Harm
Before you accept a criticality rating, force the map:
- Which business service depends on it?
- What data passes through it?
- Who is harmed when it fails?
- Is the harm immediate, cumulative or reversible?
- What else fails with it?
Immediate harm is a payments outage at noon. Cumulative harm is a slow corruption of customer records that nobody notices until reconciliation. Reversible harm can still be expensive; irreversible harm is why you do not treat all “P1s” as equivalent.
Urgent is still allowed here. A delayed internal presentation can be urgent. It is not a life-support failure. Emergency is the actual or imminent threat that requires non-routine coordination. A marketing CMS going dark is rarely that. An authentication platform going dark often is—because every other service is sitting on it, waiting to breathe.
Small Dependencies, Board-Sized Consequences
The items that surprise directors are almost never the systems with the biggest budgets. They are the unglamorous ones: a DNS record, a certificate, a single-tenant connection, a third-party messaging gateway, a privileged identity store.
If management cannot show the chain from that component to an essential service, they cannot claim they understand criticality. They can only claim they understand inventory.
Board question: Which apparently small dependency could stop one of our essential services?
Relevant Sources
- Cybersecurity Incident — NIST CSRC Glossary — https://csrc.nist.gov/glossary/term/cybersecurity_incident
- Event — NIST CSRC Glossary — https://csrc.nist.gov/glossary/term/event
- Regulation (EU) 2022/2554 (DORA), Article 3 — EUR-Lex — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
If you want a working session that traces essential services down to the hidden pumps, that is board-level resilience work—not an IT inventory exercise. Contact me.