Kode-1
risk

Why your board still can't see its technology risk

28 July 2026

Boards have never spent more time on technology. Cyber has a standing agenda item and a regulator behind it. AI has a working group, a policy, and a queue of briefings. And yet ask a director to describe where the organisation's technology risk actually sits, and the answer is usually the last incident or the most recent briefing topic — not the estate the enterprise runs on. The gap is structural, not personal. Cyber and AI reach the boardroom because they arrive pre-packaged: a named threat, a regulatory prompt, a shared vocabulary, and an industry of advisers supplying the briefing. The digital estate — the systems, integrations, and data flows that critical operations actually stand on — arrives with none of that. It has no single owner below the CIO, no annual report section, no headline when it quietly degrades. So the agenda fills with the topics that come with words, and the risk accumulates in the layer that does not. What the board sees instead are proxies. Project status reports, graded green, amber, red. Compliance registers, audit findings, budget variance. Each is true as far as it goes, and none of them is the estate. A transformation program can be green for six consecutive quarters while landing on a platform that cannot carry what it delivers. A register can be complete while two critical operations quietly share one ageing integration that nobody owns and nothing monitors. The proxies report the work; they do not report the ground the work stands on. Compare the way the same board handles financial risk. There, directors hold shared instruments — the balance sheet, the management accounts, the external audit — and they know how to interrogate them. A director who does not like a number can pull the thread. Technology risk has no equivalent instrument in most boardrooms: there is no artefact a director can hold that connects the operations the board is accountable for to the systems and dependencies they actually run on. Without the instrument, scrutiny defaults to whatever management chooses to present. The consequences are not abstract. Boards attest to operational resilience on tolerance levels they cannot connect to architecture — which means attesting without sight. Transformation investments are approved on the strength of a deck, because the deck is the only view available. And concentration risk — the shared platform, the single provider, the one integration under three critical operations — is discovered the way it is always discovered when nobody maps it: during the incident. Visibility, when it exists, has a specific shape. It is a map, kept current and kept honest, from each critical operation down to the systems, data flows, and providers underneath it. It shows what is shared, what is single point of failure, what is past its supportable life, and who owns each piece. It is not a technology document; it is a governance instrument — the technology equivalent of the balance sheet, and about as optional. A board does not need to become technical to use it. It needs to ask the questions the instrument makes answerable. Which systems sit under our most critical operation, and which of them are shared with other critical operations? What is the oldest thing on that path, and who owns it? Which single failure would we genuinely struggle to survive, and what specifically makes our stated tolerance for it true? If the answers take six weeks to assemble, that latency is itself the finding: the organisation does not currently have sight of its own ground. None of this asks directors to read architecture diagrams. It asks management to build the instrument and the board to insist on it — the same division of labour that already exists for the numbers. Digital leadership at board level does not begin with enthusiasm for technology. It begins with refusing to govern what cannot be seen. A practical place to start: ask management for one page — the top three critical operations, mapped to the systems and providers underneath them, with owners and single points of failure marked. Whatever cannot be produced inside a month is not a reporting gap. It is the current, honest measure of how much of its technology risk the board is carrying unsighted.
Field notes

The work, in your inbox.

Occasional notes on strategy, systems, delivery, and risk — written by the partners, sent when there’s something worth saying. Unsubscribe anytime.