Pay attention when using Low-Code / No-Code (LCNC) tools in highly regulated industries. There could be compliance risks.

Recently, one of the authors has written a lot about Regulatory Changes in the European Union. Therefore it’s clear that we, as solution providers, architects, and consultants, have to skill up and learn legal and compliance matters, as we wrote here. A basic legal understanding of GDPR, NIS2, DLP, SOX, IFRS, the EU AI Act, DORA, HIPAA, and contract/civil law of your country should be the foundation—alongside technical understanding and skills—for every architect who works on or leads large cloud projects. If some of those abbreviations are new to you, I would highly recommend to you to start studying those frameworks (or their local legally binding national laws).

There are many reasons why you might want to do this—for example, to avoid personal liability in court, as your platform provider will do everything they can to avoid liability and protect their reputation if something goes terrible wrong. As we explained in this article, it is important to understand the limitations and use cases a platform, like a LCNC SaaS product, was built for, and what it was not built for. To grasp this concept, you must understand the legal frameworks within which you operate and the design patterns they require you to implement to be compliant.

Most LCNC platforms are built for simple to moderately complex business applications & automations in non-highly regulated industries. They really excel in those areas and made all those innovations possible we see everyday on LinkedIn. So this article is not meant to take everything away from those super cool achievements that LCNC platforms have enabled us to do. To give a concrete example. You distribute goods from a warehouse, and you need a Power Platform-based CRM to manage all the customers, stock, orders and payments. So LCNC is for you in this case. Wait, did I say "orders and ...payments"? Yes, I did, and here lies the crux. As explained in previous articles LCNC platforms are not built for financial data by design, and therefore can never be compliant, regardless "how good" you build the solution. In this case you can build your CRM with a LCNC SaaS, but you need to get the "payment" part out to a financial / treasury system like Finance & Operations (F&O) of Microsoft - just to name one very common system here.

This is the reason for this article! We want to explain in more depth why LCNC is not a fit for healthcare and any legally regulated data in general & explain what you should use instead.

What is the problem?

As mentioned above..., some industries have very strict requirements for IT systems. In our platform article about liability of your provider we described how these industries implement specific cloud design patterns that are derived from the legal frameworks governing them. This can come from either the EU, local laws or international standards. Those frameworks are there for a reason. They protect very sensitive data, for example from patients (FHIR7 for data exchange / EHDS - European Health Data Space and others), and are the reason why you as a patient do not want to see your data processed in a LCNC application, or the respective SaaS platform the LCNC is based on, for example Power Platform. In finance, just to also mention a DORA regulated field, you need in immutability design pattern implementation, instant disaster recovery, event sourcing design pattern, implementations of the saga design pattern to ensure a constantly integer database at all times ... and much much more. All this LCNC cannot deliver by design, and therefore you always have a bad solution if you use those tools for your "law firm client". This seems to be relatively simple to understand, however many people still struggle with this and have a "Okay but I can build everything with Power Platform/Mendix if I am good enough in the tech tool" mindset. Okay, to be fair there are exceptions, if you use a small Canvas App to manage meeting rooms / parking spot bookings, there might be a chance this could work. But I doubt customers pay the subscription fees for such simple applications. Information of all the above can be found in the compliance center of your Cloud Service provider, which in my field is Microsoft: Link to Documentation.

How to approach such a use case/project - also in the era of AI

Practical Use Case & General Approach

Let's give a practical example to clarify what this means in practice. For now, we will focus on healthcare, as there is significant work required for digitalization, but also many regulations to follow. So, let's say you have a customer approaching you or coming in via a sales channel who works in healthcare with patient data and needs to build a system to manage patient referrals to specialist doctors—for example, if a patient needs to see a neurologist or a psychiatrist. These treatments are not only very expensive, but in the case of a data leak, they can have serious consequences for the patient, as these areas are still, for reasons we do not understand at all, stereotyped as "abnormal," despite mental health being incredibly important in today's stressful world.

Now, this client walks in and asks for an easy solution to manage those referrals to specialist doctors, as at the moment he does manage this manual. Maybe he has already seen some advertising on LinkedIn or YouTube about LCNC and is wondering if this could be a valid solution for his painful manual process.

So a process we would advise to an architect sitting in such a meeting could be something like the following:

1. What industry is the customer in (ideally you check this beforehand and read the respective frameworks/laws beforehand) & is it highly regulated? -> In our case it is healthcare, so both can be answered with: yes
2. Is the process mission critical? So use a common definition (for example the one from the Azure Well Architected Framework) to define if the process could be mission critical for the customer, even when the customer does not realize this himself yet. -> In our case: yes, if patient data gets leaked the company might face existential threats by the state regulator and laws suits.
3. Check which design patterns the regulation is implementing & understand the "why" those patterns are implemented. In other words: try to take the perspective of your potential customer and see the world through his eyes. I know this is very hard, but at least try! -> In our case Health related regulations implement a whole bunch of design patterns like "Security by Design" (GDPR Article 25 - "Data protection by design and by default") / "Zero trust" as in health care no file should be stored without explicit permission to do so.
4. Create your design, so an Architectural Design Document (ADD), for the application, and try to implement those design patterns. If that is not possible try to get as close as possible & document the gap to be transparent. Especially the last step is important here. If you forget to do that a later auditor can assume, and rightly so, that you just did poorly. If you document it is clear you thought about it and made an informed decision.

This will over time, and yes this takes time, improve your implementation and set the correct foundation for your project with the customer. Also there is no reason to be hectic. Take your time, even if your salesperson hurries you.

If you follow a structured approach with your organization or customer, you ensure that the final solution is:

• Fully compliant not only with industry regulation (for example HIPPA or DORA for banking) but also with general regulations like NIS2, AI Act and updated DLP
• Scalable and future proof as you implemented best practices of your chosen platform that are based on a solid design (Architectural Design Document)
• Secure as you took care of the industry regulations that, very often, mandate certain security standards (NIS2 etc.)
• Robust against later "major changes" as the foundation is rock solid

We are not saying this is the only approach, but in our opinion this is a very solid, time proven approach, that led many big projects to success. All this is independent of the technology, but some design patterns demand some technologies or rather exclude some.

Industry Clouds

At this point we made clear why certain industries are unlikely to use LCNC for applications that hold typical data of those industries, so for health care, patient data, for finance financial information and so on.

So, but there is no reason to reinvent the wheel in every project, which would be not only risky, as you might forget something, but also expensive. This is where industry clouds come into play. More and more organizations / customers demand solutions that are prebuild for their industry to 1.) accelerate development time 2.) adhere to regulatory standards out of the box and 3.) save money.

Working in the Microsoft Stack I can highly recommend the Industry Clouds of Microsoft, for example this one for Health Care. Microsoft did a fantastic job with those industry clouds tailoring them to the most relevant industries and providing extensive documentation. Those cloud blueprints are not only implementing best practices and providing reference architectures, they also implement design patterns und provide technology choices. So instead of reinventing the wheel you can start by making use of those industry clouds. However, be careful when implementing those, as they serve as a starting point, and do not let you out of the responsibility of choosing the right technology for the right information. One example is the reference architecture mentioned on this website.

There you do indeed see the Power Platform, in form of Customer Insights and Dataverse, present. However, when you dig a bit deeper into your cloud vendors documentation, in our case Microsoft, you will get more and more to the truth. In our case for FHIR compliant use cases most often a service called "Azure Health Data Services" is recommended. If you look up the documentation deeper and deeper you will notice that step by step all LCNC SaaS products are not mentioned anymore. Reason is quiet simple, most LCNC tools are not FHIR/HIPAA compliant as, just to name one simple example (but there are many more), every Power Platform Admin can see all the data. HIPAA requires auditable access logs, role-based permissions, and patient consent mechanisms. All of which are missing in Power Platform.

This is a big security risk for Protected Health Information (PHI) because Power Platform is not build by design for this kind of Role Based Access Control (RBAC) & the application of least privilege that comes with it. In our concrete case, very often, only the doctor who is treating the patient, and potentially the doctor above him if needed, should be able to see the patients data. Not every random Power Platform admin. So all in all:

1. Make use of industry clouds but understand that they are the starting point and you still need to understand which technology implements which design pattern & why.
2. Search deeper in the documentation until you found the right product / service
3. Contact your cloud service provider for detailed help if you have a highly regulated customer. They can (very likely) bring a global expert that can give you compliance & IT advise.

A quick remark in terms of AI

We want to address the topic of AI here as it gets more and more traction in the space of Line of Business (LOB) application worldwide. Generative AI, or the underlying Large Language Models (LLMs) have transformed the way many people work and think in the last two or three years.

However, in highly regulated industries the usage of those tools can be risky to say the least. As we shared shortly before XMAS 2024 the Dutch Government evaluated Microsoft 365 Copilot as non compliant, because of the vendor, Microsoft in this case, did not answer key questions about privacy and other concerns.

Does this mean you should not use this tool? No, but you need to understand what impact your choice of using it actually has in reality! So you need to understand the consequences of your actions. Especially in highly regulated industries a mistake in this area could mean the end, either bankruptcy or closure by government, of your organization.

We recommend that you check, again, the regulations like AI Act in Europe, NIS2 and the industry specific laws and regulations. Besides this you should do a DIA so a Data Impact Analysis before you go on.

One of the major reasons many corporations struggle after adopting products like Copilot is not the technology itself, but rather poor or non-existent data protection management. Copilot and similar tools just reveal those past shortcomings of the last decades. So get your Access Management in order, test it and then (potentially) use LLM based technology.

Wrap-up & Final Thoughts

So finally we want to conclude this one with some closing thoughts and wrap-up. The essence is really making use of regulations, understand what design pattern they implement and act accordingly, using common sense and not blindly adopting technology because "I can build it". The key points are:

• Compliance Challenges: Dataverse and Dynamics 365 Customer Insights are not inherently compliant with HIPAA, GDPR, or other healthcare regulations because, but not only, broad admin access and insufficient PHI security controls (as discussed).
• Intended Use in Healthcare: These tools are included in Microsoft's architecture for non-PHI use cases, such as patient engagement, population health analytics, and operational workflows, rather than for storing sensitive clinical data. This needs to be clear when looking at an architecture. Do not blindly trust diagrams.
• Risk Mitigation Strategies: Enforce strict Role-Based Access Control (RBAC) to prevent unauthorized PHI access. Ensure de-identification (so anonymization) before processing any patient data into a LCNC tool like Power Platform / Dataverse or any other LCNC tool. Use (the recommended) Virtual Health Data Tables to limit direct access to clinical records. Audit and monitor data access regularly to maintain compliance & keep those logs long enough, not just the typical 1 year or something.
• Final Recommendation: Organizations/Solution Providers must evaluate whether these tools align with their regulatory needs and apply proper governance policies to avoid compliance risks when handling PHI.

All in all, apply common sense when working with high-risk data. We would recommend doing a compliance review with a qualified party (an auditor or lawyer / audit firms tech team) before working with any kind of information we described in this article.

Disclaimer: This post is for informational purposes only & only constitutes the opinion of the authors - not the companies the authors 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 business line. There you will get legally binding answers to potential questions.