In 2026, a software defect is no longer just a bug. It's a potential multi-million euro liability. Why we should follow IT Security regulations now!

Table of Contents▾

Often when I discuss IT security related topics with customers or other parties a certain confusion becomes apparent. “Wait, wasn’t NIS2 for data protection?” .. “I thought we can eliminate our liability by putting it in the slide deck we send to the customer and which he approved?” This is totally understandable, as the EU Commission has published a ton of regulations that make it very difficult to keep track of the “important stuff”. Not saying there are meaningless regulations in the EU (shame on you if you feel like this :-) but some regulations are more important than others from a practical business standpoint to keep the bottom line of the business running & avoid risky/expensive non-compliance cases. Therefore, I want to bring a big of light into IT security related regulations “most typical” organizations should/must follow to be compliant in the EU. If you are in a very specific sector, like the health industry or medical devices or legal then you have to follow other regulations on top of the ones below. However, if you are in one of those areas chances are high you know which regulations to follow as non-compliance can have catastrophic consequences if not.

Before we start I wanted to take one myth away. Many IT (implementation) companies still seem to believe that “IT compliance is a task of the customer”, implicitly assuming they do not need to incorporate this into their everyday IT work-stream. They are, in my humble opinion, totally wrong. A law called “Product Liability Directive” makes you directly legally accountable, regardless if you take out responsibility on “slide 97 of the RFP presentation”. If your product (or IT project for that matter) is non-compliant & the customer has a damage because of this you might face compensation claims in court, in addition to reputational damages. With this aside let’s dive into the most relevant regulations.

Therefore, it is of high importance that every IT project has a design pattern based Architectural Design Document (ADD) that derived from the law and organization specific core business processes. When working like this the responsible IT Architect can take regulations into consideration when designing the system and avoid mistakes early on that might be very hard / impossible to correct later.

---

What are the major regulations we have to take into consideration?#

For most corporations that are operating in the EU the following regulations are relevant in terms of IT Security:

• NIS2 Directive / DORA for financial institutions
• EU AI Act
• CRA - Cyber Resilience Act (from end of 2027 onwards)
• Product Liability Directive (PLD)
• General Data Protection Directive (GDPR)

---

Foundations GDPR, NIS2 & CRA#

This seems like a short list, but behind those regulations is a massive list of requirements European organizations have to follow. One of my LinkedIn contacts publishes a list of the highest GDPR fines each month, and they go into the millions and tens of millions. So this is not a pure academic exercise but pure risk mitigation. What follow below is very high-level and generalized for better understanding. The mentioned regulations have hundreds of Articles and recitals so there are of course always exceptions. To understand how those regulations work let’s explore this from the ground up in simple terms. Every business these days needs data, that is rather obvious.

GDPR interests of people

Be it because you employ people, you work with vendors or business partners and of course your customers. In a typical organization a lot of data if flowing in and out of the organization. This data can contain information of natural people like the first name, last name, email but also potentially more sensitive data like a bank account number or health data. For personal data the EU Commission introduced a regulation called GDPR or for long General Data Protection Directive. This regulation, or the local implementation of this directive, ensure that the fundamental rights of every persons data in the EU should be respected. Typically people give you their data for a specific purpose, like sending them an invoice or repairing their car. A general rule of thumb is: Every new purpose you use data for needs explicit approval of the data subjects (the people). So, when you are a car repair shop using the information to send invoices and you use the data also to train your local “car repair GPT” LLM you need explicit approval of the people as this is a new purpose. Other than that personal data must be properly protected, corrected if needed and in case of a breach the organization must report in a certain timeframe So your IT security must be good enough to protect people’s data. If not you risk fines, that happen more and more and can be quite hefty (up to 10 million EUR or 2% of total global turnover).

On top of the data layer there is typically some form of integration / connection and then an application layer, so applications that make use of the data in some form.

Application Layer + Data Layer

When using applications there is a certain chance you will encounter the NIS2 regulation. This regulation is not binding for most organization but can be depending if you work in a critical area like healthcare, transportation, electricity grid maintenance and certain sectors mentioned in the Annex of the regulation. This regulation is, to say it bluntly, brutal. Several changes compared to previous years have been made. First, board level members are now directly responsible for IT security failures and cannot say anymore “IT is managing the IT security”. This argument was taken away and board members must actively manage IT security and risk personal liability in case of incidents. Secondly, the timelines for incident reportings are now pretty short. For example: You have a data breach or an insider attack in your organization and your systems trigger an alarm! In case of a serious incident you must send a first report to competent authorities within 24h. NIS2 is more process driven and forces you to make your IT system more robust. Microsoft for example offers a superb suit of products for those kinds of use cases ranging from Sentinel to Purview and related tools. Important to know is, that most applications will not be NIS2 compliant out of the box. So you will need additional effort for logging, a proper SIEM configuration so that alerts get triggered and so on and so forth. Important to note is also that NIS2 affected organization also must ensure their supply chain is NIS2 compliant. So this could to the fact that way more companies need to be NIS2 compliant than originally intended.

Now, I mentioned that most business applications will not be out of the box NIS2 compliant. This is understandable as making them NIS2 compliant for every use case is practically impossible. Best a vendor can do is: Offer the tools to make it compliant & giving good documentation how to do it. Most cloud SAAS providers are doing a good job here.

There is one exception however: Financial companies are somewhat excluded here as they have their own framework, namely DORA. But taking this into this article would be a bit much & again … People in highly regulated industries most likely know which regulations to follow :-)

CRA Inclusion

The EU Commission made the decision to pass another regulation, I know I know … another one …, about security. Stick with me, this one is less “work” for the implementation party and more for the vendors. With the CRA getting into effect software vendors have to make sure their software product are “secure by design & by default”. While those terms seem a bit vague the Act even gives detailed definitions what this means. An example is that products must be protected against know attacks at the time of putting the product into the market. When talking about AI so called “prompt injections” are a pretty common threat where people try to use manipulated and non-typical prompts to alter the behavior of a LLM in a way it was not designed to respond. When the CRA enters full force vendors of software, also SAAS products, must ensure their products are safe out of the box.

Lets sum this up as an intermediate step here:

• Data security of personal data -> GDPR
• IT Processes and Tools must be secure -> NIS2
• CRA (from end of 2027) -> IT products must be secure by design and default

---

EU AI Act & the Product Liability Directive (PLD)#

While everyone starts using AI, is already progressing further into creating real business value … yes I have to say it: It is always about ROI in the end, also for AI solutions, or just starting out with AI in an organization. While the AI Act is strictly speaking not an IT Security regulation it is targeted at secure and compliant usage of AI systems, especially “high-risk” AI systems (Art. 6 AI Act & Annex III of the AI Act). If you make use of AI and might fall into this category you have to follow the AI Act as well. It even has explicit Articles for Risk Management (Art. 9), Data Governance (Art. 10) and obligations for deployers for such systems (Art. 26). For guidance of what secure by design means an organization can make use of the CRA, as the CRA has a comprehensive, very detailed description of those topics build in so to say.

Last but certainly not least, we have to talk about a lesser known regulation. Often when I go to compliance and/or IT security sessions where also legal topics are discussed this regulation gets forgotten, or potentially ignored. I am talking about the revised “Product Liability Directive” or PLD for short.

PLD inclusion

The PLD uncovers an uncomfortable truth for IT implementation companies & brings more clarification for customers and all kinds of organizations that make use of IT companies to implement software for their organization. In the past it was unclear if a bug/mistake in a software that caused harm was a solid foundation to demand financial compensation in court. The revised PLD made it clear that mistakes and bugs in a software product can be classified as a “defective product”. What does this have to do with IT security you may ask? Well, if someone implements software and has a bug in it, also a security bug he will be held liable for it. To give a concrete example: An IT implementation partner does not follow security best practices and the customers data gets leaked. In this case the product (so the IT project) might be considered defective and a court might rule that compensation payments in favor of the organization running the application. So long story short: “I deliver my project, go on and thats it” does not work anymore. A mistake / bug could cost you dearly.

---

Summary & Action Points#

That was it. Overall I think the current landscape in the EU is really challenging. Especially for IT teams. The architect needs to have those legislations in the head when making operative IT decisions. This is a challenge which is, in my humble opinion, underestimated at the moment.

I would recommend to every IT person to (slowly) start working & reading those regulations step by step to get a better understanding of those laws. It might help to keep the following question in mind when reading: “What does the regulator want to achieve with this Regulation/concrete Article??” At least it helps me a lot when skimming through all those pages.

---

Disclaimer#

This post is for informational purposes only & only constitutes the opinion of the author - not the companies the author might be employed and/or connected with in any manner! Also this does not constitute legal advice. For specific guidance related to the topics discussed or other legal matters, please consult a qualified professional / lawyer and/or audit firms tech consultancy advisory for qualified and legally binding answers.