Why your Low-Code / No-Code platform provider will not/never, take over your "Product Liability" from the new updated EU Directive (2024/2853)

Recently, I wrote about the (strongly) changing regulatory landscape in the EU regarding software products & IT Security. We learned that IT projects and deliverables will be considered "products" (see my washing machine example linked there) under the new Product Liability Directive (PLD), and that we can, and most likely will, be held legally & financially liable for our bugs or mistakes (Directive see here). Being "liable" means being taken to court and (potentially) paying compensation—just to be clear that this is not just a single "excuse email".

This seems to be straightforward for individual software development, but what about Low-Code/No-Code (LCNC) platforms like ServiceNow, Mendix, Power Platform, and others? Here you share the underlying platform as a SaaS and build on top of it. Well..., it is still unclear who takes on what chunk of liability - For this we need court decisions, after implementation of the directive into national law. However, one thing seems clear to me: liability will be shared, and your vendor will very likely not be liable for your misconfigurations and/or mistakes! LCNC platforms recently faced some heat in the security community for security flaws as they are easy to use and, therefore, also easy to misuse. To be fair, many, but not all, of these problems are either due to misconfiguration or incorrect usage of those platforms. While I am not saying they are secure by design by any means, which clearly they are not, most problems I see occurring & hear from other people are not to this, but rather by mistakes made in implementation. So literally during the "doing stuff" phase.

Let's examine this with an example

You use a low code platform to build some automation in the financial industry that manages financial market data, as well as internal financial information and distributes it internally to some high level stakeholders. Besides the fact that you should never use low code in those industries in the first place, you still go ahead and implement some automation. All works well for months, the automation, a cloud flow in Power Platform for example, does its job as intended. No one says anything, it just "runs".

Now, on a sunny Sunday morning it becomes apparent that your automation not only did "its job" but also sent sensitive data, to people outside your organizations/customers domain. So, it has literally created a data breach, in this case an automated one!

Of course this is highly simplified for this use case & the exact technical implementation does not matter here, but the question is now: If the affected stakeholders go to court who is paying? Well, from a lot of people in the LCNC space I hear things like: "My platform provider has to make sure its secure, right?". This is a very dangerous misconception we have to get rid of!

It is very likely that your platform provider will decline any liability for implementation mistakes, as their platform was not the cause of the problem in the first place.

Estimation of impact

The new directive ,in my opinion, will have a drastic impact in the IT industry in the EU in the next 2-3 years. While I am personally not a fan of this, we still have to make sure our products comply with the laws later implemented by each member state. As I wrote earlier, those directives are the minimum that each state has to implement.

The concrete impact will become clear once the directive is implemented, which will take some time as of writing this piece. However, it will be a drastic change for many people in the IT industry. Coming from Finance, where we have to follow laws 100% and work accurately with almost zero errors, I noticed that in the IT industry some people take shortcuts. This directive will make it way harder to get away with projects executed in an 80/20 manner. You might need to shift to a slower more accurate approach.

What to do?

Call for action seems pretty straightforward: We need to improve quality! Sounds simple, right?... Well in a competitive market where budgets are tight and economy is struggling this is not easy by any means. Often organizations/ projects run on tight budgets. In my opinion we can follow a process like this:

1. Choose the correct technology
2. Apply cloud design patterns (for example from Microsoft)
3. Follow best practices while implementing (to do that you have to know them in the first place so read this here: WAF for Power Platform)
4. Test your software (yes low code is also software development) against the intended use cases & document the results (to protect yourself against later claims)
5. Train and teach people and then go for it .. meaning go on with the typical steps to build IT tools.

Example

This process is not that easy, therefore I will repeat what I outlined in another article: We need to start by choosing the correct technology first:

Quite an old slide from one of my sessions, but still valid. We need to make sure, as early as possible in the project, to choose the correct technology, and not just blindly follow what we know best. To go with our example from the beginning:

• Is the customer highly regulated? It is a bank, so yes as this is financial sector. Most likely DORA applies here.
• Is the process mission critical? We do not know this, but if internal financial data got leaked it potentially is.
• Make use of design patterns. Financial systems implement a number of design patterns. Two important ones that are often used in combination are the so called Event Sourcing Design pattern and Immutable Design pattern.

Now we come to an answer to Question 1: Choice of right technology. The reason why LNCN should never be used in DORA regulated corporations, at least for critical processes, lies in the type most LCNC platforms are built and for what use cases they are build. LCNC systems are by design not build to implement an Event Sourcing Design pattern & Immutable Design pattern mixture needed for financial systems. Besides those two financial systems also require almost instant disaster recovery which the typical 99.9% SLA LCNC vendors have can never provide. Advanced data integrity (Saga Design pattern and others) is another example and so on and so forth. So LCNC tools introduce risks in highly regulated industries that cannot be mitigated by careful implementation

This does not mean LCNC are bad by any means, they are just not build for that use case. If we are talking about CRM systems, rapid app development, making apps quickly accessible for everyone and so on... So at this stage, our analysis can already stop, as the wrong technology was used. The same logic applies to HIPPA in healthcare and other areas. LCNC just cannot meet the compliance requirements "by design". So regardless "how good" your implementation is, you will never be compliant as the underlying SaaS platform is not build for that.

In this use case of a bank needing automation with financial data to distribute it a different systems. A system built for financial institutions would have been the appropriate choice and not a low code tool. So the mistake here was in choosing the wrong technology.

And this is the important point: We are liable for our mistakes not the vendor of the platform. Even if we do something "by mistake" we are still liable in court (most likely). Most vendors have guidelines and show what their software can and cannot do. For example industry clouds from Microsoft just to name one. We chose the wrong tool for the job. This leaves us legally liable,.. rather sooner than later.

Disclaimer: This post is for informational purposes only, and does not constitute legal advice. For specific guidance related to DLP, NIS2, EU AI Act or other legal matters, please consult a qualified professional / lawyer and/or audit firms tech consultancy business line. There you will get legally binding answers to potential questions.