Why European organisations should stop treating cybersecurity, AI governance and data protection as separate compliance programmes
European organisations are entering a new phase of digital regulation.
For years, cybersecurity, data protection and artificial intelligence were often managed by different teams, with different methodologies and different reporting lines. Cybersecurity belonged to the CISO. Personal data belonged to the DPO. Artificial intelligence was largely considered an innovation or IT topic.
That model is becoming increasingly difficult to sustain.
NIS2, the EU AI Act and the GDPR have different purposes and different legal scopes. Yet when translated into operational requirements, they increasingly converge around the same concepts: risk management, accountability, governance, security, documentation, incident management and evidence.
The result is a paradox.
Europe has created several distinct regulatory frameworks, but organisations should probably not create a separate governance system for each of them.
The challenge is therefore no longer simply:
How do we comply with NIS2?
or:
How do we comply with the AI Act?
The more strategic question is:
How do we build one coherent governance model capable of addressing cyber risk, AI risk and data protection simultaneously?
1. NIS2: protecting the resilience of organisations
The primary objective of NIS2 is cybersecurity and operational resilience.
The Directive applies to a broad range of essential and important entities operating in sectors that are critical to European society and the economy. Its scope includes areas such as energy, transport, health, drinking water, digital infrastructure, cloud services, managed services and public administration.
NIS2 fundamentally asks organisations to answer a simple question:
Can you continue to provide your services securely when something goes wrong?
This requires organisations to identify cyber risks, implement appropriate technical and organisational measures, manage vulnerabilities and suppliers, prepare for incidents and report significant cybersecurity incidents.
NIS2 also brings cybersecurity directly into the boardroom. The European Commission explicitly highlights the accountability of top management for compliance with cybersecurity risk-management measures.
This is a significant evolution.
Cybersecurity is no longer simply an operational problem delegated to IT teams. It becomes an organisational governance responsibility.
Incident management illustrates this clearly. NIS2 introduces a multi-stage reporting mechanism, including an early warning within 24 hours and an incident notification within 72 hours for significant incidents.
NIS2 is therefore fundamentally concerned with:
- cybersecurity risk management;
- operational resilience;
- incident detection and response;
- supply-chain security;
- vulnerability management;
- management accountability;
- supervision and evidence of compliance.
Its central object is the security and resilience of organisations, networks, systems and services.
2. The AI Act: ensuring that AI can be trusted
The AI Act starts from a different problem.
Its primary objective is not the resilience of the organisation. It is the trustworthiness of artificial intelligence systems placed on or used within the European market.
The regulation takes a risk-based approach. Certain uses are prohibited, many systems remain subject to limited requirements, while high-risk AI systems are subject to considerably stronger obligations.
For high-risk AI systems, providers may need to establish mechanisms covering:
- risk management;
- data and dataset governance;
- documentation;
- logging and traceability;
- transparency;
- human oversight;
- accuracy;
- robustness;
- cybersecurity;
- quality management;
- conformity assessment.
The presence of cybersecurity in this list is important.
Article 15 of the AI Act explicitly requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity throughout their lifecycle.
This means that cybersecurity is no longer simply the environment surrounding an AI application.
It becomes part of the regulatory assessment of the AI system itself.
An AI model that is vulnerable to manipulation, data poisoning, adversarial attacks, unauthorised access or integrity failures may therefore create both a cybersecurity problem and an AI compliance problem.
The AI Act also introduces specific responsibilities for deployers of high-risk AI systems. They may be required to monitor system operation, organise human oversight and respond appropriately when risks or serious incidents are identified.
The AI Act therefore looks at risks that traditional cybersecurity frameworks do not necessarily capture adequately: biased outputs, unsafe automated decisions, inappropriate reliance on AI, insufficient transparency, inadequate human control or failures affecting fundamental rights.
Its central object is the trustworthy development and use of artificial intelligence.
3. Different objectives — but increasingly similar controls
NIS2 and the AI Act were created for different purposes.
NIS2 asks:
How resilient is the organisation against cyber threats?
The AI Act asks:
Can this AI system be developed and used safely, lawfully and responsibly?
Yet operationally, the two frameworks repeatedly arrive at similar governance mechanisms.
Consider risk management.
NIS2 expects organisations to identify and manage cybersecurity risks.
The AI Act requires structured risk management for high-risk AI systems.
Consider incidents.
NIS2 requires detection, handling and notification of significant cybersecurity incidents.
The AI Act establishes mechanisms for monitoring and reporting serious incidents involving high-risk AI systems.
Consider suppliers.
NIS2 explicitly places considerable emphasis on supply-chain cybersecurity.
But modern AI systems also depend on extensive supply chains: foundation models, APIs, cloud platforms, external datasets, open-source libraries and specialised service providers.
Consider documentation.
NIS2 compliance requires organisations to demonstrate that cybersecurity controls and governance arrangements actually exist.
The AI Act likewise relies heavily on documentation, logging and traceability.
And consider governance.
Both regulations ultimately require somebody inside the organisation to know:
Who owns the risk? Who made the decision? Who monitors it? Who reacts when something goes wrong?
This is why organisations that create completely separate NIS2 and AI Act programmes risk duplicating much of the same work.
4. Why does this regulatory redundancy exist?
The overlap is not necessarily a legislative mistake.
It largely reflects the fact that the regulations look at different layers of the same digital ecosystem.
NIS2 approaches digital risk from the perspective of organisational resilience.
The AI Act approaches it from the perspective of AI systems, products and their impact.
The GDPR approaches it from the perspective of individuals and their personal data.
Imagine an AI-powered recruitment platform.
A cyberattack compromising the platform may fall within an organisation’s cybersecurity risk-management framework.
The AI system itself may be subject to AI Act obligations because employment-related AI can fall within the high-risk categories.
If candidates’ personal information is processed, GDPR requirements apply simultaneously.
One technological system can therefore create:
cyber risk + AI risk + personal-data risk.
Creating three completely independent risk registers for that same system would be possible.
It might not be particularly intelligent.
5. Where NIS2 and the AI Act complement each other
Their complementarity becomes particularly obvious when we consider the lifecycle of an AI system.
NIS2 helps protect the environment in which AI operates.
It addresses infrastructure, networks, access controls, vulnerability management, incident response, business continuity and supplier security.
The AI Act focuses more deeply on the behaviour and characteristics of the AI system itself.
It addresses issues such as data quality, model robustness, transparency, human oversight and the risks associated with decisions generated or supported by AI.
Neither perspective is sufficient alone.
A perfectly governed AI model running inside an insecure infrastructure is not trustworthy.
Equally, an extremely secure infrastructure running an opaque, discriminatory or uncontrolled AI system is not trustworthy either.
This is why cybersecurity and AI governance are beginning to converge.
AI security cannot simply be delegated to the traditional cybersecurity programme.
And AI governance cannot ignore cybersecurity.
6. Then comes the GDPR
The relationship becomes even more interesting once personal data enters the equation.
The GDPR predates the current generative-AI boom, but it remains fully applicable whenever personal data is processed during the lifecycle of an AI system.
The European Data Protection Board has been explicit on this point: the AI Act and EU data-protection legislation should be considered complementary and mutually reinforcing, and data-protection law continues to apply to personal-data processing involving AI systems.
This creates another layer of governance.
The GDPR asks questions such as:
- What personal data are being processed?
- What is the legal basis?
- Is the processing necessary and proportionate?
- Have individuals been properly informed?
- Are data minimisation principles respected?
- How long are the data retained?
- Can individuals exercise their rights?
- Is a Data Protection Impact Assessment required?
- Are adequate security measures implemented?
These questions do not disappear simply because an AI system complies with the AI Act.
The EDPB has also examined particularly difficult questions concerning AI models, including when a model can genuinely be considered anonymous, when legitimate interest may constitute an appropriate legal basis and what happens when personal data used to develop a model were processed unlawfully.
This has an important practical consequence:
AI Act compliance does not imply GDPR compliance.
Nor does GDPR compliance imply AI Act compliance.
The regulations must coexist.
7. AI impact assessments illustrate the convergence
Impact assessment is a particularly revealing example.
Certain organisations deploying high-risk AI systems may have to perform a Fundamental Rights Impact Assessment under the AI Act.
At the same time, processing personal data may require a Data Protection Impact Assessment under the GDPR.
The European Commission explicitly recognises this potential overlap and indicates that, where both are required, the fundamental-rights assessment should be conducted in conjunction with the data-protection impact assessment.
That is an important regulatory signal.
The European legislator itself recognises that duplicated assessments do not necessarily create better governance.
The same principle should inspire organisations more broadly.
8. One risk, three regulatory perspectives
Consider a company deploying an AI assistant capable of accessing internal documents and performing actions on behalf of employees.
From a NIS2 perspective, relevant questions include:
Can the system be compromised? What access rights does it receive? What happens if a supplier is attacked? How is an incident detected? How does the organisation recover?
From an AI Act perspective, the questions may include:
What type of AI system is this? What risks arise from its intended use? Is human oversight sufficient? Is the system robust? Are its actions traceable?
From a GDPR perspective, the questions include:
What personal data can the assistant access? Is that processing lawful? Is access proportionate? Can individuals exercise their rights? Are prompts, outputs or logs retained?
It is the same AI assistant.
The regulations simply observe it from different angles.
That is why organisations need an integrated view of digital risk.
9. The danger of three separate compliance programmes
A siloed approach creates predictable problems.
The cybersecurity team maintains one asset inventory.
The privacy team maintains another record of processing activities.
The AI governance team creates an AI inventory.
Procurement performs supplier assessments independently.
Compliance creates another risk register.
Internal audit requests another set of evidence.
Eventually, the same application appears five times in five different governance tools with five different owners and sometimes five different risk ratings.
That is not stronger governance.
It is compliance fragmentation.
It increases administrative work while potentially making actual risk harder to understand.
10. Towards integrated digital-risk governance
The alternative is not to merge all regulations into one checklist.
Their legal differences matter and must remain visible.
Instead, organisations should create a common governance foundation and map regulatory requirements onto it.
A mature model could contain common capabilities such as:
One digital asset inventory.
Systems, AI models, datasets, suppliers and processing activities should be connected rather than maintained as unrelated inventories.
One risk taxonomy.
Cybersecurity, privacy, AI and operational risks can remain distinct categories while sharing a common methodology for ownership, assessment and escalation.
One governance structure.
CISO, DPO, legal, AI governance, risk management and business owners should not discover each other’s decisions after deployment.
One supplier-governance process.
An AI supplier can simultaneously create cybersecurity, data-protection and AI-governance risks.
One evidence architecture.
Policies, controls, logs, risk assessments, testing and audit evidence should be reusable wherever regulations require equivalent proof.
Integrated incident management.
An AI incident may simultaneously constitute a security incident, personal-data breach and AI-related serious incident. Organisations need escalation mechanisms capable of recognising all three.
11. Redundancy can actually become an advantage
There is another way to look at regulatory overlap.
If several European regulations repeatedly ask organisations to implement governance, risk management, documentation, security and accountability, perhaps the answer is not to complain about duplication.
Perhaps it is to build those capabilities properly once.
A strong security-management process created for NIS2 can support AI Act compliance.
A mature GDPR data-governance programme can support AI dataset governance.
Existing supplier-risk processes can incorporate AI-specific questions.
Incident-management procedures can incorporate AI-related escalation criteria.
Internal audit can evaluate integrated controls rather than isolated regulatory checklists.
In other words:
regulatory redundancy can become operational reuse.
That is where compliance begins to become governance.
Conclusion: three laws, one digital organisation
NIS2, the AI Act and the GDPR are not interchangeable.
Their objectives are different.
Their scopes are different.
Their competent authorities can be different.
Their terminology is different.
And compliance with one does not automatically establish compliance with another.
But organisations should resist the temptation to transform these legal differences into organisational silos.
NIS2 protects the resilience of digital organisations.
The AI Act seeks to ensure that artificial intelligence is trustworthy, safe and compatible with fundamental rights.
The GDPR protects individuals when their personal data are processed.
Modern digital systems increasingly sit at the intersection of all three.
The organisations that manage them most effectively will therefore not ask:
“Which compliance programme owns this system?”
They will ask:
“What are the risks created by this system, who owns those risks, and which regulatory obligations apply?”
That is a subtle but fundamental change.
NIS2, the AI Act and the GDPR are three layers of the same trust stack.
The real challenge for European organisations is no longer complying with each one separately.
It is learning how to govern them together.
