AI, Data Protection & Cybersecurity - A triangle legislation overview of AI Act, GDPR & NIS2. Replace Regulatory Fear with a clear process forward!
How the EU AI Act, GDPR and NIS2 overlap in every IT project, and a unified process for risk management, incident reporting and privacy by design instead of regulatory fear.
Table of Contents
Introduction: Why caring about individual laws in the EU might be a bit risky?
I noticed a trend over the last let’s say 2-3 years… When being faced with new EU regulations architects, organizations, developers and more broadly stakeholders get into panic mode! “We now need to comply with NIS2 for IT security, are we compliant??” … “What if we get fined??” … “But wait,.. do we handle our data GDPR conform?”. While trying to comply to EU regulations is in itself not bad of course…, this fragmented approach more often than not leads to the fact that “everything is tried a bit but nothing is done 100% correctly”. In the end the organization often has nothing as focus, budgets and other priorities come into the way - you know the “lets implement private endpoint after go live - we have no time for that now” kind of situations we are all aware of. So: first calm down & then ask yourself: How do you concretely ensure that your customer is not violating NIS2 or GDPR? Technology gets more and more complex, and bundling this with all those laws in mind is tricky - to say the least. Therefore I wanted to combine the three most essential EU legislations into one single big article and explain how you can move from “shooting on a moving duck” to a holistic approach that keeps you covered for the most part. This will of course be a bit of a more comprehensive article, but trust me it might be worthwhile reading on. However, I have to make compromises here and there and leave out some essential legislation’s like the updated “Product Liability Directive” (PLD) which basically could make you financially liable for implementation mistakes inside your IT project (see here for more information), the Data Act, CRA for secure products by default and some other. This is needed, as otherwise this LinkedIn Article would take 200 pages & would take waaaaay too much time to write/correct/revise and publish. So, instead of “shooting” on each legislation I recommend an integrated a fully holistic approach that should cover the absolute basics for your IT project. In doing so you reduce the operational risk from a security (NIS2), data (GDPR) and AI (AI Act) perspective. But first we need to understand why this is so hard to do, why it’s so often forgotten or even ignored by people in charge of implementing an IT projects as lead consultants/architects & how you can improve your IT projects foundation?
Compliance & Security: Why “we do that later” is the most expensive mistake in your architecture!
Let’s face the elephant in the room here directly. The EU released soooo many regulations in recent years that it gets harder, and harder and harder to design compliant IT systems. And the complexity is just rising. If I hear IT architects telling me they are annoyed by all those regulations and quote things like “I am a programmer and not a lawyer”. I understand this totally! Man I hear you guys, and I agree: It is not the most pleasant work by any stretch of imagination. In fact it’s intimating, stressful, boring, fearful and can be super annoying to work with legislation. I will not sugarcoat this here! But in the end, we have to design systems that are not only modern, scalable but also secure & compliant by default, which is you guessed it… a legal requirement! From my perspective it’s not a question of interest to skill-up in this area or “a passion for legislation”, but rather an absolute necessity as we otherwise implement IT projects that could be legally non-compliant and potentially insecure. In this process of compliance improvement one challenge is the “way of working/thinking” of large parts of the IT industry over the last 30 to 40 years. A common way of working I observed over the years is the following process (in all forms and variations of it) in a very simplified manner:
Standard Process of IT projects
The result is not always, but often enough, a project execution that does not address security and compliance requirements from the get go! And this is a problem. This can lead to non-compliant and non-secure IT projects - and therefore to fines, increases chances of data breaches and hacks and ultimately endangers the reputation for all stakeholders involved. I heard sentences like “Let’s skip security”, “We implement security later” or more recently “Can we just use production data to train this AI model in Dev?” over the years way too often… The problem is: If security and compliance is not taken care of from the beginning, the fundament of the whole IT implementation is already shaky and, same as building a house, fixing a fundament once the construction is in progress is a challenge - to say the least. Often it’s just not done at all and/or forgotten in hectic sign-off periods and tighter budgets. In following such a process because either sales pressure is too high, or implementation speed is more important than quality, IT projects are implemented that are in a nutshell: Legacy money graves and/or non-compliance cases of tomorrow, either for your own organization or for your customer. This can be fixed of course, when applying a step by step process - a phased approach so to say.
Improved process for IT projects
I am not arguing this process is easy to implement. In fact it is not. However, for architects who plan to work correctly, and not rely on “the vendor will make the software/tool secure”. This process provides a solid starting point for an ADD which is based on processes, compliance, design patterns and ultimately security from the very start. This is a solid foundation for everything that follows after that. Now, that we know how to avoid compliance mistakes in the first place let’s move to the actual three legislations that are shaping current EU based IT projects in a significant way.
So in a nutshell: It is either upskill or fail. Working secure and compliant by default will be of increased importance, especially with the speed of AI advancements that pose new security challenges. So the timeframe the process (see first diagram) of traditional IT projects worked without fines and loss of reputation, literally hoping “nothing will happen”, for organizations is closing.. faster and faster … we see this daily/weekly in the news when a new IT security breach is made public. One last sidenote: Even if your customer agreed and approved a non-compliant / insecure implementation an IT implementation partner is (very likely) still legally liable due to the updated Product Liability Directive (https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng). The old trick “the customer approved this” is not working anymore for IT implementation companies … But anyways…, this is a bit off-topic of this article so let’s jump into Data, Security and AI!
The compliance trio: More than paradigms and laws but rather the solid regulatory foundation of everything that follows
If we start a project in IT we have some basic pillars we need to think about. In the end many things come down to: Data, Security and nowadays AI. Those three pillars are essential for most IT projects that are happening right now, and in the foreseeable future.
-
We have to understand the data we have. What kind of data? Who owns the data? (spoiler alert: sometimes you do not own the data), what am I allowed to do with the data? Where is the data stored physically and who has access under which conditions? … and many, many, many more questions.
-
Security should be the core every business today. Recent cyber attacks have shown one fact very clear: One IT security problem can bring your business down. To be clear here: I mean shut down of the business, dito, finito … So having a strong IT security is essential and the base of everything else! If we have our data layer done, we need to put IT security on top and make it secure.
-
AI is more and more taking a more prominent role in todays IT projects. We see all kinds of statements, promises and more about AI. However, AI is in the EU regulated and “just implementing an AI solution” can bring you in trouble, both from a customer but also from an implementation partner perspective, … the “Product Liability Directive” is again smiling at you. So we need to take AI, Security and Data seriously - all at the same time!
The three legislations that should serve as an Absolut foundation in every IT project are the infamous GDPR (eur-lex), NIS2 Directive (eur-lex) and the EU AI Act (eur-lex). It has to be said that NIS2 is only binding for a certain number of organizations. There is a likelihood that you do not need to follow this legislation. However, NIS2 offers a lot of useful IT security improvements that you take into consideration.
Overlap Matrix: Where regulations meet
The key question is: How can I be compliant with all three while not getting into panic mode?! In my opinion a good approach is to combine requirements of all three legislations into focus areas that - most likely - you already have inside your organization. Do not treat compliance as “being compliant with legislation A and legislation B”. Ideally it should be seen as an overall improvement of delivery quality in your IT project rather than a “regulatory burden”. So it’s also connected to a mindset shift away from “How can I implement this requirement” to “Should I implement this requirement & am I doing the correct thing here”. I have tried to consolidate the key areas of the respective regulations into a matrix and then will try to explain the concrete requirements behind.
Legal Requirements of AI Act, NIS2 and GDPR across all areas
You can see that the three legislations in question do overlap at some parts. Important to notice is however that a term like “risk” is seen from a different angle in each of the regulation. To give an example we can look at risk assessment in form of a DPIA which is mandatory in many GPDR scenarios compared to risk management in a NIS2 sense. In the GDPR case its a rather abstract assessment “what happens to people data” while in NIS2 its a more concrete technical risk management system (RMS) which in an extreme case should avoid the company collapses from an IT standpoint - so very concrete. Nevertheless if you want to get a better compliance posture you should aim to solidify all your risk related topics under a central risk umbrella and then differentiate for what concrete use case which measurement is needed. In working this way you ensure that “risk”, be it a bit more abstract or concrete, is managed at a central place by people and systems that are specialized on that. Lets sum those things up for each of those categories:
- Unified Risk Management: When you implement / update a risk management system (RMS) in your organization you should strive for a unified approach to cover at least the three legislations (if you are NIS2 affected ofc - but otherwise its a good practice to do so anyways) “by design”. So, whenever a new feature, tool or something else changes your application landscape this RMS must check for risks for “rights” or “concrete IT risks” as demanded by Art. 35 of the GDPR directive (Data protection impact assessment - DPIA), Art. 9 of the AI Act (Risk Management) / Art. 6 & ANNEX III of the AI Act for Risk Classifications and Art. 21 of the NIS2 directive which demands “Cybersecurity risk-management measures”. So, instead of checking each law for specific use-cases, the RMS must by default check every new component in the IT-landscape against all three laws. In doing so you avoid that something gets forgotten or overlooked. This is of-course high level, but the emphasis is to just check everything by default - so nothing gets overlooked and there will be no one in panic mode, because it all gets checked by default.
- Central Incident Reporting & Automated actions: To be fair, regulations regarding incident reporting is very difficult with EU legislations! I agree to all the people complaining about this. Every legislation demands a different incident response time for different times of incidents under different circumstances. Creating a system that takes care of all those cases the intersection between those, for example an incident that is NIS2 and GDPR relevant, seems to be practically very hard. (I am not the one who would like to write all those KQL Queries in Sentinel). The premise for a unified and manageable system would be to lay the incident response times over each other. GDPR for example demands reporting of data breaches within 72h (Art. 33(1) GDPR) while NIS2 demands the early warning within 24h (Art. 23(4)(a)) or 72h (Art. 23(4)(b))… and the AI Act is as usual a bit vague in terms of incident reporting. The recommended way of working here is to construct your system to the lowest possible incident response time and then do a manual review by an expert what sort of incident happened and how the respective national authorities must be notified and by whom. So you can set up an internal triage deadline of 24h for every incident to give your legal team enough time to evaluate. This seems to be a practical approach which, of course, assumes that you do not have hundreds of incidents per month that you need to report. If this is the case, you should stop reading here and fix more urgent issues in your organization
- IT Security & Privacy by Design: IT Security is a delicate topic. If you want to combine your IT Security Management to adhere with NIS2, GDPR and the AI Act a good practice is to just apply the best security measures available at the moment. GDPR Art. 25 for example demands Data protection by design and by default, while NIS2 requires you to have State-of-the-Art security measures like encryption and MFA (Art. 21(2)) and the AI Act demands IT Security as well with Art. 15 (Accuracy, robustness and cybersecurity). So the best approach I think is to get your IT security up to date and not wait further. This means: Apply Zero Trust principles across your organization, ensure proper logging and incident reporting (see above), make sure data is encrypted in transit and at rest (which is often forgotten) and so on and so forth… For more information you should speak to an IT security expert. When taking those things into account, trying to unify across legislations most organizations would profit massively. Here I mean especially mid-sized companies - until lets say 50 to 1000 mio. in revenue, as big corporations over 2, 3 or more billion USD in revenue very often have the things described above implemented due to legal pressure - by example the stock exchange they are listed on and so on.
- Governance & Management Responsibility: If you are NIS2 affected a key change in responsibility arose compared to previous regulations. In the past I heard the sentence “IT security is duty of IT department”. With the NIS2 regulation the C-Level, most prominently the CEO, is directly responsible for IT security. NIS2 Art. 20 (Governance) lays out this fundamental change. A CEO can be made personally liable, or in most cases the organization will bring its own CEO to court if he misses to address key IT security objectives like: Neglecting Training Requirements (Art. 20(2), Essential reporting deadlines, failure to approve risk management measures if proposed to do so and a couple of more … This is not meant to spread fear & it will be seen how courts in the EU will assess concrete cases of CEO failures but the roadmap is clear. The old “IT security is a job of IT” is over. So, it is highly advised to any NIS2 affected organisation’s to actively involve the C-Level and take them on their responsibility across all three legislations to ensure they know what is going on, where potential risk lay and so on. This should happen in close coordination with the CISO and CIO of course.
Problems of typical IT Projects
As I said above, the most expensive mistake an organization can make is not starting with security or going along with we skip security for now. This will sooner or later lead to bad effects or the end of the organization. That is why the improved process (see above) is so important. If you do not “bake” security and compliance into your fundament you will have a very hard time doing it later. In your IT projects avoid to shoot at moving ducks. This I see often, but taking a step back, invest a week or two more into the requirements phase of the project is often well spend time/money. A new IT project, especially if implemented at enterprise scale, should try to avoid the typical Im a coder not a lawyer mindset so many tech people still have. Architects often focus on the “how to do something” and not on the “should I do this at all” question. If you work in a big enterprise IT project during the requirements engineering phase, and all you hear from lead architects is “what is this requirement and how can we implement this” and never “I am not sure we should do this / lets discuss with legal” then there is a chance that this project goes already into the wrong direction. Good architects should of course not be legal experts, but develop a sense for the moment a technical decision gets (legally) “too spicy” to just implement - this is often enough to separate a non-compliant from a compliant IT implementation . Last point here that I want to point out is a trivial one: Reading the documentation. I know, and I am guilty of this myself not only one or two times, but we tech people tend to not read documentation. It is what it is. We spend 5h to solve a problem that we could have solved in 10 min (I have fallen into this trap min. 20x times myself). If we would have just read the documentation. Is this silly? Yes. Do we do it all the time? Also, yes. So, coming from a Microsoft stack I can highly recommend reading the docs (in my case Microsoft learn) of your software stack. Very often, at least for Microsoft this is the 100% case (a compliment for sure to make to the good Microsoft Learn team), the vendor has excellent documentation on compliance, security, legal topics etc. Reading those docs helps with I would say already 80% of open points in a project and then 20% is execution and talking to legal.
Wrap-Up: Upscale or loss of reputation?
So, if you made it that far with reading, … first of all congratulations. Secondly, I hope this one did at least made you think about your next project, implementation, meeting … I know that legal / compliance / governance are really not the most sexy topics, maybe even the least sexy topics for an IT person. However, the regulatory landscape is changing. It is what it is, we have to adopt to that and need to avoid “just reading emails from our customers exchange inbox without GPDR approval”
What I would recommend is a slow process of upskilling. I would not recommend overload IT experts with legal articles, legislations etc. A slow process of first making people aware of the problematic points, education, seeing things as an opportunity to become better and deliver “better” IT projects works far better than the big “compliance hammer”.
In seeing those three legislations as one unified requirement we can make sure that from the ground up our projects are: secure, compliant and technically sound. A solid foundation is always better than a shaky one we later try to fix because “some IT auditor found a flaw in our incident response”. In working like this we create better projcts and protect our personal and professional reputation.
Good Luck!
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.
(Slightly improved and updated: April 14th, 2026)