NIS2 and DORA: What EU Companies Must Do Now

Two pieces of EU law have changed what 'doing enough' on security means, and both now have teeth. NIS2 raises the baseline for a wide swathe of the economy and makes management personally answerable for it. DORA does something narrower and deeper for the financial sector, turning operational resilience into a supervised obligation with prescribed testing. If your organisation is in scope for either, security is no longer only an engineering concern; it is a compliance obligation with named deadlines and personal consequences.

We are a security firm, not a law firm, and this is not legal advice — for your specific obligations, take proper counsel. What we can do is explain what the two regimes require in plain terms, where the dates actually stand, and how the testing and red-teaming we do maps onto the obligations, because a good deal of what both regimes demand is work we already carry out.

This is for the CTO, the CISO, and the board member who has worked out that 'the management body' in these texts means them. We have verified the dates and figures below against current sources; where a detail remains uncertain, we say so rather than inventing precision.

NIS2 in brief

NIS2 is the EU's second Network and Information Security Directive, replacing the original NIS. It widens the net considerably and standardises obligations that member states previously implemented unevenly. Because it is a directive, it does not apply directly; each member state must transpose it into national law, and the detail that binds you is that national law, not the directive text.

Who is in scope

NIS2 sorts covered organisations into two tiers, essential entities and important entities. The split follows the sector and the size of the organisation. Sectors of high criticality — energy, transport, banking and financial market infrastructure, health, drinking and waste water, digital infrastructure, public administration and space — sit in the first annex; other critical sectors, such as postal services, waste management, chemicals, food, manufacturing, digital providers and research, sit in the second.

The general size threshold brings in organisations above the medium-enterprise line: broadly, more than fifty staff or an annual turnover and balance-sheet total above ten million euro. Larger organisations in the high-criticality sectors tend to fall into the essential tier; others and smaller qualifying ones into the important tier. Some entities are in scope regardless of size because of what they do — public electronic-communications providers, trust-service providers, top-level-domain registries and DNS providers among them. The practical difference between the tiers is supervision: essential entities face proactive oversight, while important entities are generally supervised after the fact, though authorities can demand evidence of compliance at any time.

What it requires

At its core NIS2 asks for risk-based security measures proportionate to the risk, covering the obvious ground — risk analysis and information-system security policy, incident handling, business continuity and backups, supply-chain security, secure acquisition and development, policies to assess whether the measures work, cryptography, access control and asset management. The supply-chain clause matters: you are expected to account for the security of your direct suppliers and service providers, not only your own systems.

Management-body liability

This is the clause that changed the conversation in boardrooms. Under NIS2 the management body must approve the cybersecurity risk-management measures and oversee their implementation, and it can be held liable for failures to comply. Members are also required to undergo training so they can identify risks and assess management practices. Some member states provide for the temporary suspension of managers who fail to act on an authority's directions. Security is now a board responsibility in law, not only in principle.

Incident reporting

NIS2 sets a staged timeline for significant incidents. An early warning is due within 24 hours of becoming aware of the incident; a fuller incident notification within 72 hours; and a final report within one month of that notification, with an intermediate update on request. The short first clock is the one that catches teams out — 24 hours is not long to detect, classify and notify while the incident is still live, which is exactly why detection and an exercised incident process matter so much.

Fines

The directive sets maximum administrative fines of at least ten million euro or two per cent of total worldwide annual turnover, whichever is higher, for essential entities, and at least seven million euro or 1.4 per cent for important entities. Member states may go further. These ceilings are deliberately set at a level a board cannot treat as a cost of doing business.

Where the dates actually stand

The transposition deadline was 17 October 2024, and many member states missed it — the Commission has pursued infringement proceedings against the laggards. Portugal is one of the countries that transposed late. It did so through Decreto-Lei n.º 125/2025, published on 4 December 2025, which establishes the national cybersecurity legal regime and enters into force on 3 April 2026, 120 days after publication. The Centro Nacional de Cibersegurança is the lead competent authority, with CERT.PT as the national CSIRT inside it, and ANACOM, the Banco de Portugal and the CMVM acting as sector authorities. Some of the risk-management, reporting and supervision provisions phase in over a longer period after supplementary regulation, and in-scope entities must self-identify and register on the CNCS platform and notify a cybersecurity officer and a point of contact within a short window of the regime applying. If you operate in Portugal, treat the Diário da República text and CNCS guidance as the authoritative source for the exact dates and thresholds that apply to you.

DORA in brief

DORA, the Digital Operational Resilience Act, is a regulation rather than a directive, which means it applies directly across the EU without national transposition, with harmonised technical standards filling in the detail. It targets the financial sector specifically, and it has applied since 17 January 2025. Where both DORA and NIS2 could touch a financial entity, DORA is the more specific regime and takes precedence for the matters it covers.

Who is in scope

DORA reaches most of the regulated financial sector: banks, insurers and intermediaries, investment firms, payment and e-money institutions, fund managers, pension funds, crypto-asset service providers and crowdfunding providers, among others. It also reaches outward, to the ICT third-party providers that serve these firms — the critical ones can be designated and supervised directly at EU level.

The five pillars

DORA is usually described as five areas of obligation. The first is ICT risk management: a governance framework for identifying, protecting against, detecting, responding to and recovering from ICT disruption, owned by the management body. The second is incident management, classification and reporting of ICT-related incidents on a common standard. The third is digital operational resilience testing, from routine assessments up to advanced threat-led testing. The fourth is ICT third-party risk, including the contractual and oversight requirements for providers. The fifth is information sharing on cyber threats among financial entities. A common failing is to treat these as five separate projects; they are facets of one resilience programme, and each assumes you have an accurate picture of your own systems and dependencies.

ICT third-party risk and the register of information

DORA takes third-party risk seriously enough to make it administrative. Firms must maintain a register of information documenting all their contractual arrangements for the use of ICT services, which supervisors collect and use to identify concentration risk across the sector. Contracts with ICT providers must contain specified terms — access, audit, exit, sub-contracting and the rest — and the register must be complete and accurate, because gaps in it are themselves a finding when a supervisor asks for it.

Threat-led penetration testing

For the obligation that most directly concerns us: DORA requires financial entities whose scale and risk profile warrant it to carry out advanced testing in the form of threat-led penetration testing, aligned with the established European TIBER framework. This is not a routine scan. It is an intelligence-led exercise against the live production systems supporting critical functions, using threat scenarios built from current intelligence about who would attack this institution and how, carried out by testers meeting specified competence requirements and conducted on a multi-year cycle. It is closer to a real attack than anything a compliance checklist usually asks for, and it is designed to be.

Major incident reporting

DORA's reporting clock runs from the point an incident is classified as major, and the harmonised standards set the stages: an initial notification within a short window measured in hours, an intermediate report within days, and a final report within about a month. The precise hour-counts and the classification criteria are set in the technical standards, so a firm in scope should work to those rather than to a remembered figure. As with NIS2, the demanding part is the first clock, which rewards firms that can detect and classify quickly.

How pentesting and red teaming map onto the obligations

A large part of both regimes is, in substance, the work a competent offensive-security programme already does — which means security spend can satisfy compliance obligations rather than competing with them.

NIS2's requirement for measures to assess the effectiveness of your security is not met by owning tools; it is met by testing whether they work, which is what a penetration test demonstrates. Its supply-chain clause maps directly onto assessing the security of the software and services you depend on — the subject of Securing Your Software Supply Chain. Its 24-hour reporting clock is only achievable if you can detect and triage fast, so an engagement that tests your detection and response — whether your team would have seen the attack and reacted in time — speaks to the obligation directly.

DORA's testing pillar is the most explicit mapping of all: threat-led penetration testing aligned with TIBER is a red-team engagement with a regulatory wrapper. The resilience-testing obligation more broadly is satisfied by a programme of regular technical testing, and the third-party-risk pillar is informed by assessing the providers in your register. Where you operate cloud infrastructure, the identity layer we examine in Cloud IAM Misconfigurations That Lead to Breaches is squarely within the ICT-risk-management pillar.

What to do now

First, establish scope and get it in writing. Determine whether you are an essential or important entity under your national NIS2 law, whether DORA applies to you, and if both, which governs each obligation. Scope drives everything else, and getting it wrong in either direction is expensive.

Then work the gaps in priority order. Map your obligations against what you actually do today and close the differences, starting with the ones that carry the shortest clocks and the clearest liability. Confirm your management body has formally approved the risk-management measures and had the required training, because that is a specific, checkable obligation with personal consequences. Build and rehearse an incident process that can hit the first reporting deadline, since a plan nobody has exercised will not meet a 24-hour clock under real pressure. If DORA applies, build the register of information properly and plan for threat-led testing on the required cycle. Across both, treat supply-chain and third-party risk as a first-class obligation, not an afterthought.

How we help

Our part of this is the testing and the evidence. We run penetration tests and red-team engagements that demonstrate whether your measures work and whether your team would detect and respond in time, and we deliver findings in a form that supports your compliance narrative — clear severity, proven impact, concrete fixes and a record of what was tested. For DORA entities, we scope and run threat-led testing aligned with the framework. We do not sell you a compliance certificate; we give you the honest result of an adversarial test, which is what both regimes are ultimately asking you to be able to withstand.

Next steps

Confirm your scope under the national NIS2 law and under DORA, then look at your last independent test. If you cannot remember one, or it was a scan rather than an adversarial engagement, that is the gap to close first — it is the one both regimes point at most directly.

Our testing scope and process are on the services page, and you can reach the team on Telegram.