2025 was the year that several years of regulatory drafting and consultation turned into enforcement reality. NIS2 hit its October 2024 national transposition deadline and member state regulators began supervisory activity in early 2025. DORA's compliance deadline of January 2025 meant that EU financial entities faced their first full year under the regulation's ICT risk management requirements. In the US, the SEC's updated cybersecurity disclosure rules moved from guidance to enforcement action. This report synthesises the practical compliance implications for security teams.
NIS2: From Directive to Enforcement Reality
The NIS2 Directive replaced the original NIS Directive and significantly expanded its scope. Where NIS covered seven essential service sectors, NIS2 covers eighteen. The directive introduced a two-tier entity classification — essential entities and important entities — with different supervisory regimes for each. Essential entities face proactive supervision (regulators can initiate inspections without a triggering incident). Important entities face reactive supervision (supervision follows reported incidents or complaints).
ENISA's implementation report found that as of Q1 2025, 22 of 27 EU member states had completed national transposition. The five that had not were facing infringement proceedings. Enforcement activity began almost immediately after transposition in several member states, with supervisory authorities issuing information requests to entities in the energy and digital infrastructure sectors.
| NIS2 Requirement | Key Obligation | Common Gap Found in Practice |
|---|---|---|
| Art. 21 - Risk management measures | Implement proportionate technical and organisational security measures across 10 defined domains | Vulnerability management for OT/ICS systems not meeting the same standards as IT |
| Art. 23 - Incident reporting | Early warning within 24h, notification within 72h, final report within 1 month | No documented incident classification procedure to determine NIS2 reportability threshold |
| Art. 20 - Governance | Management bodies must approve and oversee cybersecurity risk management | Board-level cybersecurity accountability not formally established in governance documents |
| Art. 21(2)(d) - Supply chain security | Security measures addressing supply chain risks including vendor relationships | Third-party vendor security assessments not conducted or not documented |
The 24-Hour Early Warning Requirement
The NIS2 incident reporting timeline is the requirement most organisations are least prepared for. A 24-hour early warning to the national competent authority or CSIRT, followed by a 72-hour notification, requires a detection-to-decision process that most security teams have not formally designed.
The early warning at 24 hours does not require a complete picture of the incident. It requires: confirmation that a significant incident has occurred, an initial characterisation of the incident type, and an indication of whether the incident is suspected to be malicious. The difficulty is establishing internally — within 24 hours of discovery — that a given event meets the NIS2 threshold for a significant incident.
NIS2 Significant Incident Criteria (Article 23(3)):
An incident is "significant" if it:
(a) has caused or is capable of causing severe operational disruption
of the services or financial loss for the entity concerned; OR
(b) has affected or is capable of affecting other natural or legal
persons by causing considerable material or non-material damage.
Practical decision checklist (complete within 24h of discovery):
[ ] Has the incident caused or could it cause service disruption?
[ ] Has personal data been affected? (triggers parallel GDPR notification)
[ ] Has the incident affected other organisations (supply chain)?
[ ] Is the incident likely to be malicious (vs. accidental/technical fault)?
[ ] Does the incident involve critical or important systems (per your NIS2 scope)?
If YES to any of (a) or (b): file early warning to national CSIRT within 24h.DORA: What Financial Entities Needed to Build
The Digital Operational Resilience Act applies to a wide range of EU financial entities: banks, insurance companies, investment firms, crypto-asset service providers, and critically, their critical ICT third-party service providers. DORA's January 2025 compliance deadline meant that most entities spent 2024 in a frantic implementation sprint.
The EBA's regulatory technical standards specify the substance of DORA's five pillars in more detail than the regulation itself. The requirements that generated the most implementation work were: the ICT risk management framework (Pillar 1), the TLPT (Threat-Led Penetration Testing) programme for significant entities (Pillar 4), and the ICT third-party risk management framework with its requirement for a maintained register of all ICT service provider contracts (Pillar 5).
DORA's TLPT requirement mandates threat-led penetration testing for significant financial entities on at least a three-year cycle. The tests must be conducted by qualified testers, cover production systems including live customer-facing infrastructure, and follow a structured methodology (TIBER-EU or equivalent national framework). This is a meaningfully higher bar than standard penetration testing and many institutions underestimated the lead time for procurement and preparation.
SEC Cybersecurity Disclosure Rules: Enforcement Activity Begins
The SEC's cybersecurity disclosure rules, adopted in July 2023, required public companies to disclose material cybersecurity incidents within four business days and to include annual disclosures about cybersecurity risk management, strategy, and governance in 10-K filings. 2025 saw the first enforcement actions under the rules.
The initial enforcement focus was on two failure patterns: disclosure timeliness (incidents that were not disclosed within the four-day window) and disclosure quality (annual disclosures that described security programmes at a level of generality that provided no substantive information about actual governance and risk management practices). PwC's Global Digital Trust Insights 2025 found that 61% of CISO respondents at public companies had not yet established a formal process for determining materiality of cybersecurity incidents within the required four-day window.
What Auditors Are Actually Checking in 2025
Based on feedback from clients who have been through NIS2 supervisory engagements and DORA readiness assessments in 2025, the practical focus of regulatory scrutiny has been on three areas that map to the most common implementation gaps:
- --Evidence of management involvement in cybersecurity governance. Regulators want meeting minutes, board reports, and written policies signed by named senior individuals — not just a policy document that states 'the board is responsible for cybersecurity'.
- --Third-party and supply chain risk documentation. A register of critical suppliers with their security assessment status, contract references to security obligations, and evidence that the assessments were actually conducted.
- --Incident response capability evidence. Documented and tested incident response plans, with test records (tabletop exercises, simulations, or actual incident post-mortems) demonstrating that the plan works in practice.
Common Implementation Gaps and Fixes
| Gap | Regulatory Reference | Practical Fix |
|---|---|---|
| No documented NIS2 incident reporting procedure | NIS2 Art. 23 | Create a one-page decision tree: is this incident significant? If yes, who calls the CSIRT? Practise it in a tabletop. |
| Board not receiving regular cybersecurity reporting | NIS2 Art. 20 / DORA Art. 5 | Quarterly board-level cybersecurity dashboard with three metrics: threat exposure, control health, open incidents. |
| No third-party ICT service register | DORA Art. 28 | Inventory all ICT service contracts. Classify each by criticality. Ensure contracts include DORA-required provisions. |
| No formal materiality determination process for SEC disclosure | SEC Rule 13a-1 / 15d-1 | Define materiality criteria in writing (revenue impact threshold, data sensitivity, operational disruption). Get legal sign-off. Test in a simulation. |
The common thread across all three regulatory frameworks is that documentation and governance evidence matter as much as technical controls. A technically strong security programme that cannot produce written evidence of board oversight, incident reporting procedures, and third-party risk management will fail a regulatory review even if the underlying controls are sound. Build your compliance programme to produce evidence as a natural by-product of doing the work, not as a separate documentation exercise before an audit.