Which EU cybersecurity regulations apply to your organization
Start by identifying which object your business is regulated as, because these instruments regulate different things: entities under NIS2, financial ICT risk under DORA, products with digital elements under the Cyber Resilience Act, AI systems under the AI Act and personal data under the GDPR. A single company can sit under several at once, so map each activity to the object it touches before choosing a program. A financial entity should start with DORA, which has applied since 17 January 2025. Article 1(2) makes DORA the sector-specific act for financial entities identified as essential or important under NIS2, so confirm with your national competent authority how the two interact for your licence type. An essential or important entity outside finance should start with NIS2, through the national law of each member state where it operates.
A product maker should start with the Cyber Resilience Act. Its reporting obligations apply from 11 September 2026, and the main requirements apply from 11 December 2027. Products placed on the market before that date fall under the regulation only if they are substantially modified afterward, but the reporting obligations reach all in-scope products. Most products follow self-assessment under module A, while class II and critical products need a notified body. An AI provider should start with the AI Act (Regulation (EU) 2024/1689) and confirm its phased application dates in the text, since this page does not restate them. Any company processing personal data of people in the EU needs the GDPR, which already applies and requires no audit, attestation or certificate.
Doing more than one is often necessary. A bank serving EU customers may need DORA for ICT risk and the GDPR for customer data, and the evidence will overlap. Map the controls once, then reuse evidence where the legal text allows. Do not treat a framework mapping as proof of equivalence, because ENISA states its mapping is not a measure of equivalence. None of these regimes issues a certificate of compliance. Authorities supervise through inspections, audits, information requests and fines, and GDPR Article 42 certification is voluntary and does not reduce your responsibility. DeployOpen plans, implements and documents the controls and prepares the evidence a regulator or assessor will ask for, but it does not certify, attest or audit. Before committing budget, ask for the written scope and name the authority or assessor who will review the result.
How NIS2, DORA, the CRA, the AI Act and GDPR compare on scope and fines
This table compares the five EU laws by who they reach, when they apply, how they are supervised and the maximum fines. Each regime sets fines as the higher of a euro amount or a percentage of worldwide annual turnover, so check the cited article before budgeting. Most of these laws are enforced through regulator supervision rather than an organization-level certificate, so plan your evidence accordingly.
| Law | Scope and supervision | Dates and reporting | Maximum fines |
|---|---|---|---|
| NIS2 (Directive 2022/2555) | 18 sectors in Annexes I and II; essential and important entities. National authorities supervise through inspections, audits and fines, with no certificate. | Applies from 18 October 2024 (Article 41). Incident reporting obligations sit in Article 23. | Set by national law implementing the directive under Article 34. Confirm the amounts in your member state's transposition law. |
| DORA (Regulation 2022/2554) | Twenty types of financial entity under Article 2(1), plus ICT third-party providers. Supervised by national authorities, the ECB or ESAs; no certification scheme. | Applies since 17 January 2025 (Article 64). Major incident reporting sits in Chapter III; confirm any later phase-in dates in the text. | Tiered maximums in the Regulation. Confirm the article and amounts against the EUR-Lex text before relying on them. |
| CRA (Regulation 2024/2847) | Products with digital elements sold in the EU, judged against Annex I. Most self-assess; notified bodies cover class II and critical products. | Entered into force 10 December 2024. Reporting applies from 11 September 2026; main obligations from 11 December 2027. | Higher of EUR 15 million or 2.5% of turnover for Annex I and Article 13 or 14 breaches (Article 64). |
| EU AI Act (Regulation 2024/1689) | Providers, deployers, importers and distributors of AI systems on the EU market. Duties and supervision depend on the system's risk class. | Not stated here. Confirm each application date against the current consolidated text, as it has been amended. | Up to EUR 35 million or 7% for prohibited practices; EUR 15 million or 3% for most operator duties (Article 99). |
| GDPR (Regulation 2016/679) | Controllers and processors handling personal data of people in the EU. Data protection authorities supervise; no audit or certificate is required. | In application now, so no phase-in applies. Personal data breach notification to the authority is an Article 33 duty. | Up to EUR 10 million or 2% for Articles 25 to 39 breaches; EUR 20 million or 4% for core principles and transfers (Article 83). |
Which law reaches which part of the business
Each EU law starts from a different question: what kind of entity you are, what financial activity you perform, what product you place on the market, what AI you build or use, and whose personal data you handle. A single company often fails several tests at once, so answer each question separately before deciding which obligations to plan for.
Essential or important entity under NIS2
Check whether your organization operates in one of the 18 sectors covered by NIS2, split between 11 high-criticality sectors in Annex I and 7 other critical sectors in Annex II. Article 3 then classifies in-scope entities as essential or important. Both classes face the same risk-management duties under Article 21 and reporting duties under Article 23, but essential entities face ex ante supervision and important entities face ex post supervision under Articles 32 and 33. Confirm the classification with your national competent authority, because transposition laws set the details.
Financial entity under DORA
Check whether your organization is one of the financial entity types listed in Article 2(1) of DORA, which covers 20 types from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Article 2(1) also lists ICT third-party service providers in point (u), so a technology vendor to banks can be in scope. If you are a financial entity that NIS2 classifies as essential or important, Article 1(2) makes DORA the sector-specific act for that entity, so confirm which regime your supervisor applies.
Places products with digital elements
Check whether you place software or hardware with digital elements on the EU market, whether as manufacturer, importer or distributor. The Cyber Resilience Act sets essential cybersecurity requirements for product properties and vulnerability handling, and most products follow self-assessment under module A. Class I important products, class II products and critical products may need a notified body, depending on whether harmonized standards are applied in full. Products placed on the market before 11 December 2027 fall under the regulation mainly when substantially modified, but Article 14 reporting applies to them from 11 September 2026.
Provides or deploys AI systems
Check whether you provide an AI system placed on the EU market or put into service, or whether you deploy one in the EU. The AI Act assigns duties by role, so a provider, deployer, importer or distributor each carry different obligations. Article 23 sets obligations for importers, and Article 99 sets the penalty ceilings for breaches. Map each AI system to its role and risk category before assuming the same duties apply across your product line.
Processes personal data of people in the EU
Check whether you process personal data of individuals located in the EU, whether or not your company is established there. The GDPR applies to controllers and processors, and it requires no audit, attestation or certificate. Article 42 certification is voluntary, lasts at most three years and does not reduce your responsibility for compliance. Article 83 sets fines of up to EUR 20 million or 4% of worldwide annual turnover for the most serious infringements, whichever is higher, so the test should be applied to every data flow, not only to your headquarters.
What a SaaS company, a hospital and an EU bank each need to check first
A SaaS company selling into the EU may meet NIS2 directly, through its customers' contracts, or through both. The first question is whether the service itself falls into a category covered by Commission Implementing Regulation (EU) 2024/2690, which sets technical requirements for cloud computing, data center, CDN, managed service and managed security service providers. Settle that classification before any other step, because it determines which requirements you test against.
- Service classification: Confirm whether your service is a cloud computing service, a managed service or a managed security service under the Implementing Regulation, or whether it sits outside those categories.
- Member state rules: Confirm with counsel which member state's transposition law applies to your establishment and how it treats your size.
- Product obligations: Decide whether any software you ship as a product with digital elements, rather than as a hosted service, falls under the Cyber Resilience Act. Its reporting obligations apply from 11 September 2026 and the rest from 11 December 2027.
- AI features: If the platform includes AI systems, check whether the EU AI Act applies to you as provider or importer, starting with the use case.
- Processor role: Confirm whether you act as a processor for customer personal data and what your data processing terms commit you to.
Regulators do not issue a NIS2 certificate, so expect supervision through inspections, security audits, scans and information requests. Customers may still ask for a SOC 2 or ISO 27001 report, which is contractual evidence rather than a legal finding. Confirm your classification first, then map each customer's contractual demands against your legal duties.
Health care is one of the sectors listed in Annex I of NIS2, but whether a given hospital or health group is an essential or an important entity depends on national transposition, size and the services it provides. Settle that classification with your national competent authority or counsel before deciding how much of NIS2 applies. The GDPR applies to patient data whatever the NIS2 outcome, so the two questions run in parallel.
- NIS2 category: Confirm whether the organization is essential or important and whether national law adds rules for your size or sector. Both categories share the risk-management and reporting duties, but essential entities face ex ante supervision and important entities face ex post supervision.
- Reporting route: Confirm how your national authority receives incident notifications under the reporting duties in NIS2 and who inside the organization owns the decision to notify.
- Clinical software and AI: If clinical tools use AI, check whether the EU AI Act applies and which sector-specific product rules also apply. Confirm these with regulatory counsel, because they sit outside this page.
- Patient data: Map where health data is processed, which processors hold it and how each one is bound under the GDPR. GDPR certification under Article 42 is voluntary and does not reduce the controller's responsibility.
- Supplier evidence: Ask electronic health record, cloud and managed service vendors what evidence they will provide for the risk-management measures you must show.
NIS2 creates no certificate, so the evidence a supervisor reviews is your own record of risk assessments, incident handling, supplier oversight and remediation. Confirm your category first, then build the evidence pack around the duties that apply to it.
For banks and payment institutions, DORA is usually the first law to check. It has applied since 17 January 2025, and Article 1(2) makes it the sector-specific act for financial entities that are NIS2 essential or important entities, so the financial rules take priority over the general NIS2 rules for those entities. Confirm your licence category against the list in Article 2(1), which covers 20 types of financial entity, and also check whether you provide ICT services to other financial entities.
- Entity type: Confirm which of the 20 categories in Article 2(1) your institution falls under, including the exact point that applies to your licence.
- Competent authority: Confirm the national competent authority named under Article 46. The ECB supervises credit institutions classified as significant.
- ICT third-party register: List each ICT provider that supports your critical or important functions, and check whether any of them is designated as a critical ICT third-party provider under the oversight regime in Articles 31 to 44.
- Threat-led testing: Confirm whether your authority has identified you for threat-led penetration testing. The only authority-issued attestation DORA provides for is the one confirming that such a test met the requirements (Article 26(7)).
- Personal data: Map customer personal data flows and confirm how the DORA regulation text interacts with your GDPR obligations for the same systems.
DORA sets no certification scheme. Supervisors use their Article 50 powers, so expect examiners to ask for ICT risk management records, incident classifications, third-party contracts and test results. Confirm your entity category and supervisor first, then build the evidence set around the examiner's likely requests.
How DORA takes precedence over NIS2 for financial entities
For a financial entity that NIS2 classifies as essential or important, DORA sets the rules for ICT risk, ICT-related incidents and digital operational resilience testing in that sector. Article 1(2) of DORA treats the Regulation as a sector-specific Union legal act for the purposes of Article 4 of the NIS2 Directive. In plain terms, NIS2 still applies to the entity as a whole, but where DORA covers the same ICT duty, the DORA obligation is the one the entity must design its program around. Read the sector-specific ICT provisions of DORA first, then check where NIS2 adds anything on top, such as governance or supervisory treatment that DORA does not address. The two laws still meet at the edges, and that is where most questions arise. Incident reporting is the obvious example: a bank or payment institution may need to map one event against DORA's Chapter III classification and reporting process and against the NIS2 reporting framework in Article 23. DORA is a regulation, so it applies directly in every member state without national transposition. NIS2 is a directive, so its duties reach an entity through the national law that transposes it, and the wording can differ from one member state to another. Ask your national competent authority, and your counsel, how each obligation is handled for your specific entity type, and get the answer in writing.
Plan for change in both directions. Article 58(1) requires the Commission to review DORA and report to the European Parliament and the Council by 17 January 2028. The review covers, among other things, the criteria for designating critical ICT third-party providers, so the way your bank or fintech depends on cloud and software suppliers may be treated differently after that review. Confirm with your supervisor whether any interim guidance affects your register of ICT third-party arrangements, and track the NIS2 amendment proposal (COM(2026) 13) in case it changes how your entity is categorized. A written mapping of each duty to its governing law, reviewed when either text changes, is the most useful document you can keep on this question.
Who assesses compliance and what each regime produces
This table compares the five EU regimes on who checks compliance, what document or decision results, and what your organization must keep ready. Read each row across to see how little of the proof is a certificate, and plan evidence accordingly.
| Regime | Who checks compliance | What is issued | What to keep ready |
|---|---|---|---|
| NIS2 | National competent authorities, through inspections, security audits, security scans and information requests (Articles 32 to 34) | No certificate of compliance. Outcomes are inspection findings, orders and administrative fines | Evidence of risk-management measures under Article 21 and incident reporting under Article 23, ready for inspection |
| NIS2 supervision level | Essential entities face ex ante supervision; important entities face ex post supervision (Articles 32 and 33) | Same obligations for both classes, with different timing of scrutiny | Confirm your classification as essential or important with your national authority, since it changes when supervision starts |
| DORA (financial entities) | National competent authority for each entity type under Article 46, with the ECB for significant credit institutions; powers under Article 50 | No certification scheme. The only authority-issued attestation is that a threat-led penetration test met the requirements (Article 26(7)) | ICT risk framework, incident records, register of third-party arrangements and test reports that can support a supervisor's review |
| Cyber Resilience Act | Mainly the manufacturer's own self-assessment under module A for most products. A notified body is needed for class I important products where standards are not fully applied, and for class II and critical products (Article 32) | Technical documentation and an EU declaration of conformity for self-assessed products. Notified bodies issue their own conformity outcomes where they are involved | Product classification under Annexes III and IV, technical file, vulnerability handling evidence and reporting readiness. Confirm the route with the Commission FAQ |
| GDPR | Supervisory authorities enforce the regulation. No audit or attestation is required | No certificate required. Article 42 certification is voluntary, issued for at most three years, and does not reduce controller or processor responsibility | Records of processing, documented lawful basis and security measures that you can show on request, whether or not you hold a certification |
| EU AI Act | Assessment route depends on the system's risk class and provider obligations. Confirm the applicable conformity route against the current consolidated text before planning | Confirm with the current text. Do not assume a certificate exists for every high-risk system | Risk classification, technical documentation and post-market monitoring plans for systems you place on the EU market, once confirmed by counsel |
Where the work overlaps and where it does not
NIS2, DORA, the CRA, the AI Act and the GDPR overlap most where they ask for security governance, risk management and incident handling. They diverge on what is regulated, who supervises it and what proof each one produces. Use mappings to find shared work, but check each law's own text before you rely on a mapping.
Shared risk management controls
NIS2 Article 21 requires risk-management measures that many organizations already document under ISO/IEC 27001:2022 or NIST CSF 2.0. ENISA's technical implementation guidance for Implementing Regulation 2024/2690 includes mappings to both, with examples of evidence. ENISA states its mapping is not a measure of equivalence, so a mapped control still needs a check against the NIS2 requirement it is cited for.
Cross-framework control catalogs
The CIS Controls Navigator for v8.1 maps to 30 frameworks and versions, including DORA and NIS2. Use it to find candidate controls that serve both regimes, then confirm each mapping against the article text. NIST states that it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement, so the mapping is a starting point for your own review.
Incident handling and reporting
NIS2 Article 23 and DORA Chapter III both require incident detection, classification and reporting to national authorities on set timelines. The clocks, templates and thresholds differ, and the CRA adds its own manufacturer reporting from 11 September 2026. Build one incident process with a mapping of which report goes to which authority, and confirm each deadline in the source text.
Third-party ICT and supplier oversight
DORA Article 28 requires financial entities to manage ICT third-party risk, and NIS2 expects supply chain security from in-scope entities. Both push contract terms, provider assessments and exit planning down to suppliers. Check whether the same supplier file can answer DORA register questions and NIS2 supply chain expectations without separate evidence sets.
Product requirements the CRA adds
The CRA's Annex I sets essential cybersecurity requirements for products with digital elements, and Part II lists eight vulnerability handling requirements for manufacturers. Control mappings built for an organization's internal systems do not cover these product properties or the support periods that come with them. Software and hardware makers should scope product security work separately from corporate ISMS work.
Personal data rights the GDPR covers
The GDPR governs lawful basis, data subject rights, transfers and processor contracts, and it requires no audit or certificate. Article 42 certification is voluntary and does not reduce the controller's or processor's responsibility. A security control mapping can show that data is protected, but it does not answer access requests, erasure or lawful basis, so privacy work needs its own owner and records.
In what order to work through the EU regulations
This sequence turns five overlapping EU laws into one working plan, so a company can confirm which laws reach it, classify its entities and products, and build one body of evidence that serves several regimes.
Confirm scope for each law with counsel
Before any technical work, ask counsel to confirm, law by law, whether the company is in scope of NIS2, DORA, the Cyber Resilience Act, the AI Act and the GDPR. Each law uses different triggers: NIS2 looks at sector and size, DORA at the type of financial entity, the CRA at products with digital elements, the AI Act at AI systems placed on the market or used, and the GDPR at processing of personal data. Confirm also whether DORA applies to a financial entity that is also a NIS2 entity, since Article 1(2) makes DORA the sector-specific act for that case. The output is a written scope memo, signed off by counsel, listing each law, the reason it applies or does not, and the people accountable for each decision.
Classify entities, sectors and products
Once scope is settled, record the sector annex each NIS2 entity falls under and whether it is classified as essential or important. For a financial group, record which DORA entity types are involved and which national competent authority supervises each one. For manufacturers, list each product with digital elements and its CRA class as described in the Commission's technical descriptions, and for AI, list each system and its role as provider, deployer, importer or distributor. Confirm the classification with the relevant national authority or counsel where the text leaves room for interpretation. The output is one inventory that links each entity, product and AI system to the laws that apply to it.
Map shared controls to NIS2 Article 21 and DORA
Map the company's existing ICT and security controls to the NIS2 Article 21 risk-management measures and, for financial entities, to the DORA ICT risk management, testing and third-party requirements. Use the ENISA technical guidance and the Commission Implementing Regulation (EU) 2024/2690 as reference for expected evidence where they apply to the entity type. Tag each control with the law it serves and whether it serves several. Expect gaps around third-party oversight and testing, which both laws address. The output is a control register with gaps, owners and evidence locations. Treat mappings as working aids: ENISA states its mapping is not a measure of equivalence, so confirm coverage against the legal text.
Add product and AI obligations where they apply
For products in CRA scope, map the Annex I essential cybersecurity requirements and the vulnerability handling requirements to the product's design, release and support processes, and confirm which conformity assessment route applies, since most products follow self-assessment under module A while some classes need a notified body. For AI systems in scope, map the AI Act obligations for the role the company holds, and confirm the timing against the regulation's own application dates in the current legal text. Where an AI system processes personal data, link its technical documentation to the GDPR records. The output is a product and AI obligations register with named owners and the evidence each requirement produces.
Align GDPR records with security evidence
Connect the GDPR accountability records to the security evidence built so far. Article 32 security measures, breach records and processor contracts often overlap with NIS2 and DORA risk controls and incident logs. Link the record of processing, data protection impact assessments and processor register to the control register, so one data flow is not documented three different ways. Remember that the GDPR requires no certificate, and that any voluntary Article 42 certification does not reduce the controller's or processor's responsibility. The output is a cross-reference table that ties each personal data process to its security controls and its processor evidence.
Build reporting runbooks against the supplied clocks
Write one incident reporting runbook per law that applies. For NIS2, use the Article 23 reporting obligations; for DORA, the incident classification and reporting rules in Chapter III; for the CRA, the Article 14 reporting obligations, which apply from 11 September 2026 and cover manufacturers' notifications through the CRA Single Reporting Platform; and for the GDPR, breach notification. Take the exact deadlines from the current legal texts and national transposition measures, not from summaries. Map which notification goes to which authority, and where one incident triggers several, pre-assign the owner who files each one. The output is a set of runbooks, a contact register for each authority and a tabletop test record.
Set dates and confirm national transposition
Build a single calendar with the dates from the legal texts: NIS2 applied from 18 October 2024 under Article 41 as transposed nationally, DORA has applied since 17 January 2025, the CRA's Article 14 obligations apply from 11 September 2026, and most CRA obligations and the Article 71(2) general application date fall on 11 December 2027. Check each national NIS2 transposition law, because the company's obligations depend on how its Member State adopted and enforces the directive. Monitor the Commission's July 2026 proposal to amend NIS2 (COM(2026) 13), which remains a proposal until approved. Assign an owner to review the calendar on a fixed cycle. The output is a dated obligations calendar with the source of each date and a record of the national measures checked.
Keep one evidence library across all laws
Store evidence once and tag it to every requirement it satisfies. Typical shared items include risk assessments, asset inventories, access reviews, vulnerability and patch records, supplier due diligence files, penetration test reports, incident logs and training records. For DORA, the only authority-issued attestation in the text is the one that a threat-led penetration test met the requirements (Article 26(7)), so keep that letter with the test file. Do not present internal records as certificates, since NIS2, DORA and the GDPR create no certification scheme of their own. The output is a single evidence index that a supervisor, auditor or counsel can read in one pass, with a review date for each item.
What buyers ask before they hire outside help on EU regulations
Which EU cybersecurity law applies first to our company?
It depends on what you make, what you run and who you are, so the first step is classification, not a framework. NIS2 applies to entities in 18 sectors, split into 11 high-criticality sectors in Annex I and 7 other critical sectors in Annex II. DORA applies to 20 types of financial entity under Article 2(1). The Cyber Resilience Act applies to products with digital elements placed on the EU market, and the AI Act applies to AI systems. The GDPR applies whenever you process personal data of people in the EU. Several can apply at once. Before any work starts, confirm scope in writing with a lawyer or your national competent authority, then sequence the work around the regulation with the nearest deadline that applies to you.
Does a certificate prove NIS2 or DORA compliance?
No. Neither law creates a certificate of compliance. NIS2 is overseen by national competent authorities through inspections, security audits, security scans, information requests and administrative fines (Articles 32 to 34). DORA is supervised by competent authorities using the powers in Article 50, and the only authority-issued attestation it provides for is the attestation that a threat-led penetration test met the requirements (Article 26(7)). Any vendor offering a 'NIS2 certificate' should be asked which accredited body issued it and what legal standing it has. DeployOpen does not issue certifications, attestations or audit reports. We prepare controls, documentation and evidence so your supervisor or your independent auditor can assess them.
How does a DORA-regulated bank handle NIS2?
Under Article 1(2) of DORA, the regulation is a sector-specific Union legal act for the purposes of Article 4 of NIS2 for financial entities identified as essential or important entities under NIS2. In practice, a bank or other in-scope financial entity should plan its ICT risk, incident reporting and testing work against DORA, and confirm with its supervisor which NIS2 obligations remain for it. Do not assume the two regimes are simply duplicated. Map each DORA chapter (ICT risk management, incident management, resilience testing, third-party risk) to the NIS2 article it overlaps with, then record where the sector-specific rule governs. Ask your legal counsel to confirm the position for your entity type and member state.
What drives the cost of EU regulatory work, and who pays for what?
Cost has two parts: the external work you buy (classification, gap analysis, remediation, documentation, testing, training) and your own staff time, which does not disappear when you hire help. The main drivers are the number of in-scope entities and legal entities, the number and type of products or ICT services, how much of the required control evidence already exists, how many systems and third parties are in the boundary, and what your supervisor or a regulator is expected to ask for. DeployOpen does not publish a price list. Costs follow from a written, fixed-scope proposal. Ask for the deliverables, the entities and systems covered, the evidence to be produced, the assumptions about existing controls, what is one-time and what is a recurring retainer, and which items you must provide.
How long does readiness take, and what does it depend on?
Readiness time depends on the starting point, not on a fixed period, and no DeployOpen duration applies until a scope is agreed in writing. Key dependencies are how current your asset inventory and risk register are, how many systems and suppliers must be assessed, whether incident reporting procedures have been tested, and the application dates that apply to you. The CRA's reporting obligations apply from 11 September 2026, and most of its other obligations apply from 11 December 2027. DORA has applied since 17 January 2025, and its Article 14 reporting obligations apply from 11 September 2026. Ask any provider to tie the timeline to a named regulatory date and to list the milestones the client must meet.
What does the work need from our own staff?
Expect ongoing input from a named executive sponsor, a compliance or risk owner, system owners, the people who run incident response and the owners of key ICT suppliers. The external team can draft policies, map controls, run tests and prepare evidence, but decisions on risk acceptance, supplier contracts and reporting thresholds stay with your board and management. Ask the provider to list every client role, the hours or meeting cadence they expect, and the decisions that need sign-off. Missing input is the most common reason a fixed-scope plan slips, so agree who is responsible for each deliverable before work begins.
Can our internal team do this without outside help?
Often yes for a small, single-jurisdiction entity with a mature security program and staff who know the regulation well. Internal teams usually struggle with three things: cross-mapping overlapping obligations, producing evidence that holds up to an independent review, and running resilience testing and third-party reviews at the depth the regulator expects. A useful test is whether you can name the owner, control and evidence for every requirement in the scope and show them to a reviewer. Where you cannot, outside help can fill the gap for specific deliverables while your team keeps ownership of the program.
How do DORA and NIS2 fines compare?
Both regimes set fines as the higher of a fixed amount or a percentage of worldwide annual turnover, but the figures differ. Under Article 64 of DORA, the maximums are EUR 15 million or 2.5% for breaches of Annex I and Articles 13 and 14, EUR 10 million or 2% for other listed obligations, and EUR 5 million or 1% for incorrect or misleading information to authorities. Under NIS2, the sources supplied here do not set out a single equivalent table, so confirm the NIS2 maximums in the national transposition law that applies to you, and check with counsel how the sector-specific rule affects a DORA-regulated entity. Under GDPR Article 83, the maximums run to EUR 20 million or 4% for the most serious infringements. Fines are not the only exposure, so also weigh supervisory measures and reputational effects.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares the systems, controls and evidence that EU regulatory readiness work depends on. We do not issue audit reports, attestations or certifications, so the regulator, notified body or independent auditor named by each regime remains the source of any formal outcome.
How we scope
- Start by confirming which entity types, products or AI systems your organization falls under before any build work begins.
- Written scope names the regulations covered, the systems in each boundary and the evidence each deliverable will produce.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Implement and configure the self-hosted platforms in your cloud accounts, data centers or air-gapped networks that hold in-scope controls.
- Test applications, APIs, cloud and infrastructure against the controls each regulation requires, with findings tracked to closure.
- Map each control to the articles of each regulation so overlaps between NIS2, DORA, the CRA, the AI Act and the GDPR are documented once.
How we hand over
- Deliver written documentation of configurations, control owners, evidence locations and the assumptions behind each mapping.
- Provide evidence packs that your compliance lead and independent assessors can review, without us stating any conclusion of compliance.
- Confirm with your regulator, notified body or auditor which evidence they expect, since their requirements decide what is sufficient.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover platform upgrades, evidence refreshes and re-testing when systems or regulatory guidance change.
- Ask for the retainer scope in writing, including response expectations and which regulatory updates are covered.
Sources and further reading
- NIS2 Directive: securing network and information systems, European Commission ↗
- Directive (EU) 2022/2555 (NIS2), EUR-Lex ↗
- Regulation (EU) 2022/2554 (DORA), EUR-Lex ↗
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex ↗
- Cyber Resilience Act implementation, Shaping Europe's digital future ↗
- NIS2 Technical Implementation Guidance (June 2025), ENISA ↗
