What DORA compliance costs, and why two firms pay very different amounts
No official price for DORA compliance exists. The Commission's impact assessment (SWD(2020) 199) found that one-off costs come mainly from IT investment and are hard to quantify because firms' legacy systems differ widely. It expected low implementation costs for large firms, which had already invested heavily in ICT, and lower costs for smaller firms subject to proportionate measures. DORA has applied since 17 January 2025, so the question now usually arrives from a board, a supervisor or a customer that wants to know what the gap will take to close. Budget owners should treat any single figure with caution and ask for a cost build-up instead.
The real cost depends on four things: the type of financial entity under Article 2(1), the current state of ICT systems and their documentation, the number of ICT third-party services that support critical or important functions, and whether threat-led penetration testing (TLPT) applies to the entity. A microenterprise or an entity on the simplified regime under Article 16(1) carries a different workload from a bank that must run TLPT every three years. Recurring items drive long-term spend: the yearly framework review (Article 6(5)), yearly testing of systems supporting critical or important functions (Article 24(6)), yearly continuity plan testing (Article 11(6)) and maintenance of the register of information (Article 28(3)). Ask any partner to split its quote into one-time and recurring lines against these items.
Roles also shape the bill. The organization owns its controls and decides how much risk to accept. An implementation partner, if one is engaged, prepares systems, documentation and evidence under a written, fixed scope. Only the competent authority supervises compliance under Article 50, and no auditor or certifier issues a DORA certificate, so a quote should not promise one. Confirm with your supervisor which evidence it expects and how often it asks for it. Before signing, ask the partner to state what is excluded, which assumptions drive the estimate, and what changes the price if legacy systems turn out to be more complex than expected.
Who gets paid for what in a DORA programme
This table lists each cost component of a DORA programme, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to see which costs stay in-house, which go to outside parties and which recur every year after the first implementation.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal staff time | Own employees across the management body, compliance, IT, security and procurement | Both: the first gap closure is one-time, and ongoing duties recur | Size of the legacy estate, number of critical or important functions, and how many contracts need review |
| Implementation partner | External firm preparing systems, policies, the register of information and evidence | Mostly one-time, with optional retainers for later updates | Scope agreed in writing, state of existing documentation, and number of systems and ICT services in scope |
| Security testing providers | Firms running the basic and advanced tests that Article 24 and the testing programme require | Recurring, with yearly testing of systems supporting critical or important functions (Article 24(6)) | Number and complexity of systems tested, depth of scope, and whether ICT providers take part in the tests |
| Continuity plan testing | Internal teams, and external facilitators where the organization buys them | Recurring, with yearly continuity plan testing (Article 11(6)) | Number of critical functions with plans, whether tests simulate third-party failures, and how much recovery work each test uncovers |
| Framework review | Internal staff, with optional external support for the review report | Recurring, with a yearly review of the ICT risk management framework (Article 6(5)) | Frequency of change in systems and providers, and the volume of findings to track |
| Register of information | Internal staff or the implementation partner, plus data collection from providers | Recurring, with maintenance of the register (Article 28(3)) | Number of ICT contracts, quality of provider data, and how often contracts change |
| Threat-led penetration testing (TLPT) | Accredited testers, threat intelligence providers and internal coordination staff | Recurring for identified entities, at least every 3 years with at least 12 weeks of active red team testing | Scope set by the authority, pooled testing with other entities (Article 26(4)), and the number of live systems in scope |
| Tooling and licences | Software vendors and cloud providers, including open-source platforms run in-house | Mostly recurring subscriptions, with one-time setup | Number of users and assets, logging volume and whether tools are self-hosted or bought as a service |
| Independent review | Internal audit function or an external assessor chosen by the organization | Recurring, with optional third-party verification under Article 6(10) | Whether the entity is a microenterprise, the extent of outsourced verification and the depth of the review |
Which factors make DORA compliance cost more or less
DORA cost is set less by the Regulation's headline requirements than by the state of an entity's systems, the number of providers it depends on, and how far it qualifies for proportionality. The six drivers below are the ones an organization can influence before it asks for a quote, so each card names a decision to make or a check to run.
Scope of ICT systems supporting critical functions
The more systems that support critical or important functions, the more they must be documented, tested every year and covered by the continuity and incident processes. Map which applications, data flows and infrastructure actually sit behind those functions before asking for a quote. Consolidating overlapping platforms can shrink the set that needs yearly testing, but only if the functions themselves are re-scoped with the business owners and documented.
Legacy state of systems
The Commission's impact assessment treats the state of legacy systems as the main source of uncertainty in one-off costs, because firms start from very different points. An estate with unsupported software, undocumented configurations or manual controls will cost more to bring to the required standard than a modern, well-documented one. Before scoping, ask for an inventory of end-of-support components and a short technical review, so the quote reflects real remediation work rather than an assumption.
Providers and the register of information
Each ICT provider adds contract reviews, due diligence, exit planning and a line in the register of information, which must be maintained as a recurring duty. The count matters, and so does data quality, since incomplete or inconsistent provider records force rework before any submission. Clean up the provider list, confirm identifiers and remove retired services before onboarding a new partner, so the register work is priced on a stable baseline.
Evidence maturity
Supervisors check whether controls operate, not only whether policies exist. An entity with logs, tickets, test results and management sign-offs already in place needs to package evidence rather than create it, which is far cheaper than building a record from scratch. Assess how easily you can produce evidence for each ICT risk area today, and flag gaps that will need new tooling or recurring activity. Ask any implementation partner to state which evidence it will prepare and which remains your responsibility.
Identification for TLPT
Entities identified for threat-led penetration testing face the most expensive testing regime in DORA, with active red team testing of at least 12 weeks and a cycle of at least every three years. The ESA estimate that such testing costs between 0.1 % and 0.3 % of the total ICT budget is the reference point for planning. Confirm early whether your competent authority has identified you, because that decision changes the budget far more than any other single driver.
Entity size and category
Microenterprises are relieved of the independent ICT risk control function, internal audit of the framework and the Article 24 testing duties, and entities under Article 16(1) follow the simplified framework. These relief measures can lower cost substantially, but only if eligibility is confirmed in writing before the scope is fixed. Check your category under Article 2 and the thresholds in Article 4 and Article 16(1), and do not assume relief from size alone.
What the Commission's impact assessment figures do and do not tell you
The figures in the Commission's impact assessment (SWD(2020) 199) are useful context, but they are not a budget for your entity. The impact assessment itself says one-off costs come mainly from IT investment and are difficult to quantify because firms' legacy systems differ widely. It also expects large firms to face low implementation costs because they already invested heavily in ICT. Use the figures to understand the shape of the problem, not to set your spending. The one ratio you can apply directly comes from an ESA estimate cited in the same impact assessment: threat-led penetration testing costs between 0.1 % and 0.3 % of the total ICT budget of the firms concerned. Treat this range only as a sense check. Divide your annual ICT budget by your own estimate, then ask whether your TLPT plan, if you are in scope, falls inside that band. If it falls well outside it, check the scope, the number of live production systems in the test and whether a pooled or joint test could apply. Note that this is a ratio across the sector's firms, not a rule for your organization, and the figure predates the final technical standards.
The larger numbers describe benefits to the sector, not costs to your firm. The impact assessment estimated that removing overlapping incident reporting could save some of the largest banks between EUR 40 million and EUR 100 million per year, and that a common testing approach could bring the 44 largest cross-border banks total benefits of EUR 11 million to EUR 88 million. The industry assessments it cites put the cost of operational incidents for the EU financial sector at between EUR 2 billion and EUR 27 billion per year. None of these is an entity's compliance budget. Do not put them in a business case as expected savings or as a measure of what your programme will cost. When a board asks how big the investment should be, the defensible answer comes from your own scope, your current systems and written quotes from the parties who will do the work. Ask each provider to state which DORA obligations its price covers, which recur each year and which are one-off. The impact assessment's figures can frame that discussion, but they cannot replace it.
How recurring costs differ by entity situation
Large credit institutions with extensive legacy systems carry the full set of recurring DORA obligations, and most of their ongoing spend sits in the systems that support critical or important functions. The Commission's impact assessment expected implementation costs for large firms to be low because of past ICT investment, but that expectation rests on the state of each firm's estate, so your own legacy inventory is the deciding factor. Recurring duties include the yearly framework review under Article 6(5), yearly testing of systems supporting critical or important functions under Article 24(6), yearly continuity plan testing under Article 11(6), and maintenance of the register of information under Article 28(3). If the entity is identified for threat-led penetration testing, that cycle runs at least every three years with at least 12 weeks of active red team testing.
- Full framework review: The yearly review under Article 6(5) draws on incident data, testing results and changes to the estate, so cost rises with the number of systems and providers in scope.
- Testing of critical systems: Yearly testing of systems supporting critical or important functions is the largest recurring line for many legacy estates, especially where remediation work follows each test.
- Register upkeep: Maintaining the register of information across many contracts and subcontracting chains is ongoing administrative work, not a one-time exercise.
- Threat-led testing: Where the entity is identified, the three-year cycle and 12 weeks of active red team testing drive a significant cost, which the ESA estimate of 0.1 % to 0.3 % of total ICT budget helps frame.
- Legacy remediation: Older platforms may need compensating controls or replacement, and those costs recur until the estate is modernized.
Ask any quote to split one-time remediation from yearly testing, review and register work, and to state which systems are treated as supporting critical or important functions.
A small entity on the standard regime keeps the full core obligations but usually has a smaller estate and fewer providers, so recurring cost is driven more by repeated process work than by system scale. The standard regime does not relieve these entities of the Article 6 framework review or the Article 24 testing programme. Recurring work therefore includes the yearly framework review, yearly testing of systems supporting critical or important functions, yearly continuity plan testing, and register maintenance. Because the entity is not microenterprise-sized, it cannot delegate testing duties to a third party as a relief, though it can still outsource specialist work.
- Yearly framework review: The review under Article 6(5) recurs at the same depth as for larger firms, so a small team pays for the same activity in fewer hours.
- Systems testing: Yearly testing under Article 24(6) applies to systems supporting critical or important functions, and scope is often limited to a few platforms.
- Continuity testing: Yearly continuity plan testing under Article 11(6) recurs and often needs an external facilitator when internal staff are thin.
- Register upkeep: Register maintenance under Article 28(3) recurs even with few providers, because each contract change must be reflected.
- Outsourced verification: Article 6(10) allows outsourcing verification of compliance with the ICT risk management requirements, while the entity remains fully responsible.
Confirm with your competent authority whether any proportionality option applies to your entity type, and ask a provider to price the recurring items separately from the initial build.
Microenterprises receive the most relief among the situations on this page. Under Article 6(4) and 6(6), they do not need an independent ICT risk control function or an internal audit of the framework. They are also relieved of the Article 24 testing programme duties, and under Article 30(3) they may delegate audit rights over ICT providers to an independent third party. The remaining recurring obligations still include maintaining the framework, managing ICT providers and keeping the register of information under Article 28(3). Recurring cost therefore concentrates in the few tasks that remain, and in the fees paid to any third party that holds delegated audit rights.
- No independent control function: The relief under Article 6(4) removes a standing internal role, so the recurring cost of that function does not arise.
- No internal audit of the framework: Article 6(6) removes the recurring audit of the framework, which is often the most expensive yearly item for small firms.
- No Article 24 testing programme: The testing programme duties are not required, though the entity should still confirm which basic checks apply to its own systems.
- Delegated audit rights: Under Article 30(3), an independent third party can hold audit rights over a provider, so the fee for that service becomes a recurring cost to compare.
- Register maintenance: Register upkeep remains, and it is usually the largest administrative item left for a microenterprise.
Before relying on relief, confirm with your competent authority and your legal advisers how microenterprise status is established for your entity.
Entities under Article 16(1) follow the simplified ICT risk management framework set out in Title III of Delegated Regulation (EU) 2024/1774. They are excluded from threat-led penetration testing and from the ICT third-party risk strategy requirement. Recurring cost is therefore shaped by the simplified framework itself, which keeps the core governance and risk management elements while removing the heavier layers. Because the simplified regime is defined by the Regulation's criteria, first confirm that the entity actually falls under Article 16(1) before you plan around its reduced duties, since the categories and their conditions determine which obligations remain.
- Simplified framework: Title III of Delegated Regulation (EU) 2024/1774 sets the simplified requirements, so the recurring work follows that text rather than the full Chapter II set.
- No TLPT: The exclusion from threat-led penetration testing removes the three-year cycle and its active red team cost.
- No third-party strategy requirement: The entity is excluded from the ICT third-party risk strategy requirement, which lowers recurring governance work on provider strategy.
- Remaining contract and register duties: Obligations for ICT contracts and the register of information continue to apply where they are not expressly removed.
- Verification of the simplified framework: The entity still needs evidence that the simplified controls operate, and the cost of that evidence recurs each year.
Confirm the exact scope of the simplified regime for your category with your competent authority, and ask any provider to show which requirements its quote assumes still apply.
What critical providers pay in oversight fees, and how TLPT is shared
The oversight fees for critical ICT third-party service providers fall on the provider, not the financial entity, but they can reach your budget through contract pricing. The Commission's proposal COM(2020) 595 stated that oversight of critical providers would be funded by fees charged to those providers. Delegated Regulation (EU) 2024/1505 sets the annual oversight fee scaled to the provider's turnover, with a minimum of EUR 50 000, and a EUR 50 000 opt-in fee for providers that apply voluntarily for designation. The ESAs' estimated cost for their new DORA tasks, about EUR 30.19 million for 2022 to 2027 including 18 full-time staff, explains why the legislators chose provider-funded oversight. Ask each ICT provider on your register whether it expects to be designated, how it treats these fees in its price list, and whether any increase is passed through during the contract term. Confirm the current designation status and fee mechanics with the provider and the ESA publications, since designation is decided by the ESAs and the fee schedule may be updated.
Pooled TLPT is the main way the testing cost can be shared. Article 26(4) allows threat-led penetration testing to be pooled where an ICT provider serves several financial entities, so one test can cover shared systems instead of separate tests for each client. Delegated Regulation (EU) 2025/1190, Article 16(2), goes further for group entities: where they share ICT systems, a joint test is preferred if it reduces costs and resources. For a group with several regulated entities on one platform, the practical decision is whether a single scoped test across the group is feasible, and who coordinates the test, the threat intelligence and the closure report. Agree the test owner, cost split and reporting lines in writing before scoping starts. Confirm with your competent authority how it will treat a pooled test for each entity, because the attestation logic still applies to each financial entity in scope.
Pooled arrangements do not remove the recurring cost of testing your own environment, and a provider's fee does not reduce your obligations. Ask for a quote that separates the tester's fees, the threat intelligence provider's fees, the provider's time for participation, and any remediation support, so you can see which costs repeat and which are shared. Ask providers to state in the contract whether they will bear, share or pass on the cost of their participation in your TLPT, and how that cost is capped or priced in advance.
Which cost model fits: in-house, partner-led or pooled
This table compares four ways to fund and run DORA work: in-house, partner-led with internal ownership, pooled or joint TLPT, and fixed-scope engagements versus retainers. Read each row for when the model fits, which costs are one-time or recurring, and where it tends to fail. The main takeaway is that the entity stays fully responsible under Article 6(10) whichever model it chooses.
| Cost model | When it fits | What it shifts in cost | Risk to manage |
|---|---|---|---|
| In-house programme | Entities with mature ICT governance, staff who already run resilience testing, and legacy systems that need little change | Mostly internal staff time and tooling; costs recur through yearly framework review, testing and register upkeep | Internal capacity gaps in testing, documentation or incident reporting that surface only at supervisory review |
| Partner-led preparation with internal ownership | Entities that need outside help to build systems, controls and evidence but want the board and staff to own decisions | Front-loaded one-time fees for scoping, implementation and evidence; smaller recurring internal effort after handover | Unclear handover, with controls built but no internal team able to operate or evidence them after the engagement ends |
| Pooled or joint TLPT for group entities | Group entities or several entities sharing ICT systems or a common provider, where Article 26(4) and Article 16(2) of Delegated Regulation (EU) 2025/1190 allow one test | Shares the cost of one threat-led test across entities; each entity still carries its own governance and reporting work | ICT providers unable or unwilling to support a joint test, and disputes over scope, data and attestation across entities |
| Fixed-scope engagement | Defined projects with agreed deliverables, such as a gap analysis, a register build or a single TLPT cycle | One-time cost tied to written scope, deliverables and timelines; changes to scope usually need a new quote | Scope that omits recurring duties, so yearly activities restart as unplanned spending |
| Retainer for ongoing testing and upgrades | Entities that need continuous testing, platform upgrades and yearly review support after go-live | Recurring cost set by the agreed service level; reduces surprise spending on yearly testing and updates | Paying for capacity that goes unused, or an agreement that does not define what happens after a major incident |
| Outsourced compliance verification (Article 6(10)) | Entities that want an independent party to check ICT risk management compliance on their behalf | Adds an external verification cost, typically recurring; does not reduce the entity's own accountability | Treating outsourced verification as a transfer of responsibility, which DORA does not allow |
How a DORA cost estimate is built from written scope
The sequence below turns an unclear compliance question into a written scope that a quote can follow from. Each step produces a document the buyer can check before any price is discussed.
Confirm the entity category and TLPT status
Start by establishing which of the 20 types of financial entity listed in Article 2(1) the organization is, whether it qualifies as a microenterprise or falls under the simplified regime in Article 16(1), and whether a competent authority has identified it for threat-led penetration testing. This is usually done by the compliance lead with legal counsel and the authority's correspondence. The output is a scope statement that names the entity category, the obligations that apply and the proportionality route, which sets the size of everything that follows.
Inventory ICT systems and critical functions
Next, list the ICT systems, applications and data flows in the environment, then mark which ones support critical or important functions. Internal IT and the business owners of each function do most of this work, with DeployOpen typically helping to map the self-hosted platforms in the client's own cloud accounts or data centers. The output is an asset inventory with a critical or important function flag on each line, because the scope of yearly testing and continuity testing depends on that flag.
List ICT third-party providers and contract status
Compile every provider that supplies ICT services, including intra-group services, cloud providers and open-source software operated under a support or subscription agreement. For each, record which services it supports, whether those services touch a critical or important function, and whether the contract already contains the clauses DORA requires. The output is a provider list with contract status, which shows how much contract remediation and register work is in view before anyone estimates effort.
Assess current policies, register and evidence
Compare the existing policies, plans, register of information and test records against the Regulation and its technical standards. This gap assessment is run by the organization's compliance and security staff, with an implementation partner preparing the comparison if requested. The output is a gap list that states each missing or weak item, the requirement it traces to, and the evidence a supervisor would ask to see. The list is the main input for scope decisions and should be reviewed by the management body's owners.
Agree deliverables and recurring activities in writing
Decide which gaps will be closed, which documents will be produced or updated, and which recurring activities the organization will run, such as the yearly framework review, yearly testing of systems supporting critical or important functions and yearly continuity plan testing. Each recurring activity is placed on a calendar with an owner. The output is a written deliverable list and an activity calendar, signed off by the organization. Ask whether TLPT, if applicable, is in scope or priced separately, and whether any testing will be run by a provider.
Receive a quote that follows from the scope
DeployOpen does not publish a price list. Once the scope, deliverables and calendar are agreed, the quote is built from them, so each line can be traced back to a deliverable or activity. Ask for the one-time items and the recurring items as separate lines, the assumptions behind each, and what would change the price if the scope moved. The output is a fixed-scope proposal that the buyer can compare against other options. Fees paid to an independent auditor or assessor, if the buyer also requires one, are separate and not part of the implementation quote.
What usually inflates DORA costs, and how to avoid each
Most DORA cost overruns come from decisions made early in the programme, before the entity knows which functions, systems and providers actually matter. The cards below cover five recurring traps, each with the step that keeps effort and spend proportionate to what the Regulation requires.
Scoping every system as critical
Treating every system as supporting a critical or important function multiplies the yearly testing, continuity testing and provider scrutiny DORA ties to those functions. Agree the function map first, with business owners signing off which functions would cause material disruption if they failed. Ask your consultant to show how each system was assigned, so the scope can be defended to a supervisor and revisited when the map changes.
Leaving the register of information to the end
The register of information must be maintained over time, and building it late forces rushed data collection from providers and internal teams. Start with a provider inventory and contract list, then populate identifiers and service data as contracts are reviewed. Ask for the data-quality checks to be built into the process from the start, so maintenance remains a routine task rather than a recurring rebuild.
Buying tooling before the gap analysis
Licences bought before the gap analysis often duplicate capabilities the entity already has or miss the evidence supervisors will ask for. Run the gap analysis against the Regulation and its technical standards first, then size tooling to the gaps it confirms. Ask vendors and integrators to map each proposed tool to a named requirement and to state which parts of the evidence it cannot produce.
Duplicate testing without joint planning
Running a separate penetration test for each entity or system, then another for the same shared platform, adds cost without adding assurance. Plan the testing calendar jointly across group entities and shared systems, and check whether one test can satisfy several entities where the systems are the same. Ask your tester to document scope overlap in writing before work starts, so duplicated effort is visible early.
Contracts that leave incident assistance open
Article 30(2)(f) requires ICT providers to assist with incidents related to their service at no additional cost or at a cost determined in advance. A contract that is silent on this leaves incident response costs open at the moment the entity is least able to negotiate. Before signing, check that the clause states either no extra charge or a pre-agreed rate, and that it covers assistance during reporting deadlines.
Who owns the controls, who prepares evidence and who issues nothing
The financial entity owns its DORA obligations. The management body remains accountable for the ICT risk management framework, approves the key policies and carries the duty to oversee the ICT risk strategy, whatever help it buys. Outsourcing changes who does the work, not who is responsible for the outcome. Most of the recurring spend sits here because the organization runs the framework every year.
- Management body accountability: Board or equivalent members must approve the framework and understand the ICT risk it accepts, and this time is a internal cost even when no invoice is raised.
- Policy sign-off: Internal staff approve the policies, the register of information and the review report, and they keep them current.
- Decision on outsourcing: The organization decides how much verification to outsource. Article 6(10) allows outsourcing of compliance verification to intra-group or external undertakings while the entity stays fully responsible.
- Run costs: Yearly framework review, yearly testing and continuity testing, and register maintenance under Article 28(3) are performed or paid for by the entity.
- Staff time: Control owners, system administrators and incident responders spend time on evidence collection every year.
Before accepting any quote, confirm which of these tasks the partner will perform, which the organization will perform, and who signs each document.
An implementation partner such as DeployOpen does engineering and documentation work inside the client's own infrastructure. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in the client's cloud accounts, data centers or air-gapped networks. It prepares systems, controls and evidence for assessment. It does not decide the risk appetite, approve policies on the entity's behalf, or issue any report or certificate.
- Platform work: Planning, building, hardening and integrating the self-hosted platforms that the entity's ICT risk framework depends on.
- Documentation and evidence: Preparing configuration records, logs, test outputs and control descriptions that the entity's own staff review and adopt.
- Testing support: Running security testing and supporting resilience testing where scoped in writing.
- Ongoing support: Upgrades, backups and continuous testing are available through retainers, which recur as a separate cost.
- Fixed scope: Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope.
Ask the partner to list every deliverable and state which ones are evidence prepared for the entity's review and which ones are reports it would be expected to sign.
The competent authority supervises DORA compliance for its type of financial entity, as set out in Article 46. The ECB handles significant credit institutions, and the ESAs act as Lead Overseers for critical ICT third-party providers. Authorities use the supervisory powers in Article 50 to request information, inspect and require remedial measures. They do not certify entities, and their supervision produces no fee that the entity pays for a compliance certificate.
- Supervision, not certification: DORA sets no certification scheme, so no auditor or certification body can certify an entity as DORA compliant.
- Information requests: Authorities ask for policies, registers, test results and incident records during supervision, so the organization must keep them ready.
- The TLPT attestation: The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7).
- Independent review is separate: An independent auditor's or assessor's review of the framework is a voluntary line item, budgeted apart from the implementation and run costs and not a substitute for supervision.
- Penalties: Non-compliance leads to the enforcement measures that member states set under Chapter VII.
Confirm with your national competent authority what documents it expects and how it requests them, because supervisory practice varies by member state.
Questions buyers ask about DORA compliance cost
Is there an official DORA price for compliance?
No. DORA does not publish a price list or a fixed compliance fee, and no regulator sets one for an entity. Cost depends on how far your systems are from the requirements, how many ICT services you run, your entity type and whether you are identified for threat-led penetration testing. The Commission's impact assessment (SWD(2020) 199) said one-off costs come mainly from IT investment and are difficult to quantify because firms' legacy systems differ widely. It also expected lower costs for smaller firms subject to proportionate measures. Ask any partner for a fixed-scope written quote built from your gap analysis, and confirm your obligations with your competent authority.
Which DORA costs are one-time and which recur each year?
One-time costs are mostly IT investment to close gaps in systems, tooling and documentation, which the impact assessment says is hard to quantify. Recurring costs come from obligations DORA repeats. These include the yearly review of the ICT risk management framework (Article 6(5)), yearly testing of systems supporting critical or important functions (Article 24(6)), yearly continuity plan testing (Article 11(6)) and maintaining the register of information (Article 28(3)). For identified entities, TLPT runs at least every three years with at least 12 weeks of active red team testing. Ask a quote to separate project work from these annual activities.
Does threat-led penetration testing always apply to my entity?
No. TLPT applies only to entities that competent authorities identify for it, not to every financial entity. Entities under Article 16(1), which covers the simplified ICT risk management regime, are excluded from TLPT. Microenterprises are also relieved of the testing programme duties in Article 24. If you are identified, the ESA estimate cited in the impact assessment put TLPT costs at 0.1% to 0.3% of the total ICT budget of the firms concerned. Where a provider serves several entities, pooled testing is allowed under Article 26(4), which can reduce cost. Confirm your status with your competent authority before budgeting.
Can a small or microenterprise entity do DORA work in-house?
It can, in part. Microenterprises do not need an independent ICT risk control function or internal audit of the framework (Article 6(4) and (6)), and they may delegate audit rights over providers to an independent third party (Article 30(3)). Entities under Article 16(1) follow the simplified framework in Title III of Delegated Regulation (EU) 2024/1774. Even so, the entity remains fully responsible, and Article 6(10) allows outsourcing verification of compliance only while keeping that responsibility. Many small firms keep ownership and sign-off in-house and buy specific work such as testing, documentation or system hardening. Weigh staff time against the written scope of any outside help.
What do critical ICT third-party providers pay in oversight fees?
Critical providers pay annual oversight fees scaled to turnover, with a minimum of EUR 50 000, according to Delegated Regulation (EU) 2024/1505. A provider that applies voluntarily for designation pays a EUR 50 000 opt-in fee under the same regulation. The Commission's proposal (COM(2020) 595) stated that oversight of critical providers would be funded by these fees rather than by the financial sector directly. Fees are paid by the provider, but financial entities should check how these costs may reach their contract prices. Confirm the current fee terms in the regulation and in the designation decision for your provider.
How do I compare two partner quotes for DORA work?
Compare the written scope first, then the price. Check that both quotes cover the same gap analysis, the same policies and registers, the same annual activities and the same testing. Ask which deliverables are one-time and which recur, and how each recurring activity is priced. Confirm who owns the controls (your entity), who prepares evidence (the partner) and who signs off (your management body). Ask what the partner needs from your team and how changes to scope are priced. A partner preparing evidence does not issue an attestation or confirm compliance, so ask for the scope of that exclusion in writing.
What does DORA work need from my own team?
Your team owns the decisions, so expect time from the management body, risk, compliance, IT operations and procurement. Management must approve the ICT risk management framework and carry responsibility under DORA. Operations staff must supply asset inventories, system configurations, logs, incident records and provider contracts. Procurement must collect contract clauses and provider data for the register of information. The amount of time depends on how documented your environment already is, so ask a partner to list each input, its owner and its due date in the written scope before work starts.
Does a partner's work mean my entity is DORA certified?
No. DORA sets no certification scheme, so no auditor or partner can certify an entity as DORA compliant. Competent authorities supervise compliance using their powers under Article 50. The only authority-issued attestation the Regulation provides for is the TLPT attestation under Article 26(7), which covers a threat-led test. A partner prepares systems, controls and evidence for supervisory review, and your management body remains accountable. Ask your partner which evidence it will prepare and confirm with your competent authority which documents it expects to see.
How DeployOpen scopes DORA work and hands over the evidence
DeployOpen prepares the systems, controls and evidence that drive DORA compliance cost, inside your own infrastructure. We do not issue audit reports or attestations; independent assessors and competent authorities make those determinations.
How we scope
- Agree a written scope that lists which systems, ICT services and entities the DORA cost estimate covers.
- Separate one-time build work from recurring yearly activities such as testing and register maintenance in the quote.
- Confirm with your legal and compliance team which proportionality options apply to your entity type before pricing starts.
How we build
- Implement and harden the self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- Configure logging, backup and access controls so the evidence needed for cost-driving activities is generated automatically.
- Run security testing on systems that support critical or important functions, with findings tracked to remediation.
How we hand over
- Deliver documentation, configuration baselines and test records in a format your compliance team and assessors can review.
- Provide a cost-driver summary that maps recurring activities to owners, frequencies and the evidence each one produces.
- Transfer administration knowledge to your staff so the platforms remain under your control after the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer once the initial scope is delivered.
- Revisit the cost model when your ICT estate, providers or proportionality position changes.
- Coordinate with your independent auditor or competent authority when they request evidence, without speaking for them.
