Higher Walls, Deeper Water: What Dutch Flood Engineering Teaches Boards About Cyber

“So the best we can hope for is that we fail, but not too badly?”

I have been asked some version of that question in almost every cyber governance session I have run, usually by an experienced Director with a long and successful career behind them. It is a fair question. For a long time I did not have a good answer to it.

I found one in a story about Dutch river dykes.

It arrived sideways, which is how the useful ones usually do. Roman Mars was interviewing the journalist Alex Davies on 99% Invisible about Davies' book on test engineering, the largely invisible profession that breaks things deliberately so the rest of us do not have to.¹ Davies mentioned a Dutch flood programme in passing. I have been reading about it ever since.

The winter of 1995

In 1993, and again in 1995, the Rhine and the Meuse ran higher than the Netherlands had planned for. Close to 250,000 people were evacuated, along with about a million animals, and damage ran past €400 million.² The dykes held, but not by much.

The obvious response was the one the Dutch had been refining for centuries. Build the dykes higher.

They decided not to, for two reasons that translate almost directly into boardroom cyber discussions.

The design basis had expired

A dyke is engineered to a specification: a water level with an associated return period, the one in 100 or one in 1,250 year event. That specification is calculated from historical hydrology. Once the climate driving that hydrology shifts, the number on the drawing stops describing the river you have. It describes a river that used to exist.

Building to a more demanding version of an unreliable number buys a more expensive wall and no additional confidence. The Dutch problem in the 1990s was not that their dykes were too low. It was that they no longer trusted the calculation that told them how low was too low.

Most cyber controls rest on a specification of the same kind, though it is not often written down anywhere a Board would see it. Awareness training assumes phishing is detectable by a trained eye. Callback verification assumes a voice on the phone belongs to the person it claims to. Threat models assume reconnaissance costs an adversary time and effort. Code review assumes software examined by capable people over many years has been examined adequately.

Every one of those is a statement about what an attacker can afford. Artificial Intelligence (AI) is revising all of them at once, and considerably faster than control frameworks get updated. When a model finds vulnerabilities in code that survived decades of expert scrutiny, the assumption being invalidated is not really a technical one. It is an actuarial one.

That is the same shape of problem the Dutch faced. Not weaker walls. A less reliable number.

A higher dyke means deeper water

The second reason is the one Directors sit forward for.

Every metre added to a dyke raises the level the river can reach before the dyke fails. Which means the volume of water held back by that wall, on the day it does fail, is larger. The likelihood of the event goes down and the severity of it goes up, in a single decision.

That trade also happens invisibly. The likelihood improvement is measurable and gets reported. The severity increase is usually not measured at all. There was a practical limit as well: Dutch river dykes have villages built along them, so raising them further meant demolishing the villages, and the prevention-only strategy had run out of social licence as much as engineering headroom.

Room for the River

What they built instead was a programme called Room for the River: approved by cabinet in 2006, delivered across more than 30 sites for around €2.3 billion, with most projects complete by 2018.³

The logic reverses the usual instinct. Rather than raise the barrier against the load, reduce the load. They moved dykes landward, lowered floodplains, cut new side channels, deepened river beds, lowered groynes, and in places deliberately gave land back to the water. At Nijmegen they relocated a dyke several hundred metres and opened a new channel through what had been the edge of the city. The target was to carry 16,000 cubic metres per second where the Rhine enters the country, up from 15,000, without raising dyke levels to get there.

One correction matters here, because it is the first thing a sceptical Director reaches for. This was not a retreat from prevention. The Netherlands did not lower its flood protection standards; it later tightened them. Room for the River is a preventive control. It simply works on the load instead of the barrier, and it reduces the consequence at the same time.

It was also considerably harder than raising dykes. It cost more, took longer, and needed land, planning approvals and the cooperation of municipalities being asked to give ground to a river. Why the Dutch chose the harder option anyway is a question worth its own answer, and I will come back to it.

This is not defence in depth

Here is where a cyber audience gets ahead of me, and where I want to slow down.

Defence in depth has been the profession's answer for twenty years, and it is a good one. Do not rely on a hard exterior. Layer controls so that any single failure is contained by the next. Segment, monitor, authenticate, encrypt, back up, rehearse. We have solid evidence that layering produces better outcomes than a strong perimeter alone.

Room for the River is not that. Defence in depth is layered dykes. It is barriers, all the way down, and it accepts the volume of water as a given. Nothing in defence in depth has ever told an organisation to collect less, hold it for less time, or keep less of it in one place.

The Dutch decision was different in kind. They treated the load itself as a variable.

Once you have that distinction, it is difficult to unsee in a technology environment. A flat internal network behind a strong perimeter is a high dyke over a deep polder. Consolidating data into a single store is efficient, easier to control, and enormously valuable to whoever eventually reaches it. Single sign-on reduces credential sprawl and concentrates the consequence of one compromised identity. Each of those decisions genuinely lowers likelihood. Each also deepens the water. Boards are shown the first half of that trade in the quarterly report and almost never the second.

The two Australian breaches every Director remembers make the point. What turned each into a national event was not only that someone got in. It was how much was sitting there when they did, how long it had been retained, and how far an intruder could move once inside. Data never collected cannot be exposed. Data already deleted cannot be exposed. A network divided into compartments limits how far the water travels.

Notice where that puts the decision. Layering is an architecture choice, and a Board can reasonably delegate it. Deciding what the organisation collects, why it holds it, and how long it keeps it is a decision about products, marketing, customer records and regulatory obligation. That one cannot be delegated to the security function, because the security function does not own any of it.

The consequence-side pre-mortem

I teach the pre-mortem as a Board technique. Assume the strategy or the control has already failed, suspend the question of likelihood, and work backwards to what caused it.

It is the closest thing a Board has to the discipline Davies spends his book on. Test engineers do not check whether a product survives its rated load. They break it deliberately, to learn how it fails and at what point. No organisation gets to do that to itself. We do not breach ourselves to find out how deep the water goes. The pre-mortem is destructive testing we can afford, which makes it worth asking whether we run it well.

It carries one structural bias. Working backwards from a failure leads to causes, and causes lead to more preventive controls. The loop closes on itself, which is precisely the loop the Dutch were stuck in.

So run a second pass. Having assumed the failure, ask a different question: what made the consequence severe? Not what let the water over the wall, but what determined how far it reached. Then ask which of those factors the organisation could design out now, while nothing is happening.

There is a distinction in the test engineering comparison worth holding onto. The test engineer breaks something to discover the failure mode. The Dutch went a step further and designed theirs, choosing in advance where the water would go.

Cause-side and consequence-side pre-mortems produce genuinely different answers. Only one of them ever produces “collect less”, “keep it for less time”, or “hold it in more than one place”.

Back to the question

So, is the best we can hope for that we fail, but not too badly?

No. The best we can hope for is that prevention holds, and prevention deserves to stay the first line. The Dutch never suggested otherwise, and their protection standards today are among the most demanding anywhere. What they worked out is that a taller wall is not the only way to improve those odds, and that past a certain point it starts working against you.

Three questions get a Board to the same place, without anyone having to concede that failure is inevitable.

The first of those has always been a reasonable question. What has changed is that the assumptions underneath our controls are now being revised in public, at speed, which makes it an urgent one.

The Dutch did not stop building dykes. They stopped treating the dyke as the whole answer, and went looking for the room they had given away.

← Back to Insights