There is one person who knows how it works. Not because that was ever agreed, but because he has been there longest. He fixes what goes wrong, knows the connections that are documented nowhere, and remembers which solution was once temporary and still is.

On a Tuesday, he hands in his notice.

That is the moment many organisations first see where their dependency really sits. Not in the systems, but in the knowledge around them. And that insight arrives with a notice period attached.

Dependency in itself is not a problem. It is part of modern business. The risk arises when that dependency grows faster than the understanding of it. IT then becomes not merely supporting but business-critical, and without ownership, alternatives and recoverability being arranged sharply enough.

Why this is a board-level matter

You do not need to know every system, contract or technical detail. You do need to know what the organisation genuinely depends on.

The core question is not whether IT is running. The core question is what happens when a critical system, a supplier, a connection or a key person is temporarily unavailable.

That question bears directly on continuity. Can clients still be served? Can production continue? Can orders, payments and schedules still be processed? And who decides when the answer is uncertain?

Dependency becomes dangerous when it stays implicit. The organisation then looks stable, while its actual resilience rests on assumptions, supplier promises and individual knowledge.

What I typically see

  • there is one person who knows how it really fits together, and that is recorded nowhere
  • a system that was once meant to be temporary now carries part of the business
  • the supplier has become critical without anyone having taken that decision
  • the agreements with that supplier cover response times, not whether you can work again afterwards
  • there is a continuity plan written for an organisation that no longer exists
  • at the last period of growth the IT grew along and the overview did not
  • nobody can say how long the organisation can hold out without a particular system, so the question is never asked
  • technical debt is recognised internally and never weighed at board level, because it is never on the board agenda
  • the question only reaches the table during an acquisition, an audit finding, or the departure of a key person.

The result is that the organisation knows IT matters, but does not know sharply which dependencies are genuinely business-critical.

The questions this raises

These questions are not technical. They are about what you can afford.

  • Which services, processes or client commitments must not come to a standstill?
  • Which systems, suppliers, connections and people are critical to those?
  • What happens if one of those dependencies falls away?
  • How quickly must recovery happen to limit commercial damage?
  • What shows that recovery is genuinely possible?
  • Who owns the dependency, not merely the system?
  • Which knowledge sits with one person, and what happens when they leave?
  • Which risks have been accepted, knowingly or otherwise?
  • Which dependencies have grown large enough to require an explicit decision?

These questions make IT discussable as a business risk. Not as a maintenance problem, but as a question about continuity and responsibility.

What a Reality Check delivers here

A Reality Check does not examine your entire IT environment. It starts from a concrete board-level question and looks at the dependencies underneath it.

On this subject, that typically produces:

  • a sharp picture of the processes or services at the centre of the question
  • an overview of the systems, suppliers, connections and people they depend on
  • the distinction between ordinary dependency and business-critical dependency
  • insight into recoverability, ownership and decision points
  • identification of knowledge that sits with a single person
  • an overview of assumptions about suppliers, agreements and recovery
  • decision points for the board, sharp enough to make the trade-off yourself
  • concrete priorities for follow-up.

What a Reality Check does not deliver is a cost estimate or an improvement programme. What a solution costs depends on choices you still have to make. Those choices stay yours.

The value does not lie in a complete inventory. The value lies in making visible the dependencies that have become a board-level concern.

In short

Dependency is not risky because it exists. It becomes risky when the organisation does not know sharply which dependencies are critical, who is accountable for them, and what happens when they fail.

Outsourcing moves execution, not responsibility.