Between 2024 and 2026, Europe stacked more regulatory obligations onto organizations than most compliance teams can absorb. The AI Act phases in enforcement for high-risk systems starting February 2026, with full applicability by August. NIS 2 has been transposed (or should have been) into national law across member states. DORA – Digital Operational Resilience Act is already live for financial entities since January 2025. GDPR, meanwhile, keeps evolving through enforcement decisions and new guidance, especially around automated decision-making and large-scale profiling.
None of these regulations exist in isolation. They share overlapping requirements around risk management, documentation, incident reporting, and accountability. And yet many organizations still run separate compliance tracks for each one, burning through budgets and duplicating effort.
So what do compliance professionals need to know and be able to do right now? Below are the specific competencies that separate the people who can navigate this regulatory environment from the ones running to keep up.
Regulatory fluency across multiple frameworks
Knowing GDPR well is no longer enough. A compliance professional working in any mid-to-large European organization now needs working knowledge of at least three or four regulatory frameworks simultaneously.
Consider a company that processes personal data, uses AI-based fraud detection, operates in the financial sector, and relies on cloud infrastructure. That single company falls under GDPR, the AI Act, DORA, and NIS 2. Each regulation has its own risk classification system, its own reporting timelines, and its own supervisory authority.
Nobody memorizes every article in every regulation. What matters is understanding where they overlap and where they diverge. GDPR requires a Data Protection Impact Assessment. The AI Act requires a Fundamental Rights Impact Assessment for high-risk AI systems used by public bodies. NIS 2 requires cybersecurity risk assessments. DORA requires ICT risk management frameworks. A compliance professional who treats these as four separate exercises will spend months producing redundant documentation. One who maps the commonalities can build a single integrated assessment process that satisfies multiple requirements with far less effort.
ISO 27001 certified organizations already have an advantage here. The management system structure, the risk-based approach, the emphasis on documented processes and continuous improvement: these translate directly to NIS 2 and DORA requirements. Organizations with ISO 27001 certification can reportedly achieve ISO 42001 (the AI management system standard published in 2023) up to 40% faster than those starting from scratch. That efficiency carries over to regulatory compliance as well.
Technical literacy, not technical mastery
Compliance professionals do not need to write code. But they do need to understand what happens inside the systems they are responsible for governing.
When an organization deploys an AI system that processes personal data for credit scoring, the compliance officer needs to understand what training data was used, how the model makes decisions, whether those decisions can be explained to the data subject, and what bias testing was conducted. This is not optional under the AI Act. High-risk AI systems require transparency obligations, human oversight mechanisms, and technical documentation that describes how the system was designed, developed, and validated.
The same applies to cybersecurity. NIS 2 and DORA both require organizations to implement technical and organizational measures for risk management. If the compliance officer cannot have a meaningful conversation with the CISO about network segmentation, access controls, encryption standards, or vulnerability management, the compliance function becomes a checkbox exercise disconnected from actual security posture.
Nobody expects compliance officers to become engineers. But you should be able to read a technical risk assessment and spot what is missing, know enough about machine learning to ask whether the training data was representative, and tell the difference between pseudonymization and anonymization well enough to assess whether a processing activity falls under GDPR at all.
ENISA’s implementation guidance for NIS 2 suggests a team structure that includes a CISO, a cybersecurity implementer (typically a system administrator with incident response skills), and a cyber legal, policy, and compliance officer. That last role requires someone who sits comfortably at the boundary between legal requirements and technical reality.
Risk assessment as a practical discipline
Risk assessment shows up in every single one of these regulations. But doing it well is harder than following a template.
GDPR requires risk-based approaches to data processing. The AI Act classifies AI systems into risk levels (unacceptable, high, limited, minimal) and ties compliance obligations to those classifications. NIS 2 requires cybersecurity risk assessments covering supply chain risks, business continuity, and incident handling. DORA requires ICT risk management that accounts for third-party service providers.
Where most people get stuck is translating abstract risk categories into concrete organizational decisions. There is a difference between writing „this is a high risk” and writing „this processing activity involves health data of 50,000 patients, processed by an AI system whose decision logic we cannot fully audit, hosted on infrastructure managed by a third-party provider who has not completed their NIS 2 compliance”. The second version moves the conversation forward. The first one just fills a spreadsheet.
Good risk assessment also means knowing when something is genuinely low risk and saying so. Over-classification wastes resources and creates compliance fatigue. If every processing activity is flagged as high risk, the organization stops taking risk assessments seriously.
Cross-functional communication
ENISA’s NIS 2 guidance makes it explicit: compliance cannot happen inside a silo. The compliance officer needs to work with IT, legal, risk management, procurement, and senior management. DORA takes this further by requiring that the management body itself has sufficient knowledge and skills to understand ICT risks.
In practice, this means the compliance professional needs to communicate in at least three registers. With the board, the conversation is about liability, financial exposure, and strategic risk. With IT and security teams, it is about specific technical controls and their effectiveness. With operational teams, it is about workflows, data flows, and practical implementation.
The AI Act introduces another layer. Organizations deploying high-risk AI systems need to ensure that people overseeing those systems understand their capabilities and limitations. The compliance function may need to coordinate training programs that bridge the gap between the development team that built the model and the business team that uses it.
This is also where the DPO role is expanding. The 2025 survey on AI and the DPO profession highlights that traditional skills (conducting impact assessments, mapping processing activities, running awareness programs) must now be combined with understanding AI technologies and their ethical implications. The DPO who only talks to legal is becoming obsolete. The one who can sit in a room with data scientists, security engineers, and business managers and facilitate a productive conversation about risk is the one organizations actually need.
Incident response and reporting
The reporting timelines alone demand a level of preparedness that many organizations have not achieved.
NIS 2 requires significant incidents to be reported to the national CSIRT within 24 hours of becoming aware of them, with a full incident notification within 72 hours. GDPR requires personal data breach notification to the supervisory authority within 72 hours. DORA requires major ICT-related incidents to be reported to the competent authority, with an initial notification, intermediate report, and final report. The AI Act requires providers of high-risk AI systems to report serious incidents.
The compliance professional needs to have pre-built processes for each of these. That means knowing exactly who determines whether an incident is „significant” under NIS 2 versus a „personal data breach” under GDPR versus a „major ICT-related incident” under DORA. A single security incident could trigger reporting obligations under all three.
What separates prepared organizations from panicking ones is tabletop exercises that test these processes before a real incident happens. Not a generic „what if we get hacked” scenario, but specific simulations: a ransomware attack that encrypts a database containing personal data, hosted by a third-party cloud provider, used by a high-risk AI system. Walk through the classification, the notifications, the timelines, the documentation. Find the gaps before the regulators do.
Vendor and supply chain oversight
Both NIS 2 and DORA put significant emphasis on supply chain risk. Organizations are responsible not just for their own compliance, but for ensuring their third-party providers meet certain standards.
DORA requires financial entities to maintain a register of all ICT third-party service providers, conduct risk assessments of those providers, and include specific contractual clauses related to security, audit rights, and exit strategies. NIS 2 requires essential and important entities to address supply chain security in their risk management measures.
From a GDPR perspective, this means the Data Processing Agreement is just the starting point. The compliance professional needs to assess whether the processor actually implements the technical and organizational measures described in the agreement. When that processor also provides ICT services to a financial entity, DORA requirements come into play. When the processor’s infrastructure is classified as important under NIS 2, that adds another layer.
The way out is building a vendor assessment process that covers multiple regulatory requirements in a single review: one questionnaire, one audit framework, multiple compliance objectives. Procurement teams resist adding compliance checks. The only way to get them on board is to make those checks fast and specific enough that they do not hold up every contract.
Documentation that works
Every regulation requires documentation. DPIAs, records of processing activities, risk assessments, policies, procedures, audit trails. The volume can become unmanageable.
The difference between compliance that works and compliance that exists only on paper is whether the documentation reflects reality. A 200-page information security policy that nobody has read does not make the organization more secure. A concise, specific policy that maps to actual technical controls and is reviewed quarterly does.
ISO 27001 practitioners understand this well. The standard requires documented information, but it also requires that the management system is actually effective. The same principle applies to GDPR accountability, AI Act technical documentation requirements, and NIS 2 risk management measures.
Good documentation serves two purposes at once: it satisfies the regulator and it is useful to the people who need to follow it. An incident response plan so complex that nobody can execute it during a real incident has failed, no matter how thorough it looks on paper.
Where this leaves the profession
The compliance professional of 2026 needs to be comfortable wearing several hats: legal analysis, technical conversations, project coordination, and acting as translator between departments that otherwise would not talk to each other. GDPR started this shift. The AI Act, NIS 2, and DORA have accelerated it.
Certifications still matter. CIPP/E and CIPM from IAPP remain relevant for privacy. ISO 27001 Lead Auditor is the baseline for information security. ISO 42001 is becoming necessary for AI governance. But a certification proves you studied something, not that you can apply it under pressure. The real test is whether someone can walk into an organization that falls under four overlapping regulatory frameworks and build a program that holds together without becoming a bureaucratic exercise.
Regulations exist to protect people. Compliance exists to make that protection operational. Keeping both of those facts in view, at the same time, is harder than it sounds.
