Best Way to Comply with DORA and NIS2

The best way to comply with DORA and NIS2 is to build a unique program based on risks and evidence, not two separate projects. You align governance, the inventory of critical assets, testing, remediation, and traceability on a single foundation, then map this foundation to the requirements of Regulation (EU) 2022/2554 and Directive (EU) 2022/2555. It’s easier to manage and more robust in an audit because you don’t multiply internal frameworks for the same risk.

Key takeaways

• A unique program costs less than dual compliance and produces consistent evidence for DORA and NIS2.

• Compliance mainly hinges on the inventory of critical assets, mapping of dependencies, and dated proof of controls.

• Regular testing matters more than a well-written PDF file, as authorities want to see implemented and verifiable measures.

• The right target is simple: for each major requirement, show a control, an owner, proof, and the latest test result.

• Key Points

The Best Choice: A Unique Compliance Foundation Based on Evidence

Why Separating DORA and NIS2 Costs More

Teams that launch two programs almost always end up with two inventories, two risk matrices, and two validation circuits. It’s double work, leading to longer timelines, more discrepancies, and greater difficulty defending the case in an audit. DORA targets the financial sector and digital operational resilience; NIS2 covers essential and important entities across several sectors of the EU. The substance is different, but the mechanisms are largely common. According to https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai, "the average U.S. cost of a breach reached a record $10.22 million." When the cost of an incident reaches this level, the issue is no longer just regulatory; it becomes operational.

The Common Logic to Exploit

You need to start with shared building blocks: governance, risk management, incident notification, supply chain security, regular testing, and continuous improvement. The real difference in an audit does not lie in the number of policies but in the quality of the evidence related to critical systems. A good file shows who decides, what is protected, how often it is tested, and how discrepancies are corrected. This is where compliance becomes defensible. In practice, it quickly becomes clear that the same controls serve both the resilience expected by DORA and the security posture required by NIS2.

Start with Critical Systems and Applicable Obligations

Defining the Scope Without Blind Spots

The safest method consists of four steps. First, define the legal scope: entities, countries, activities, and applicable obligations. Second, identify essential, critical, or important services. Third, link these services to supporting assets. Fourth, map third-party dependencies. Without this sequence, you will audit secondary systems while real risks remain off-screen. In a medium-sized group, it is often seen that a priority business application depends on a SSO, an email provider, and a cloud host. If any one of these links fails, the service becomes unavailable. It is this dependency path that needs to be documented, not just the list of servers.

Identifying the Assets That Matter in Supervision

The expected deliverables are simple: asset register, application mapping, third-party matrix, and governance RACI, meaning who is responsible, who validates, who executes, and who is informed. The link between DORA and NIS2 is quickly visible: critical or important functions in DORA often correspond to essential or important services in NIS2. Take an API-first client portal with public cloud, an IAM service, and a CI/CD pipeline. If the cloud, identity, or pipeline fails, the service fails too. Therefore, the scope must reflect these dependencies, not just the organizational chart. This is also where evidence is most often lacking, as ownership is diluted between security, product teams, and operations.

Build a Common DORA-NIS2 Control Matrix

The Areas to Merge

The right approach is to merge the requirements into a single control matrix. You map DORA and NIS2 to internal controls on IAM, vulnerability management, logging, backups, incident response, and third-party management. To operationalize this matrix, useful frameworks include ISO/IEC 27001, ISO/IEC 27002, NIST Cybersecurity Framework 2.0, and CIS Controls. They do not replace the texts but provide a usable control structure. According to https://www.verizon.com/business/en-en/resources/reports/dbir/, "While representing approximately one-fourth of our dataset," web application attacks weigh heavily in the observed incidents. For a compliance officer, this is a clear signal: application controls are not secondary; they are at the center of the risk.

The Evidence to Associate with Each Control

In an audit, a control only truly exists if it is linked to a dated proof, an owner, and a frequency. A simple example:

• Vulnerability Management → weekly scans, quarterly or targeted pentests, correction tickets, validated exceptions.

• Logging → retained logs, timestamps, alert reviews, detection proof.

• Third-Party Management → contractual clauses, risk assessments, periodic reviews, reported incidents.

A control without proof is an intention. Proof without ownership is waste. This is also why teams that document a lot but test little end up accumulating invisible discrepancies.

Regular Testing is the Hardest Part to Prove

What the Audit Wants to See

DORA emphasizes testing for digital operational resilience. NIS2 expects proportional technical, operational, and organizational measures, with an evaluation of their effectiveness. This changes everything: a simple compliance table is not enough. The audit wants to see a complete cycle, from testing to correction, with dates, results, and follow-ups. This is precisely where many programs fail. In application environments, the speed of correction is often the weak point. According to https://info.edgescan.com/vulnerability-statistics-li23, the MTTR of a critical vulnerability on a web application is 35 days. In other words, a known hole can remain open for over a month if no one drives the retest and closure.

Why an Annual Pentest Often Isn’t Enough

A vulnerability scan detects known flaws. A configuration review checks for hardening discrepancies. An application penetration test validates actual exploitation chains. A crisis exercise tests coordination and notification. They have different objectives, hence different frequencies. The usual weak point is static PDF reports: they describe a problem but do not prove remediation or retesting. Fleuret reduces this proof risk with rapid agent-based pentests, replayable proofs of concept, and DORA/NIS2 mapping linked to remediation tickets. You get actionable results in hours, not a document forgotten in a shared folder.

Transform Each Requirement into Audit-Ready Evidence

The Minimal Form of Solid Evidence

Acceptable evidence contains at least the date, scope, method, result, criticality, owner, correction status, and approval or exception. Without these elements, the auditor cannot verify whether the control was applied to the right system at the right time. The documents to retain are fairly stable: approved policies, test results, incident logs, risk decisions, supplier contracts, continuity plans, and review minutes. According to https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024, "For another year ransomware and DDoS attacks were the most reported forms of attacks during the reporting period and accounted for more than half of the" most reported forms of attacks. This type of pressure explains why response and remediation evidence must remain up to date, not just archived.

The Audit File to Keep Updated

Take a critical vulnerability. The chain of evidence must show: detection, validation, ticket, correction, retest, closure. This sequencing applies to both DORA and NIS2. When the need is to produce an actionable file quickly, Fleuret pushes findings to Jira, Linear, or Slack, then provides a signed report on demand. The gain is not cosmetic: you shorten the time between discovery and correction, thus reducing the gap between paper compliance and actual compliance. Among the teams we see, it is often this loop that separates a credible posture from a mere stack of documents.

The Mistakes That Most Often Block Compliance

False Signals of Maturity

The five mistakes I see most often are always the same: policies not linked to critical assets, incomplete inventory, poorly assessed third-party dependencies, one-off pentests without follow-up, and lack of ownership for exceptions. The real trade-off is between broad coverage and depth of testing. If you test broadly but superficially, you reassure management without improving risk. If you test deeply but too few systems, you leave blind spots. European financial organizations are already very exposed: in the 2024 sector analysis, the https://www.eba.europa.eu/publications-and-media/publications/operational-risks-and-resilience-0 studied 488 public incidents from January 2023 to June 2024. This volume shows how much supervision expects precise files, not general promises.

The Blind Spots of Overly Documentary Programs

Too many organizations confuse documentary compliance with demonstrated resilience. An environment may seem clean on paper and remain fragile in production: an exposed API, partial MFA, or secrets left in CI/CD are enough to bring down the demonstration. The regulator is not looking for a perfect binder. They seek the ability to prevent, detect, correct, and prove. The third weakness we often see is third-party management. According to https://securityscorecard.com/resources/resources/global-third-party-breach-report/, 35.5% of breaches in 2024 were related to third-party access. For a compliance officer, this means that a supplier contract without reviews or evidence of assessment leaves a hole in the entire system.

90-Day Action Plan to Quickly Establish Credibility

The First 30 Days

Define the scope, the register of critical assets, and the mapping of third parties. Appoint an owner for each major control, then establish an incident notification procedure. This is the minimum compliance setup. It does not make you mature, but it avoids obvious gaps and structures the rest. If you start in an environment of 12 people delivering twice a day, don’t seek exhaustiveness. Start with exposed services, sensitive data, and authentication paths. This is where the impact is immediate.

The Next 60 Days

Build the common control matrix, then set a testing schedule. Launch the first scans, configuration reviews, and penetration tests on priority systems. Add tracking for tickets and exceptions. Sustainable maturity begins when each discrepancy has an owner, a target date, and proof of closure. In finance, the pressure is even greater: resilience is not proven with a single annual exercise but with a repeatable sequence of testing, correction, and retesting.

By 90 days, you should be able to show, for each major requirement, the control, the proof, and the latest result. If you cannot do this, you are not yet credible in an audit, even if the policies are written.

What I Recommend

Do not treat DORA and NIS2 as two separate regulatory projects. Build a common foundation, then keep it alive through regular testing, correction tickets, and clean evidence. If your team can quickly show the latest test, the control owner, and the closure of the discrepancy, you are on the right track. Otherwise, start there before writing another line of policy.