DORA and NIS2 compliance: build one evidence program, not two

Yanis Grigy, CEO10 min read

The fastest way to comply with DORA and NIS2 is to build one program grounded in risk and evidence, not two separate projects. You align governance, the inventory of critical assets, testing, remediation and traceability on a single foundation, then map that foundation to Regulation (EU) 2022/2554 and Directive (EU) 2022/2555. It is easier to run and it holds up better in an audit, because you stop maintaining several internal frameworks for the same risk.

Key takeaways

  • One program costs less than double compliance, and it produces consistent evidence for both DORA and NIS2.
  • Compliance is won or lost on the critical asset inventory, the dependency map and dated proof that controls work.
  • Regular testing matters more than a well-written PDF, because supervisors want to see measures that are implemented and verifiable.
  • The target is simple: for every major requirement, show a control, an owner, a piece of evidence and the latest test result.

The best option: one evidence-based compliance foundation

Why splitting DORA and NIS2 costs more

Teams that launch two programs almost always end up with two inventories, two risk matrices and two approval circuits. That is duplicated work, which means more delay, more gaps and a harder file to defend in front of an auditor. DORA targets the financial sector and digital operational resilience. NIS2 covers essential and important entities across many EU sectors. The substance differs, but the mechanics are largely shared.

The stakes are not only regulatory. According to IBM's 2025 Cost of a Data Breach report, "the average U.S. cost of a breach reached a record $10.22 million." At that price, a compliance program that does not reduce real exposure is money spent twice.

The shared logic to exploit

Start from the common building blocks: governance, risk management, incident notification, supply chain security, regular testing and continuous improvement. What makes the difference in an audit is not the number of policies, it is the quality of the evidence tied to critical systems. A good file shows who decides, what is protected, how often it is tested and how gaps get fixed. In practice, the same controls serve both the resilience DORA expects and the security posture NIS2 requires.

Start with critical systems and the obligations that apply

Scope without blind spots

The safest method has four steps:

  1. Define the legal perimeter: entities, countries, activities and applicable obligations.
  2. Identify the essential, critical or important services.
  3. Link those services to the assets that support them.
  4. Map the third-party dependencies.

Skip that sequence and you will audit secondary systems while the real risks sit outside the scope. In a mid-sized group, a priority business application often depends on an SSO provider, an email provider and a cloud host. If any one of those links fails, the service is down. That dependency path is what you need to document, not just the server list.

Identify the assets supervisors care about

The deliverables are simple: an asset register, an application map, a third-party matrix and a governance RACI (who is responsible, who approves, who executes, who is informed). The overlap between the two texts shows up quickly: critical or important functions under DORA often match essential or important services under NIS2.

Take an API-first customer portal running on a public cloud, with an IAM service and a CI/CD pipeline. If the cloud, the identity layer or the pipeline goes down, the service goes down with it. The scope has to reflect those dependencies, not the org chart. This is also where evidence is most often missing, because ownership is split between security, product teams and operations.

Build a shared DORA and NIS2 control matrix

The domains to merge

Merge the requirements into a single control matrix. Map DORA and NIS2 to internal controls on IAM, vulnerability management, logging, backups, incident response and third-party management. ISO/IEC 27001, ISO/IEC 27002, the NIST Cybersecurity Framework 2.0 and the CIS Controls are useful to operationalise that matrix. They do not replace the legal texts, but they give you a control structure you can run.

Application security belongs at the centre of that matrix. The Verizon Data Breach Investigations Report places basic web application attacks at roughly a quarter of its dataset. For a compliance lead, the signal is clear: application controls are not a side topic, they are where the risk concentrates.

The evidence behind each control

In an audit, a control only exists if it is tied to dated evidence, an owner and a frequency. For example:

  • Vulnerability management: recurring scans, targeted or periodic pentests, remediation tickets, approved exceptions.
  • Logging: retained logs, timestamps, alert reviews, proof of detection.
  • Third-party management: contract clauses, risk assessments, periodic reviews, reported incidents.

A control without evidence is an intention. Evidence without an owner is noise. That is why teams that document a lot but test little end up accumulating gaps nobody sees.

Regular testing is the hardest part to prove

What the audit wants to see

DORA insists on digital operational resilience testing. NIS2 expects proportionate technical, operational and organisational measures, with an assessment of their effectiveness (Article 21(2)(f), covered in detail in our piece on NIS2 for the mid-market). That changes everything: a compliance spreadsheet is not enough. The audit wants a complete cycle, from test to fix, with dates, results and follow-up.

This is exactly where many programs break. On application environments, remediation speed is usually the weak point. According to Edgescan's vulnerability statistics report, the mean time to remediate a critical vulnerability in a web application is 35 days. A known hole can stay open for more than a month if nobody drives the retest and the closure.

Why an annual pentest is often not enough

A vulnerability scan detects known flaws. A configuration review checks hardening gaps. An application penetration test validates real exploitation chains. A crisis exercise tests coordination and notification. They have different goals, so they need different frequencies. The DORA side of this is covered in our guide to DORA penetration testing requirements.

The usual weak point is the static PDF report: it describes a problem, but it proves neither the remediation nor the retest. Fleuret closes that evidence gap with fast agentic pentests, replayable proofs of concept and a DORA and NIS2 mapping linked to remediation tickets. You get actionable results in hours, not a document forgotten in a shared folder.

Turn every requirement into audit-ready evidence

The minimum shape of solid evidence

Acceptable evidence carries at least the date, the scope, the method, the result, the severity, the owner, the remediation status and the approval or exception. Without those fields, the auditor cannot verify that the control was applied to the right system at the right time. The documents to keep are fairly stable: approved policies, test results, incident registers, risk decisions, supplier contracts, continuity plans and review minutes.

The threat pressure explains why that file has to stay current rather than archived. The ENISA Threat Landscape 2024 reports that ransomware and DDoS attacks were again the most reported forms of attack over the period, together accounting for more than half of the incidents it observed. Response and remediation evidence goes stale fast in that environment.

The audit file to keep up to date

Take one critical vulnerability. The evidence chain has to show: detection, validation, ticket, fix, retest, closure. That sequence works for DORA and for NIS2 alike. When you need a usable file fast, Fleuret pushes findings to Jira, Linear or Slack, then delivers a signed report on demand. The gain is not cosmetic: you shorten the time between discovery and fix, which shrinks the distance between compliance on paper and compliance in production. In the teams we work with, that loop is usually what separates a credible posture from a 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:

  1. Policies that are not tied to critical assets.
  2. An incomplete inventory.
  3. Third-party dependencies that were never properly assessed.
  4. One-off pentests with no follow-up.
  5. No owner for exceptions.

The real trade-off is between breadth and depth of testing. Test broadly but shallowly and you reassure the board without reducing risk. Test deeply but on too few systems and you leave blind spots. European financial organisations are already heavily exposed: in its 2024 sector analysis, the EBA reviewed 488 public incidents between January 2023 and June 2024. Supervisors expect precise files, not general promises.

The blind spots of paper-heavy programs

Too many organisations confuse documented compliance with demonstrated resilience. An environment can look clean on paper and stay fragile in production: an exposed API, partial MFA or secrets left in the CI/CD pipeline are enough to break the demonstration. The regulator is not looking for a perfect binder. It is looking for the ability to prevent, detect, fix and prove.

Third-party risk is the other weakness we see constantly. According to SecurityScorecard's Global Third-Party Breach Report, 35.5% of breaches in 2024 were linked to third-party access. A supplier contract with no reviews and no assessment evidence leaves a hole in the whole program.

A 90-day plan to become credible fast

Days 1 to 30

Set the scope, build the critical asset register and map your third parties. Name an owner for each major control, then fix an incident notification procedure. This is minimum compliance. It does not make you mature, but it closes the obvious gaps and gives the rest a structure.

If you are a 12-person team shipping twice a day, do not chase exhaustiveness. Start with exposed services, sensitive data and authentication paths. That is where the impact is immediate.

Days 31 to 90

Build the shared control matrix, then set a testing calendar. Run the first scans, configuration reviews and penetration tests on priority systems. Add tracking for tickets and exceptions. Durable maturity starts when every gap has an owner, a target date and a proof of closure. In finance the pressure is higher still: resilience is not proven by a single annual exercise, but by a repeatable sequence of test, fix and retest.

At day 90, you should be able to show, for every major requirement, the control, the evidence and the latest result. If you cannot, you are not yet credible in an audit, even if every policy is written.

What I recommend

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

Fleuret runs agentic pentests that produce the evidence chain DORA and NIS2 auditors ask for: replayable PoCs, tickets, retest and a signed report. See Fleuret in action.

Sources

Share this postShare on LinkedIn

Privacy Settings

This site uses third-party website tracking technologies to provide and continually improve our services, and to display information according to users' interests. I agree and may revoke or change my consent at any time with effect for the future.

Privacy PolicyLegal NoticeMore Information