NIS2 and DORA: What European Cyber Regulation Means for Your Stack

NIS2 and DORA are the two European regulations that have most changed how engineering teams talk about security over the last couple of years, and they get confused with each other constantly, which is understandable — both emerged from the same EU push to raise baseline cyber resilience across critical sectors, both put concrete accountability on management rather than letting security stay a purely technical function, and both introduce incident reporting obligations with short clocks. But they cover different scopes, and conflating them leads teams to either over-apply DORA’s financial-sector-specific requirements everywhere, or under-estimate how broadly NIS2’s “important entity” category reaches outside the obviously regulated industries.

This is not legal advice, and if your organization is in scope for either regulation you need actual counsel and a compliance program, not a blog post. What follows is a practical, engineering-facing map of what each directive is about, how they differ, and — the useful part for anyone reading a security site — a checklist of technical controls that map cleanly onto the obligations either one describes, regardless of whether you’re formally in scope. Good security hygiene doesn’t need a regulatory trigger to be worth doing.

NIS2: Broadening Who Counts as Critical

NIS2 (the second Network and Information Security Directive) is the EU’s update to its baseline cybersecurity framework, and its most consequential change from the original NIS directive is scope: it pulls a much wider set of sectors and company sizes into regulated territory. Where the original directive focused narrowly on a handful of critical infrastructure operators, NIS2 organizes covered organizations into two tiers — generally described as “essential” and “important” entities — spanning sectors like energy, transport, banking, health, digital infrastructure, public administration, and, notably, digital service providers and managed service providers that many smaller companies rely on without necessarily realizing those providers are themselves in scope.

The practical effect for a mid-sized software company: you may fall into NIS2 scope not because your own sector is obviously “critical infrastructure,” but because you provide a digital service to organizations that are, or because a member state has designated your sector as important at a size threshold that includes you. Scope determination is member-state-specific in its details (each EU country transposes the directive into national law with some latitude), so the honest answer to “are we in scope” is “check with counsel in every jurisdiction you operate in,” not a number from a blog post.

What NIS2 asks of covered entities, at a level of generality that holds regardless of jurisdiction-specific detail:

• A risk management approach covering the organization’s network and information systems, not just a checkbox policy document.
• Incident handling processes with reporting obligations that operate on tight, tiered timelines — an early warning within hours of becoming aware of a significant incident, followed by more detailed reporting shortly after, and a final report once the incident is resolved. Exact timing thresholds vary by transposition; don’t rely on a single number without checking your applicable national law.
• Business continuity and crisis management planning, including backup management and disaster recovery.
• Supply chain security, explicitly including the security practices of direct suppliers and service providers — this is the clause that pulls MSPs and SaaS vendors into everyone’s risk assessment.
• Management-level accountability: NIS2 explicitly puts responsibility on management bodies, including potential personal liability provisions in some transpositions, for approving and overseeing cybersecurity risk-management measures. This is a deliberate design choice to stop security from being purely a delegated technical function that leadership can plausibly claim ignorance of.

DORA: Financial-Sector Operational Resilience

DORA (the Digital Operational Resilience Act) is narrower in sector but arguably deeper in technical specificity: it applies to the EU financial sector — banks, insurers, investment firms, payment institutions, and, critically, the critical third-party providers (cloud platforms, data analytics providers) that those financial entities depend on. That last category is one of DORA’s most distinctive features: it creates a direct oversight mechanism reaching into the technology vendors underneath the financial sector, not just the financial entities themselves.

DORA organizes its requirements around five pillars, which map fairly directly to things a security or platform engineering team already recognizes:

1. ICT risk management — a governance framework for identifying, protecting against, detecting, responding to, and recovering from ICT-related risk, again with explicit management-body ownership.
2. Incident reporting — classification of ICT-related incidents by severity and reporting to regulators within defined windows, similar in spirit to NIS2’s tiered reporting but with financial-sector-specific classification criteria.
3. Digital operational resilience testing — regular testing of ICT systems, including, for larger/more significant entities, threat-led penetration testing (TLPT) performed by qualified testers against production-like systems.
4. Third-party risk management — contractual and oversight requirements over ICT providers, including exit strategies and concentration risk assessment (what happens if your critical cloud provider fails or is unable to continue service).
5. Information sharing — voluntary arrangements for sharing cyber threat information and intelligence among financial entities.

NIS2 vs. DORA at a Glance

Dimension	NIS2	DORA
Primary sectors	Broad — energy, transport, health, digital infra, public admin, digital services, and more	Financial sector specifically, plus critical ICT third-party providers to it
Core mechanism	Risk management + incident reporting + supply chain security	Five-pillar ICT operational resilience framework
Testing requirement	Risk-based, generally less prescriptive	Explicit resilience testing, including TLPT for significant entities
Third-party oversight	Supply chain security expectations on the regulated entity	Direct oversight regime reaching critical ICT providers themselves
Management accountability	Explicit, including liability considerations in some transpositions	Explicit, management body owns the ICT risk framework

Where they overlap — and this is the part worth internalizing regardless of exact scope — is the underlying philosophy: cybersecurity is treated as an operational resilience question owned by leadership, not a technical afterthought delegated entirely to an infosec team with no budget authority, and incidents must be reported on a clock that assumes you already have the visibility to know something happened quickly.

A Practical Control Checklist

None of the following requires citing a specific article number to be worth doing — these are the controls that show up, in one form or another, whenever either regulation gets translated into an actual audit checklist.

# Illustrative internal control-mapping doc, not a legal compliance artifact
controls:
  risk_management:
    - asset_inventory_current: required
    - risk_assessment_cadence: annual_minimum
    - risk_treatment_plan: documented_and_owned

  incident_response:
    - detection_capability: siem_or_equivalent_logging
    - internal_escalation_time_target: "under 1 hour for critical severity"
    - external_reporting_runbook: documented_per_jurisdiction
    - tabletop_exercise_cadence: at_least_annual

  supply_chain:
    - vendor_security_review: required_before_onboarding
    - critical_vendor_register: maintained
    - exit_strategy_documented: for_each_critical_vendor

  resilience_testing:
    - backup_restore_test_cadence: quarterly
    - dr_failover_test_cadence: annual_minimum
    - penetration_test_cadence: annual_minimum

  governance:
    - management_briefing_cadence: quarterly
    - named_accountable_owner: required

Mapped to concrete technical measures a platform team can actually own:

• Logging and detection: centralized log aggregation (a Loki/Promtail or ELK-style stack, or a managed SIEM) with retention long enough to support an investigation, not just a dashboard.
• Backups: tested restores, not just successful backup jobs — a backup nobody has restored from is an assumption, not a control.
• Incident runbooks: a written, rehearsed process for the first hour after a suspected incident, including who has authority to notify a regulator and on what timeline, drafted with actual counsel input rather than improvised during the incident itself.
• Vendor risk register: a maintained list of critical third parties, what they can access, and what happens if they have an outage or breach — this is the operational core of both directives’ supply-chain language.
• Access reviews: periodic review of who has privileged access to production systems, with removal on role change or departure — unglamorous, and consistently the control auditors find gaps in.
• Patch and vulnerability management cadence: a defined SLA from vulnerability disclosure to remediation, tracked, not aspirational.

A vendor risk register does not need to be a specialized GRC product to start; a structured table you actually keep current beats an elaborate tool nobody updates.

-- Minimal critical-vendor register, kept current, not aspirational
CREATE TABLE critical_vendors (
    id SERIAL PRIMARY KEY,
    vendor_name TEXT NOT NULL,
    service_provided TEXT NOT NULL,
    data_access_level TEXT NOT NULL,       -- e.g. 'none', 'pii', 'financial'
    last_security_review DATE,
    exit_strategy_documented BOOLEAN DEFAULT false,
    concentration_risk_notes TEXT
);

-- Flag anything overdue for review at a glance
SELECT vendor_name, last_security_review
FROM critical_vendors
WHERE last_security_review < now() - interval '12 months'
   OR last_security_review IS NULL;

The incident escalation runbook is the other artifact worth having written down before you need it, not during the first hour of an actual incident.

# incident-runbook.yaml — skeleton, adapt timelines to your applicable
# national transposition and confirm with counsel; do not treat the
# hours below as a citation of any specific legal deadline
incident_severity_levels:
  critical:
    internal_escalation: "immediate, page on-call"
    legal_and_compliance_notified: "within 1 hour of confirmed classification"
    regulator_early_warning: "per applicable jurisdiction's timeline — confirm with counsel"
    customer_communication: "per contractual and legal obligations, coordinated with legal"
  high:
    internal_escalation: "within 4 hours"
    legal_and_compliance_notified: "same business day"
  moderate:
    internal_escalation: "next business day triage"

post_incident:
  - root_cause_analysis_required: true
  - final_report_owner: "named accountable owner, not a rotating role"
  - runbook_update_required: true

Where Teams Get This Wrong

The most common mistake is treating either regulation as a one-time certification project rather than an ongoing operational discipline — teams that sprint to a compliant-looking state ahead of an audit date and then let the incident runbook go stale, the vendor register go unmaintained, and the backup restore test lapse are technically “compliant” on paper and operationally unprepared in practice. The second most common mistake is scoping decisions made by engineering leadership without legal input — “are we in scope” and “what exactly must we report and by when” are jurisdiction-specific legal questions, and getting them wrong in either direction (assuming you’re out of scope when you’re not, or over-building compliance theater for obligations that don’t actually apply) wastes real effort either way.

Key Takeaways

• NIS2 broadens the EU’s critical-sector cybersecurity baseline across a wide range of industries and sizes, including many digital service providers who may not think of themselves as “critical infrastructure.”
• DORA is financial-sector-specific but reaches further into technical specificity, including mandated resilience testing (up to threat-led penetration testing for significant entities) and direct oversight of critical ICT third parties.
• Both regulations put explicit accountability on management bodies, not just delegated security teams — this is a deliberate structural choice, not an incidental detail.
• Incident reporting under both operates on tight, tiered timelines that assume you already have the detection capability to notice an incident quickly — build that capability before you need the clock to start.
• Supply chain and third-party risk management is a first-class obligation under both, not an afterthought — maintain an actual vendor register with documented exit strategies for critical providers.
• Exact scope thresholds, reporting timelines, and penalty structures are jurisdiction- and transposition-specific — verify with qualified legal counsel rather than a generic online summary, this one included.
• Good operational security practice (tested backups, rehearsed incident response, maintained vendor risk registers, access reviews) is worth doing on its own merits, independent of whether a specific regulation formally applies to you.