Read the three EU laws reshaping European risk work — GDPR, NIS2, and DORA — and a pattern emerges beneath the legal language. Each one, in its own domain, asks an organization to do the same four things: understand its risks, put proportionate controls in place, report when something goes wrong, and be able to demonstrate all of the above to a regulator. That is not a new discipline. It is risk management with a legal deadline attached.
This article maps the three regimes onto the risk process you already run. It is an orientation, not legal advice — the exact obligations depend on your sector, size, and role, and those are questions for qualified counsel. But the strategic point holds regardless of the details: treating each regulation as a separate compliance project is how organizations end up with three parallel binders and no actual resilience. Treating them as inputs to one risk process is how you satisfy all three at once.
The three regimes, briefly
GDPR — the General Data Protection Regulation — has governed the processing of personal data across the EU since 2018. Its risk core is a duty to protect personal data with appropriate technical and organizational measures, to assess the risk of higher-risk processing before you do it, and to notify the supervisory authority of qualifying breaches quickly — generally within 72 hours of becoming aware. Its penalties are the ones everyone remembers: fines reaching into the tens of millions of euros or a percentage of global annual turnover, whichever is higher.
NIS2 — the second Network and Information Security Directive — extends EU-wide cybersecurity obligations to a much wider set of sectors than its predecessor, sorting organizations into "essential" and "important" entities. It requires appropriate cybersecurity risk-management measures, prompt incident reporting, and — the provision that changed the conversation in many boardrooms — explicit accountability of senior management for cybersecurity risk. Under NIS2, "the IT department handles it" is no longer a defensible answer.
DORA — the Digital Operational Resilience Act — applies to financial entities and their critical technology providers. It is the most detailed of the three, setting requirements for ICT risk management, incident reporting, regular resilience testing, and — distinctively — the active oversight of third-party technology dependencies, including the concentration risk of relying on a handful of large cloud and software providers.
Different sectors, different scopes, different regulators. But stand back and the shared skeleton is unmistakable: know your risks, control them proportionately, report incidents, and prove the whole thing works.
Why a compliance silo is the wrong response
The instinctive reaction to a new rule is to launch a project named after it. A NIS2 project, a DORA programme, a GDPR workstream — each with its own owner, its own spreadsheet, its own assessment, its own report. It feels orderly. It is, in practice, a trap.
Silos duplicate work, because the same underlying risks appear in all of them: a ransomware event is a cybersecurity risk under NIS2, a personal-data breach under GDPR, and an operational-resilience failure under DORA — one risk, wearing three compliance hats. Silos also fragment ownership, so the same control gets assessed three times by three teams against three checklists, and still nobody holds the complete picture. And silos are brittle: the next regulation arrives, and you start a fourth binder.
The alternative is integrated: one risk process into which each regulation feeds its specific requirements. The register holds the risks once; the laws become lenses and obligations layered on top, not parallel universes.
Folding regulation into the risk process
Here is how the mapping works in practice, step by step.
Identification gains a regulatory lens. When you identify risks, add the question each regime forces: Which of these risks involve personal data? Which threaten the availability of an essential service? Which are ICT risks that could break operational resilience? The same risk may raise its hand for several lenses, and that is exactly the point — you record it once and tag its regulatory relevance.
Assessment gains regulatory impact dimensions. Your impact scale already covers financial and operational consequences. Regulation simply adds dimensions that were always there: legal and regulatory exposure, and the specific consequence of a reportable breach. A data breach is not only a reputational and financial event; it is a notification obligation with a clock attached, and rating it that way keeps its true severity visible.
Treatment gains mandatory controls. The four treatment strategies are unchanged, but regulation removes "accept" from the menu for certain risks — some controls are not optional. NIS2 and DORA both expect specific measures (access control, incident response, testing, supplier oversight); GDPR expects protection proportionate to the risk of the processing. In your register, these appear as required controls with owners and deadlines, exactly like any other treatment — the difference is that "we chose not to" is not an available answer.
Monitoring gains reporting deadlines. Every one of these regimes has an incident-reporting clock. Your monitoring and review process is where those clocks live: an incident feedback loop that asks not only "was this risk in the register?" but "does this trigger a notification, and to whom, by when?" Rehearsing that question before an incident is the difference between a controlled 72 hours and a panicked one.
Documentation: the quiet common denominator
There is one requirement all three regimes share that deserves its own emphasis: you must be able to demonstrate compliance, not merely achieve it. A regulator does not accept "we manage our risks well" on trust. They ask for evidence — the risk assessments, the controls, the decisions, the dates, the history of who changed what and why.
This is the same evidence a well-kept risk register produces as a by-product of being used. The change history that makes an audit a filter click rather than an excavation is precisely what a regulator wants to see. Which means the single most valuable regulatory investment is often not a compliance tool at all, but a risk process disciplined enough to leave a trustworthy trail. An organization whose register records every rating, control, treatment, and change over time is most of the way to demonstrable compliance before the regulator ever calls.
The strategic takeaway
GDPR, NIS2, and DORA are not three problems. They are three views of one obligation: run a real risk process and keep the receipts. Organizations that internalize this stop chasing regulations one at a time and instead build a single register that answers all of them — tagged by regime where it matters, owned once, documented throughout. The next regulation, and there will be one, then becomes a new lens on an existing process rather than another binder on the shelf.
A tool that keeps your risks, controls, treatments, and full change history in one always-current place turns "prove it" from a fire drill into a report you can already produce; EasyRisk.io is built for that kind of demonstrable, documented risk work, and it is free to start. The regulation supplies the deadline. The risk process supplies the answer.
Frequently asked questions
Are GDPR, NIS2, and DORA the same thing? No — they are separate pieces of EU legislation with different scopes, and not even the same type of instrument: GDPR and DORA are regulations that apply directly across the EU, while NIS2 is a directive that each member state writes into its own national law. GDPR governs personal data across all sectors, NIS2 sets cybersecurity obligations for essential and important entities across many sectors, and DORA governs digital operational resilience for financial entities and their technology providers. What they share is a common structure: assess risk, apply proportionate controls, report incidents, and prove it.
Do I need separate compliance projects for each regulation? Usually not, and separate silos tend to duplicate work, because the same underlying risk often appears under several regimes at once. A more efficient approach is one integrated risk process into which each regulation feeds its specific obligations, so a risk is recorded once and tagged for the regimes it touches. Confirm the specifics for your sector with qualified counsel.
How does regulation fit into a normal risk process? As layers on the process you already run. Identification adds a regulatory lens (which risks involve personal data, essential services, or ICT resilience), assessment adds legal and reporting impact, treatment adds mandatory controls where "accept" is not permitted, and monitoring adds incident- reporting deadlines. The register then holds the evidence regulators ask for as a by-product of being kept current.
What is the reporting deadline for a data breach under GDPR? As a general rule, a qualifying personal-data breach must be reported to the relevant supervisory authority within 72 hours of becoming aware of it, with affected individuals notified where the risk to them is high. The exact triggers and thresholds depend on the circumstances, so the practical step is to rehearse the notification decision before an incident, not during one.