I have said it from a stage more than once. Stop chasing compliance, build real resilience. The room nods, someone writes it down, and we move to the next slide.
It sounds serious, the kind of line a person who has seen a few things is supposed to say. And in eighteen years I have not once watched that sentence change what an organization did the following Monday.
So what do we actually mean by it? I have started to think we do not know. We say it at every conference and put it in every board paper. It has become the polite way to look down on compliance without having to say what we would do instead. And the two words carrying all of that weight, “real” and “resilience,” are the two nobody stops to define.
Start with “real.” We only put that word in front of something when we already suspect the rest of it is not. Nobody says real gravity, or real arithmetic. When we say real resilience, we are admitting, without admitting it, that most of what we file under resilience is paper. The policy nobody reads. The recovery plan nobody has run. The four-hour recovery target sitting next to a system that has never once been switched off to see whether the four hours hold. “Real” is us confessing, in a single word, that we do not quite trust our own vocabulary. It is the most honest thing in the sentence, and the part we skip past fastest.
Then there is “resilience,” and this is where I part ways with how most of us use it. Resilience is not vague. It is not a feeling, not a maturity score, not a color on a heat map. It is what is still working when something breaks, and how long it takes to come back. That can be measured. Recovery time is a number. The share of a service still running while you are under attack is a number. And the figure almost nobody writes down, the gap between the moment you know something is wrong and the moment someone actually decides what to do about it, is a number too. In most of the incidents I have seen, that is where the hours (and days) disappear. Not in the technology. In the wait for someone with the authority to say yes.
I have watched a company lose a day and a half to exactly that. On paper everything was in order. ISO/IEC 27001 certified, NIS2 measures approved by the board, a continuity plan with a recovery target written next to every critical system. Then something actually broke. The failover took twenty minutes. Getting a human being with the authority to approve it took eleven hours, because the one person who could say yes was travelling and nobody below them would own the call. The plan worked perfectly. The recovery took thirty-six hours. And for all thirty-six of them, on paper, they were resilient.
That is the gap the phrase keeps pointing at without wanting to stand inside it. So the honest question is not whether these frameworks make you resilient. It is where, precisely, each of them touches that gap, because they do not touch it evenly, and most of what they ask for does not touch it at all.
ISO/IEC 27001 gets treated as the paperwork standard, and done lazily it is one. But there is a moment in it that is real, and it is not in Annex A. It is in the cycle: you assess a risk, you decide how to treat it, you act, you check. The whole thing lives or dies on the word “decide.” A risk register is worth something at exactly one moment, when a person with a budget looks at a line and commits to changing it. Everything before that is preparation and everything after it is admin. When the register gets filled in, color-coded, reviewed and filed with no decision in the middle, you have not managed a risk. You have produced a signed, dated, audit-ready document proving you saw it coming and did nothing. The auditor cannot tell those two apart. The incident can.
NIS2 does something ISO never did. It drags cybersecurity out of the IT department and puts it on the board, which now has to approve the measures, oversee them, sit through training, and can be held personally liable when it all goes wrong. It also starts a clock: twenty-four hours for an early warning, seventy-two for a fuller one, and a month for the final report. Both of those are real. A named, liable person decides differently from a committee, because they cannot make an awkward choice disappear by passing it around the table until it dissolves. And a twenty-four-hour clock cannot be answered with a binder.
But I want to be honest about what the clock does and does not do. It does not make your response any good. It shortens the time you have before you must admit you are in trouble. It does nothing to get you out of trouble faster. You can file a flawless warning at hour twenty-three and still be down for nine days. NIS2 measures how quickly you own up. It says nothing about how quickly you recover.
DORA is the only one of the three that refuses to take your word for it. For the entities it covers, a plan is not enough. You test the systems behind your critical functions every year, and if the regulator considers you significant, you sit through threat-led penetration testing, on your live production systems, run by people paid to get in, with your own defenders kept in the dark until it is over.
That is the closest anything in European regulation comes to measuring resilience honestly, because it does the one thing a document cannot: it breaks something on purpose and watches what you actually do. A report from that kind of exercise does not tell you that you have a plan. It tells you what the plan did when someone competent went looking for the difference between your architecture diagram and your Tuesday. There is always a difference. DORA just makes you find it before an attacker does.
Line the three up and the same thing shows through all of them, even though only one says it out loud. Each produces resilience where it forces a decision, an owner, or a proof, and produces paper everywhere else. Which means the work that matters is not implementing the framework. It is the handful of things the framework will never make you do, done anyway.
And here is the uncomfortable part, the part that has nothing to do with technology. The reason we do not run the test is not that we lack the tools or the budget. It is that a test can be failed, and failed in front of the very people we spend the rest of the year reassuring. A register can only ever agree with you. A test can contradict you, on the record, with your name on the report. So we quietly choose the version that cannot embarrass us, and we call it prudence. That is a human problem long before it is a security one, and it is the real reason the frameworks stop where they do. Every framework ever written can require a plan. Not one of them can make you willing to find out whether it holds.
The first is to test the thing you are most afraid to test. Every organization has one system it will happily run a tabletop around and never actually touch, because everyone in the room quietly knows what would happen if they did. That system is your real risk, and the reluctance is the tell. DORA forces banks to do this on live production. Nobody forces a hospital, a water utility, or a logistics operator, and they are the ones with the most to learn. You do not need a regulator to schedule your own failure. You need to decide you would rather fail a test you called than an incident you did not.
A real test does the one thing a register cannot. It finds the failure you never wrote down: the runbook that quietly assumed an engineer who left in the spring, the critical function that turned out to rest on a single supplier nobody in the room owned, the recovery target that held on paper and became half a day the moment someone had to be woken to approve the fix. None of that lives in a risk register, because a register holds what you already know, and an incident is built almost entirely out of what you assumed. A tabletop where everyone reads the plan aloud will not surface it either; people are far too reasonable in a meeting room. You find it by pulling the plug, in a window you chose, and watching what the organization does when the thing it was promised could never fail, fails. That is the difference between believing you can recover and knowing it.
The second is to measure the wait, not only the recovery. Put a stopwatch on the gap between detection and decision, in every drill and every real incident, and write the number down. It is the most useful figure you are not collecting, and it is almost never a technology number. It is a governance number. It tells you whether anyone is actually allowed to act at three in the morning, or whether your entire response is quietly waiting on one person’s phone. Track it across a year and it stops being an anecdote and becomes a trend, and the trend is nearly always the same: the technical half of your response has been optimized to death, and the decision sitting in front of it has never once been touched. That is the number I would take to a board, because it is the one thing they can actually fix, and usually the one thing they are the cause of.
Which leads to the third, the one that costs nothing and gets skipped anyway: decide who can say yes before the night it matters. Name the person. Name the deputy. Agree in daylight, and in writing, the irreversible calls they are allowed to make on their own, cutting a system off, failing over, going public, so that nobody burns eleven hours hunting for permission while the clock NIS2 handed you runs down. This is what NIS2’s liability is actually good for. Do not use it only to punish the board after the fact. Use it to make the board delegate the decision before the fact.
The fourth is smaller and blunter. Restore a backup you actually depend on, on an ordinary day, with no warning. A backup that has never been restored is not a backup. It is a hope with a schedule.
None of that earns a certificate, and none of it is a maturity model. All of it produces the one thing no framework can hand you: evidence that the plan works when nobody is watching it. It is slower and less impressive than a certificate, and it is the only version that survives contact with a real incident.
So here is what I would put on the slide, instead of “real resilience, not compliance.” A question. When did you last break your own critical service on purpose, who was in the room to watch it fail or come back, and how long did it take before someone was allowed to decide? Answer that and you already have the thing; you never needed the slogan. Fail to answer it and no framework is going to hand it to you, because the frameworks were only ever an invitation to decide, to own it, and to prove it. Proving it is the part almost everyone skips, quietly, while certifying the standard, appointing the owner and filing the report inside the hour. You do not find out whether you were resilient on the day the certificate arrives. You find out at three in the morning, in the time it takes one person to pick up the phone and say run it.
