Cybersecurity can be so reassuring. After all, we’ve inventoried everything: servers, clients, applications, databases, interfaces, cloud services. Every asset has an owner, a criticality level, a protection requirement, and—most importantly—a unique ID in the asset management system. The elephant in the room may not be listed, but the asset list is complete.
This is precisely where a fundamental problem lies with many asset-based approaches to cyberrisk management: they start with the object—not the risk scenario. The question then becomes, for example: How critical is this server? Yet a far more interesting question would be: What could actually happen—and how bad could it get?
After all, a cyber risk rarely arises in isolation from a single asset. It often only becomes critical through the interplay of several factors: compromised credentials, a lack of segmentation, privileged accounts, dependent systems, inadequate backups, external service providers, and a chain of unfortunate events. And that is precisely where the tail risks lurk: rare but potentially existential scenarios.
A single asset, when viewed in isolation, may seem only moderately critical. The resulting chain of events can nonetheless lead to weeks of production downtime, data loss, business disruption, or significant liability and reputational damage. The problem, therefore, is not asset management. The problem arises when we confuse asset management with risk management.
Good cyber risk management should therefore not primarily ask, "What assets do we have?" but rather, "What scenarios could really hurt us?" Only then does the question arise as to which assets, vulnerabilities, root causes, and dependencies are involved in these scenarios. After all, a perfectly maintained asset database can look extremely reassuring—until the elephant moves.
