Some companies respond to questions about security with complete confidence. They have safeguards in place, documented procedures and successful audit results. Everything appears to be under control. Yet in some cases, a single unforeseen event is enough to cause serious disruption. This is where the difference between apparent security and genuine resilience becomes clear.

Apparent security can be summarised in a single sentence: the system is well protected as long as everything goes according to plan. Resilience begins when the plan breaks down.

At first glance, the distinction may seem subtle. In practice, it separates organisations into two groups that are almost impossible to tell apart under normal conditions. Both have safeguards. Both pass audits. The difference only becomes visible when disruption occurs, especially when it falls outside any existing scenario.

Apparent security is often reflected in statements such as: “We have procedures. We passed the audit. The provider guarantees availability under the contract.” Each of these describes the situation on paper rather than the organisation’s ability to continue operating during disruption. Documentation is necessary, but it cannot restore operations on its own.

Apparent security rarely results from negligence or bad intentions. Quite the opposite. It often develops in organisations that have invested heavily in protection and have every reason to believe they are prepared. The problem is that the entire system has been designed and tested under conditions anticipated by those who created the plan. As discussed in the context of systemic risks, disruptions may be technical, legal or geopolitical. They rarely conform to what has been written into a procedure.

It is also worth clarifying what resilience is not. It is not simply another layer of safeguards or more extensive documentation. A resilient architecture maintains operational continuity and control over data during disruption, including scenarios that have not previously been anticipated or documented. Put simply, safeguards are designed to ensure that the plan succeeds. Resilience determines what happens once the plan has failed.

For businesses, this distinction leads to several specific questions. First: which of our security mechanisms assume that everything else is operating normally? Second: what happens when that assumption no longer holds? Third: has anyone in our organisation tested a scenario in which the safeguard itself fails, rather than only the threat it is designed to protect against?

A simple distinction often used in business continuity discussions can also be helpful. Security is tested by checking whether the system operates according to plan. Resilience can only be tested by simulating a situation in which normal control mechanisms are no longer available. This clearly separates the two concepts and shows what exercises that genuinely reveal an organisation’s readiness should look like.

The answers to these questions may be uncomfortable, and that is entirely appropriate. Discomfort at the analysis stage costs very little. The same discomfort discovered during a crisis can cost real money, customers and reputation.

The simplest test for apparent security is this: if the sense of protection depends on the assumption that everything will go according to plan, it provides only the illusion of security, not genuine protection. Genuine resilience begins with accepting that, at some point, the plan will fail. It also means preparing the organisation for precisely that moment.