From "IT Quality" to "Executive Guardrails" - Top 10 things to pay attention to in 2026

Over the years I saw some things in IT projects that could be improved or done better from a compliance / risk / best practices perspective. All those points could lead to bad project outcomes or bad consequences in the future. I will list them in no particular order & give a recommendation what should be done instead. In the face of the now passed Cyberbeveiligingswet (Cbw/NIS2) in the Netherlands (as well as almost every other EU country), and the upcoming Cyber Resilience Act (CRA), the following points are no longer just “IT best practices”, they are the critical controls that stakeholders who implement IT should pay attention to:

1. Production Data copied over to Non-Production environments without appropriate anonymization/consent. That is a classic GDPR violation as GDPR data is “purpose bound” (Art. 5(1)(b) GDPR) & the person did not give you date of birth, email and IBAN bank information so you can “test” your “Acceptance System” with more-realistic data (spoiler: just because data is in your system does not mean you “own” it. You are more likely then not “controlling” it:-). What should be done instead is putting an anonymization layer in-between using tools like NER (Named Entity Recognition) that nowadays, using AI, anonymize personal GDPR protected data.
2. Using Data of people in AI systems without consent. This is another classic GDPR violation (Art. 6 & Art. 22 GDPR) I see happening left and right. Problem here is that if you use people’s data for training in your DEV environment, you scan Outlook of your organization with an Agent for new incoming emails etc. you miss the consent of the people giving you their data. If you use data in AI systems, even without training them, you need consent. So advice here is to put a small checkbox on your contact form or something - so people who contact you are aware this is happening.
3. The misunderstanding that “I am in the cloud - so I do not need a backup”. Just be clear. Some cloud vendors have service offerings with very high SLAs like eight “9” or whatever. However, the bottom line is: Cloud is not a backup. If you have your whole user-management and critical data / processes in the public cloud it is recommended to get a regular backup from this information from time to time. Also a backup to another cloud provider is possible to mitigate the risk.
4. Over customization of low-code / no-code (LCNC) tools or using LCNC platforms for use-cases they are not built / intended for. If you use a LCNC platform and figure out that after some time you have hundreds of code extensions in the backend / frontend. Dozens of workloads in connected cloud environments there is a certain chance that you picked the wrong platform in the beginning and/or there was no proper ADD made by an architect when the project was set up. This bears a huge technical debt / overhead and eventual financial risk. LCNC should be used for simple to medium complex business use-cases. Over-customization creates Technical Rigidity. In a fast-moving markets, this technical debt prevents the organization from pivoting to new AI opportunities, turning a “Low-Code” asset into a legacy object that might slower business agility later on. Do not fall into the complexity-trap or “let me trade a massive developer tech team against a monthly license fee” marketing speech. This will not work out in most of the cases. Advice here is: Think beforehand and work with a good architect / partner who is as tech-agnostic as possible to get a good and honest ADD done.
5. Hidden licensing cost. Especially in LCNC projects the project often starts very cheap. If no proper ADD was done, no one looked in detail at the licenses needed. This can turn a cheap LCNC project into a 50k or 100k / year license trap. Advice is to study requirements license-wise carefully at the start & for at least one or two years (if possible) to give a rough estimation how much money needs to be budgeted & decide if this investment makes P&L wise sense for the organization.
6. Missing classification/awareness of high-risk/forbidden AI systems. Recently I saw a presentation where an architect wanted to use AI chatbots in an organization that helps people with sexual orientation and/or advice in this area. This is a classical Art. 6 AI Act. high-risk AI use case (which this architect was not even aware of). To avoid fines and massive reputational damage, always classify/judge/test & monitor (also after go-live) your AI systems - especially those who are public facing on your website.
7. Over-Sharing / Elevated permissions of Connectors. Very often I have seen that integrations run by default with “system administrator” roles or similar high level security roles. This can lead, and has led, to very bad outcomes and must be limited according to the “least privilege” principle. At least the organization/customer should be informed of the potential serious consequences and advised to act.
8. Some LCNC environments / products like the Power Platform have something which is called “default environment” which is an environment every user gets to play around. Those environments are/were often used for shadow IT and caused data-breaches in the past. Advice here is to ensure all environments are properly secured, for example starting with Data Loss Prevention policies (DLPs).
9. Lack of proper Application Lifecycle Management (ALM). If you do not have a proper deployment and ALM practice in place your project might run out of control quickly. So it is advised to have a clear & very strict DTAP (Development, Test, Acceptance & Prod - or leave Acc out if you wish) street in place and only making changes in Dev. This sounds trivial but I have seen dozens of times where organizations got into huge trouble because all DTAP environments were not synched and people made hundreds of changes directly in PROD.
10. Missing Logging & SIEM tools. Especially in highly regulated industries logging your IT activities is key. In a presentation in Denmark (which was about NIS2 compliance of Power Platform) I asked “If someone on a Friday night, mass deletes or mass downloads data in your production LCNC environment - can you detect, analyze and report this withing the 24h deadline NIS2 is giving you until Saturday evening?” Make sure that, if you are NIS2 affected (see Art. 23(4)(a) of NIS2), or also otherwise deal with high risk information/data that you can answer this question with a clear “yes”. Tools like Sentinel, Defender and others make it really easy to implement such mechanisms.

Modern IT projects often fail (or are over budget) not due to a lack of features, but because of a avoidance of fundamental governance and security “hygiene.” By treating data privacy as a “purpose-bound” commitment and strictly enforcing the principle of “least privilege”, organizations can avoid reputational damage of a preventable breach (see recent events in the Dutch communications market where a security incident revealed GDPR violations). Moving to the cloud or using LCNC does not take away responsibility from a project to be rigorous in terms of architecture, backup strategies, and lifecycle management. Success lies in shifting from a “build & ship fast” mentality to a “build responsibly and in accordance with design patterns / legal considerations and best practices” framework that anticipates the legal and technical debts and pricing structures of not only today but also tomorrow.

---

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.

Updated: 17.04.2026