Complexity and Third Parties: The Pattern Boards Need to Break

Even though I use the Liechtenstein case as my starting point, this is not about that case. It is about a pattern, one that shows up in large, grown environments, wherever they are run, once an attack succeeds.

In late July, attackers gained access to Liechtenstein’s register of beneficial owners. Copies of data on roughly 31,000 legal entities were taken. Eight days later, Fabian Schmid, head of the Office of Information Technology, told the NZZ am Sonntag that the attackers had searched the system “until they found a weakness in the application.” The cause was apparently a logic flaw in how the application checked permissions. The application had been built and maintained by an external firm, which was also contractually responsible for security. Regular security tests had taken place. It still was not enough.

That combination interests me far more than the question of who was behind the attack. It points to five patterns I keep finding, in different forms, across many environments, well beyond public administration. Anyone who takes these five patterns seriously should not wait for a comparable case closer to home before examining them.

Environments we no longer control

Modern IT landscapes grow over years. Every single integration, every additional feature, made sense on its own. Add them up, and you get a level of complexity that hardly anyone fully grasps any more, not even the specialists responsible for it. What is often missing in these situations is the willingness to admit the scale of that complexity. Liechtenstein illustrates this well: a permissions logic that nobody fully understands any more is not the exception in such an environment. It is often the logical result of growth.

For the board, this means: features and integrations are not an end in themselves. Every additional connection widens the attack surface unless it is controlled down to the detail. Anyone unable to provide that level of control has two options. Either invest in specialists who genuinely and demonstrably master that complexity, or simplify the platform until it becomes manageable again. Both cost money. Doing nothing costs more in the end. Above all, when personal data is involved, that inaction becomes a risk for the people affected, not just for the company.

Security is never uniformly high

Here too, I would argue for a radical mindset shift on the board. The starting point for any discussion should be the assumption that an attack will happen. The only open question is when, and where it first breaks through.

A second insight follows from that, one that gets lost in daily practice: security within an organisation is rarely uniform. It varies between network, application and data layers, depending on patch status, data criticality, process maturity and the current threat landscape. Anyone who assumes uniform protection overlooks exactly the point where defences are weakest. In Liechtenstein, it was the permissions logic of a single application, less protected than the rest of the system. Tomorrow, it could be something entirely different.

For the board, this means directing attention and budget to where criticality and actual protection diverge most, rather than spreading them evenly across an assumed, organisation-wide security status.

Theory does not replace practice

Like Liechtenstein, companies typically have contracts, defined standards and regular security testing. On paper, security in Liechtenstein was in order: according to its own organisational chart, the Office of Information Technology has its own CISO function, reporting directly to its leadership. That is exactly the point. On paper, it was enough. In practice, it was not.

Many people in cybersecurity today work theoretically, with policies, frameworks and certificates. Those who genuinely attack and defend in practice are, comparatively, often underweighted. A security test that works through a checklist finds what is on the checklist. An attacker who systematically searches for a weakness finds what is actually there. That is the gap Liechtenstein fell into, and others fall into it regularly, the same way. I will put this bluntly: anyone deciding on cybersecurity at board level should know how many of their own tests genuinely try to break the system, and how many merely confirm what was already expected.

We often monitor the wrong thing

The attackers were apparently able to search the system for an extended period before they succeeded. We frequently monitor whether a system is running and detect standardised attacks. We rarely monitor whether someone is systematically working through its logic, and as a result we often miss the anomaly itself. This is not an isolated case. According to IBM’s 2025 Cost of a Data Breach Report, it takes an average of 241 days globally to identify and contain a data breach, the lowest figure in nine years, but still roughly eight months. In Liechtenstein, the irregularity was apparently first noticed by the Office of Justice, which uses the register operationally, not by IT security itself. In many other cases, months pass before anyone notices at all. Organisations often collect so much data that the anomaly gets lost in the noise. Artificial intelligence can help here, but it is no cure-all.

Then there are outsourced systems, applications and services. From my own experience as a CEO and board member, I know this: a contract or an attestation confirms that a process is documented. It does not confirm that anyone in-house understands what is actually happening in the outsourced operation. This is precisely where we need to assess third parties differently and integrate them more closely into our own security review, rather than relying on their assurances. That makes the relationship more demanding and more expensive. A provider required to undergo certifications and independent audits will not make its offering cheaper. You pay that price upfront, or you pay it afterwards, as Liechtenstein is learning right now. Worse still, the people whose personal data is involved pay it too.

The limits of outsourcing

Outsourcing has been, and often still is, the right call. Few companies can build every competency in-house. But outsourcing only works as long as control over the outsourced service is retained. That control is missing in many of the situations I come across. Which raises an uncomfortable question: at what level of complexity and dependency does a division of labour stop being safe to operate, simply because, in the end, nobody truly has access to what is actually running?

A mindset shift, and a board’s job

These five patterns reinforce each other: too much complexity, unevenly distributed security, too much theory and too little practice, the wrong kind of monitoring, uncontrolled outsourcing. This is not an IT topic. It is a governance question, because liability under Art. 754 CO (Swiss Code of Obligations) cannot be outsourced through a contract or an attestation, any more than the knowledge of what is actually happening in one’s own environment can. That applies to a register operator in Vaduz just as much as to any company that outsources its core processes.

A simple test shows where a board actually stands. Ask for an understandable overview: who has access to which systems and data, for what reason, and from where. Not the raw technical list, but a version readable without an IT background. If that overview cannot be produced within a reasonable time, in an understandable form, that failure is itself a finding. It means the level of complexity has reached a point that deserves attention.

Technology can be delegated. Responsibility cannot.