Who is affected

The three frameworks interlock and differ mainly in scope:

  • GDPR: every organization that processes personal data.
  • NIS2: companies in 18 sectors, usually from medium size upwards, from energy and health to digital services. In Germany, NIS2 has applied through the NIS-2 implementation act since 6 December 2025. The BSI thus supervises around 29,500 entities instead of about 4,500 before. By the end of June 2026, 17,729 of them had registered.
  • DORA: financial entities such as banks, insurers and payment service providers. DORA has applied directly in all EU member states since 17 January 2025.
applies to everyoneGDPR Art. 32

Appropriate technical measures to protect personal data, including regular review of their effectiveness.

deadline 17.10.2024 · 18 sectorsNIS2

Risk management, reporting obligations, and management-level accountability for essential and important entities.

from 17.01.2025 · financial sectorDORA

Digital operational resilience, including regular testing of ICT systems, of which APIs are a central part.

From the inside out: GDPR applies to every organization handling personal data, NIS2 additionally to 18 critical sectors, DORA to the financial sector.

NIS2: what applies to APIs

NIS2 requires risk-management measures under Article 21. Several of them directly concern APIs:

  • Security in development and maintenance, including vulnerability handling: vulnerabilities in APIs must be found and fixed, not only after an incident.
  • Procedures to assess effectiveness: having measures is not enough. They must demonstrably work, for example through regular testing.
  • Supply chain security: this also covers APIs of service providers and third parties that are integrated into your own processes (see Unsafe Consumption of APIs).
  • Access control and multi-factor authentication: for APIs this means sound authentication and authorization, exactly where BOLA and BFLA arise.

Significant incidents must be reported: an early warning within 24 hours, a notification within 72 hours and a final report after one month.

Management must approve the measures and oversee their implementation. It can be held liable for infringements. The directive provides for fines of up to EUR 10 million or 2% of worldwide annual turnover for essential entities. For important entities it is up to EUR 7 million or 1.4%, whichever is higher in each case.

DORA: what applies to APIs

DORA requires financial entities to have a digital operational resilience testing programme (Art. 24). For APIs, the key points are:

  • Tests at least once a year of all ICT systems and applications supporting critical or important functions (Art. 24(6)). APIs through which payments, accounts or customer data flow usually belong to them.
  • Explicitly named types of test: from vulnerability scans through source code reviews and end-to-end tests to penetration tests (Art. 25).
  • TLPT: certain financial entities must additionally carry out threat-led penetration tests at least every three years (Art. 26).
  • Third-party APIs: they fall under ICT third-party risk. Dependencies must be recorded, assessed and contractually secured (Art. 28 et seq.).

As with NIS2: major ICT-related incidents must be reported.

GDPR: what applies to APIs

The GDPR applies to every API through which personal data flows. Article 32 requires appropriate technical and organizational measures and explicitly a process for regularly testing their effectiveness. If a personal data breach becomes known, for example because an API returned other customers' data, it usually has to be reported to the supervisory authority within 72 hours (Art. 33).

GDPR sanctions violations of the security of processing (Art. 32) under the lower fine tier with up to 10 million euros or 2% of worldwide annual turnover, whichever amount is higher. More severe violations reach up to 20 million euros or 4%.

What auditors expect as evidence

All three frameworks require not only measures, but proof that they work. For APIs this means in practice:

  • An up-to-date API inventory: which interfaces exist, including old versions and shadow APIs, and who owns them.
  • Test scope and frequency: which APIs were tested when and how. Under DORA this is at least yearly for critical functions.
  • Findings with evidence: which endpoint, which test, which result. A score without evidence is not enough in an audit.
  • Remediation and retest: how each finding was handled and whether the gap is demonstrably closed.
  • Mapping to the requirement: which finding touches which obligation, for example NIS2 Art. 21 or DORA Art. 25.
Key point

Auditors don't want a score, they want proof: which endpoint, which test, which result, how it was handled.

From finding to evidence

This is exactly where a traceable finding comes in: every Venedy finding brings its own record of who decided what and why. That same record becomes the compliance evidence, classified per finding under DORA and NIS2. The evidence falls out as a byproduct of the assessment, not as a separate chore. How Venedy works

Frequently asked questions

Am I affected by NIS2?

That depends on sector and company size. The BSI offers an applicability check for this. Affected companies must register with the BSI.

Is a yearly pentest enough for DORA?

For systems that support critical or important functions, DORA requires tests at least once a year (Art. 24(6)). That is the minimum. APIs change with every release, and new endpoints bring new authorization paths. Testing only once a year therefore often means testing a state that no longer exists.

Is an API data leak reportable?

Often, yes. If personal data reaches unauthorized parties, the GDPR reporting obligation within 72 hours applies, unless a risk to the data subjects is unlikely. For NIS2 entities, such an incident can additionally be a significant incident with its own deadlines. In the financial sector, the DORA reporting obligations apply.

Sources

Keep reading
SovereigntySovereignty in a Security Context RisksOWASP API Security Top 10