DORA non-compliance can expose a fintech to supervisory intervention, national penalties and expensive operational remediation. It does not create one universal turnover-based fine for every financial entity. To estimate exposure, first identify the entity’s regulatory category, the applicable national enforcement rules and the specific control failures. Then assess the disruption and corrective work those failures could cause.
This guide separates the legal mechanisms from the business costs. It explains why the periodic penalty payment for a designated critical ICT provider is different from a financial entity’s sanction, and how to build an evidence-based budget without inventing a fine percentage or assuming every breach leads to licence withdrawal.
Establish whose DORA obligations you are costing
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 2 identifies the financial entities within its scope, including payment institutions, electronic money institutions, investment firms and certain crypto-asset service providers. It also contains exclusions and interacts with sector-specific definitions. “Fintech” is a business description, not a regulatory category that settles applicability.
A regulated payment institution, a technology supplier to a bank and a group company providing internal IT services may therefore have different obligations and enforcement exposure. A supplier does not become a designated critical ICT third-party provider merely because a customer considers its software important. Designation under Article 31 is a separate supervisory process. Contractual requirements from regulated customers must also be distinguished from obligations imposed directly on the supplier.
Record the legal entity, authorisation category, competent authority and relevant national rules before assigning a financial value to a failure. Group revenue alone does not identify the applicable sanction regime. For a business holding several permissions or operating through several entities, analyse the affected activities and allocation of responsibility. The guide to DORA for banks and financial institutions provides additional sector context, but the costing decision should follow the entity’s actual permissions.
Financial-entity penalties depend on national rules
Articles 50–54 establish supervisory powers and a framework for administrative penalties and remedial measures. Article 50 requires Member States to establish appropriate rules and make their application effective. The measures must be effective, proportionate and dissuasive. It does not establish a universal maximum fine of two percent of worldwide turnover for financial entities.
National authorities must have powers to obtain relevant documents and data, investigate, inspect and require corrective or remedial action. Measures include orders to end an infringement, cessation of unlawful practices, pecuniary measures and public notices identifying an infringement. The applicable national legislation determines the detailed sanction framework and procedure. Some infringements may instead be subject to criminal penalties under the national approach permitted by Article 52.
Article 51 requires consideration of relevant circumstances, including gravity, duration, responsibility, financial strength, benefits or avoided losses, losses to third parties, cooperation and previous infringements. Intent or negligence also matters. A legal ceiling is consequently not a prediction of the amount imposed, and multiplying annual revenue by an unsupported percentage is not a defensible forecast.
For budgeting, maintain a short legal assessment identifying the jurisdiction, the rule breached, the potential measures and any material uncertainty. Obtain advice on that framework when an actual exposure arises. Use the broader DORA penalties and enforcement guide to organise the questions, while verifying the national provisions relevant to the entity. Avoid combining incompatible maximum amounts from several countries as though all necessarily apply to one incident.
Management responsibility is real, but no universal director fine exists
Under the ordinary ICT risk management framework, Article 5 assigns the management body responsibility for defining, approving and overseeing the framework and its implementation. It addresses governance, resources, risk tolerance, continuity arrangements, third-party arrangements and maintaining appropriate knowledge and skills. Buying software or appointing a security lead does not transfer those management responsibilities to the supplier or employee.
Article 50(5) requires powers to apply relevant sanctions or corrective measures to management-body members and other responsible individuals under the conditions established by national law. It does not set a universal one-million-euro fine for every director. Personal exposure requires analysis of the national legal basis, the individual’s responsibility and the circumstances, rather than automatic attribution to everyone attending a board meeting.
A useful management record explains the known issue, its operational significance, the proposed measures, resources, owner and outstanding limitations. Minutes that simply declare the organisation compliant provide little help if known recovery failures remain unresolved. Training should allow decision-makers to challenge assumptions about dependencies and recovery, with its depth proportionate to the risks they oversee.
Article 16 replaces Articles 5–15 for its specified categories with a simplified ICT risk management framework. That distinction should remain visible when mapping management duties: do not quote every ordinary-framework provision as directly applicable to an entity governed by Article 16. The simplified framework nevertheless requires documented risk management, continuity measures, testing and improvements; it is not permission to leave responsibility undefined.
Critical-provider periodic payments are a separate mechanism
Article 35 concerns the Lead Overseer’s powers over designated critical ICT third-party service providers. Its periodic payment mechanism is designed to compel compliance with specified information, investigation, inspection and follow-up reporting measures under Article 35(1)(a)–©. It is not a daily charge automatically imposed on every financial entity experiencing an outage or every supplier with an uncorrected vulnerability.
Under Article 35(6), the decision follows failure, in whole or in part, to comply with the required measures and expiry of at least 30 calendar days after the provider received their notification. The payment can reach one percent of the provider’s average daily worldwide turnover in the preceding business year. It is imposed daily until compliance, for no more than six months from notification of the decision imposing it.
The amount is calculated from the date specified in the decision. The framework considers seriousness, duration, intent or negligence and cooperation, and provides an opportunity to be heard and rights of defence. There is no separate general five-million-euro ceiling in this mechanism, and extrapolating the daily figure across a whole year disregards its six-month limit.
A fintech using the provider should therefore separate the provider’s potential payment from its own exposure. The commercial contract may allocate some costs or create specific remedies, but it does not change the legal addressee of the supervisory measure. Assess dependency, continuity and exit capability rather than simply adding the provider’s possible payment to the fintech’s own regulatory budget.
Service restrictions can create substantial migration costs
Article 42 provides a follow-up process where risks identified through oversight of a critical provider are not adequately addressed. As a last resort, following the prescribed notification and, where relevant, consultation, competent authorities can require financial entities to suspend use or deployment of a service, partly or entirely, and where necessary terminate relevant contractual arrangements.
That is different from a provision automatically withdrawing a financial entity’s operating licence. Any authorisation consequence must be established under the relevant sectoral and national legal framework. Equally, the absence of an automatic DORA licence-withdrawal rule does not make a service restriction commercially harmless. A dependency can be essential to executing customer transactions or maintaining access to records.
Article 42 requires consideration of continuity risks and time for financial entities to adapt arrangements and implement exit strategies and transition plans. Costing should reflect that process rather than assume an instantaneous forced migration in every case. Examine data export, replacement capacity, integration, testing, customer communications and the period during which both environments must operate.
The practical question is whether the proposed alternative can support the affected function with acceptable risk. An exit document naming another cloud supplier is incomplete if the application cannot run there or the data cannot be reconciled after transfer. Connect the financial estimate to the evidence required by DORA third-party risk management: contractual rights, service dependencies, monitoring and the feasibility of the relevant exit arrangement.
Do not assume enforcement always starts with a warning
An authority may request information, investigate, require correction or impose measures according to its powers and the applicable procedure. DORA does not promise every financial entity a standard sequence of informal warning, free remediation period and then a fine. A risk assessment should not rely on receiving an additional grace period before an existing duty matters.
At the same time, investigation, an identified deficiency, a remedial order and a final sanction are different events. Keep a record of what the authority actually requested and the procedural status. Assign someone to coordinate accurate responses, preserve relevant material and reconcile technical descriptions with the evidence. Contradictory explanations can consume time and make it harder to demonstrate that a control has been repaired.
Publicity also has conditions. Article 54 addresses publication of administrative sanction decisions, including final decisions and information about appeals where appealable decisions are published. It provides for delayed, anonymous or withheld publication in specified circumstances. A budgeting model should consider possible disclosure and communications work without assuming every supervisory exchange immediately becomes a public naming exercise.
Build the operational cost estimate around a concrete failure
Start with a failure scenario supported by the organisation’s architecture and risk assessment. For example, assume a payment service cannot restore a critical database within its required recovery arrangements because a dependency was omitted from the recovery procedure. This is a hypothetical planning example, not a reported enforcement case or a prediction that an authority will impose a particular sanction.
Estimate the investigation and repair work: staff time, specialist support, replacement infrastructure, data validation and repeat testing. Distinguish work needed to restore the service from work needed to correct the underlying control. An emergency restoration may succeed while leaving monitoring, documentation or vendor access arrangements unresolved. Cost both stages without treating them as the same deliverable.
Next assess the service consequences. The relevant losses depend on actual contracts, customer impact, business volume and recovery duration. Service credits, compensation, missed transactions and support demand should be linked to those facts. Do not turn all delayed transactions into permanently lost revenue, or assume every dissatisfied customer will leave. State the assumptions and show how the result changes with a longer or shorter disruption.
Finally identify constraints on the response. The same engineers may be needed for recovery, evidence gathering and a planned product launch. Overtime, temporary help and deferred work have different financial effects. Record them separately so that management can understand the resource bottleneck. A credible estimate can use ranges grounded in supplier quotations and internal workloads without claiming that those ranges are industry averages.
Compare remediation options without double counting
Separate one-off implementation from recurring operation. Rebuilding a recovery process, renegotiating a contract and migrating a service are different from regularly maintaining records, monitoring suppliers and testing controls. Allocate shared effort consistently: the same incident response exercise should not be charged in full to several compliance programmes merely because it produces evidence for each.
Compare options against the risk they address. A tool may make an ICT risk management framework easier to maintain, but it does not establish whether a restore works or whether a supplier will support an exit. Likewise, an expensive assessment is not automatically more effective than a focused technical repair followed by appropriate validation. Specify the outcome and evidence before comparing proposals.
Testing costs require particular care. DORA provides a testing programme with proportionality and differentiated requirements; advanced threat-led penetration testing applies to entities identified under the relevant criteria and process, not to every small fintech. The resilience testing and TLPT guide helps distinguish the workstreams. Do not budget universal advanced testing simply because a supplier presents it as a standard package.
A small team may use outside expertise for a defined gap while retaining accountable internal owners. Evaluate the cost of supplying accurate inputs, reviewing deliverables, operating the resulting process and updating it later. The cheapest initial document package can become costly if nobody can maintain it or demonstrate its relationship to the actual systems.
Proportionality changes implementation, not the need to assess scope
Article 4 links implementation to size, overall risk profile and the nature, scale and complexity of services, activities and operations, as specified in the relevant requirements. A low headcount does not necessarily imply low operational risk. A narrowly staffed entity can support a service whose outage has significant consequences or depend on a difficult-to-replace provider.
The simplified Article 16 framework applies to specified categories, including small and non-interconnected investment firms, exempt payment and electronic money institutions and small occupational retirement institutions, subject to the provision’s terms. It is not a general exemption for businesses below an invented revenue threshold. Document why the entity falls within the category instead of inferring eligibility from a marketing label such as startup.
Use that assessment to size processes and resources. A proportionate arrangement should still identify important dependencies, maintain suitable continuity arrangements and establish evidence that the controls operate. The DORA compliance guide can structure the initial gap assessment. Prioritisation should follow operational impact, legal duties and feasible corrective measures rather than a generic list of expensive purchases.
Coordinate DORA and GDPR without treating them as one regime
An ICT incident can raise both DORA and GDPR questions where personal data are affected, but the regimes have different scope, triggers and enforcement frameworks. A technical availability problem is not automatically a reportable personal-data breach. A financial entity must examine the facts and the relevant obligations rather than presume that filing one report satisfies both systems.
Where GDPR Article 33 applies, notification is required without undue delay and, where feasible, within 72 hours after awareness, unless the personal-data breach is unlikely to create a risk to individuals’ rights and freedoms. A late notification must explain the reasons. Every personal-data breach must be documented, while Article 34 communication to individuals is a separate high-risk assessment subject to its conditions and exceptions.
Shared incident facts, timelines and corrective evidence can reduce duplicated work, but decision records should identify which legal test was applied. The DORA and GDPR overlap analysis supports that separation. The existence of GDPR fines does not establish an equivalent DORA tariff, an average expected penalty, or automatic cumulative maximum fines for a single event.
Make the budget reviewable by management
Present management with the specific deficiencies, the services affected, proposed remedies, accountable owners, delivery dependencies and evidence needed to close each item. Identify which costs are supported by quotations or measured effort and which remain uncertain. Keep any national penalty assessment separate from the operational cost forecast so that one uncertain legal figure does not obscure a well-supported recovery problem.
When considering software, use the DORA software buyer’s guide to frame evidence and workflow requirements, and the discussion of tools for startups and fintechs to examine maintainability with limited staff. Ask what information must be entered, what can be exported, and how an owner verifies completion. A subscription is one budget line; it is not proof that the organisation can continue its critical services or satisfy a supervisory request.