Learn
Search for DORA compliance cost and you will find figures that differ by three orders of magnitude. One article puts it at a few thousand euros of software. Another quotes tens of millions for a mid-sized bank. Both are quoted with total confidence, and neither tells you anything useful, because DORA compliance cost is not a price, it is a function. The inputs are your entity type, the number of critical or important functions you run, how many ICT contracts you hold, and how much of the work you already did for other regulations. Two of the work items below have step-by-step guides: how to create a risk register and user access review software.
This page gives you the function. It walks the eight work items that appear on every DORA programme, what each one actually consists of, what multiplies it, and where teams consistently underestimate. At the end you can produce a number that is yours rather than someone else's average.
On this page
- DORA compliance cost at a glance
- Why published DORA cost estimates disagree so wildly
- What actually drives your DORA cost
- The eight work items you will pay for
- The Register of Information: the item teams underestimate
- Contract remediation: the item that needs legal budget
- Resilience testing and TLPT: who pays for what
- Consultancy, legacy GRC or platform: three cost curves
- What DORA costs after year one
- How to cut the number without cutting the compliance
- Frequently asked questions
DORA compliance cost at a glance
Every DORA programme pays for the same eight things. What changes is the multiplier on each one.
| Work item | What multiplies it | One-off or recurring |
|---|---|---|
| Scope and classification | Number of legal entities and business functions | One-off, reviewed annually |
| Gap assessment | How much ISO 27001 or NIS2 work already exists | One-off, repeated yearly |
| ICT risk management framework | Whether you are writing from scratch or adapting | One-off, maintained |
| Register of Information | Number of ICT providers and contracts | Recurring, filed to your NCA |
| Contract remediation | Contract count, and supplier willingness to renegotiate | One-off per contract, then at renewal |
| Resilience testing programme | Whether you are designated for threat-led testing | Recurring, annual and multi-year |
| Incident classification and reporting | Incident volume and out-of-hours cover | Recurring |
| Running the programme | Evidence volume and board reporting cadence | Recurring |
Why published DORA cost estimates disagree so wildly
There are three reasons, and understanding them is most of the work.
They measure different things. Some estimates count only external spend: consultants, testers, software. Others include the internal salary cost of the people running the programme, which is usually the larger number. A figure without that boundary stated is not comparable to anything.
They ignore the starting point. Regulation (EU) 2022/2554 does not ask for much that a mature information security programme has never seen. If you already hold ISO 27001, have a working incident process and maintain a vendor register, a large share of DORA is re-evidencing work you have done rather than new work. If you are starting from spreadsheets, it is genuinely new. The same regulation therefore produces very different bills.
They quote the largest firms. Sector-wide totals divided by employee counts produce headline numbers that describe a systemically important bank with hundreds of ICT contracts. They do not describe a payment institution with fifteen suppliers. Be careful about any per-employee figure, since DORA obligations scale with functions and contracts, not headcount.
The honest position: nobody can quote you a DORA price without knowing your entity type, your function inventory and your contract count. What they can do is give you the model.
What actually drives your DORA cost
Four variables account for most of the variance between two organisations.
- Your entity type and proportionality. DORA applies across a wide set of financial entities and applies proportionately. A small, non-interconnected entity carries a lighter version of several obligations than a significant credit institution. Establishing where you sit is the first thing to do, because it changes the scope of everything after it.
- How many critical or important functions you run. This is the single biggest multiplier in the regulation. A function classified as critical or important under Article 3(22) pulls stronger contractual requirements, tighter testing expectations and closer scrutiny of the providers behind it. Over-classify and you pay for obligations you did not owe. Under-classify and a supervisor will correct you at the worst possible moment.
- How many ICT contracts you hold. Every contract has to be recorded and, where it supports a critical or important function, must contain specific provisions. Contract count drives both the register work and the legal work, and it is the number most teams have never actually counted before they start.
- What you can reuse. Evidence gathered for ISO 27001, NIS2 or SOC 2 answers many DORA requirements. Whether you can reuse it depends on whether your controls are mapped across frameworks or maintained separately per framework. Separately maintained means paying for the same evidence several times.
The eight work items you will pay for
1. Scope and classification. Establish which entities are in scope, inventory your business functions and decide which are critical or important. Output: a defensible, documented classification. This is cheap in euros and expensive in senior attention, and getting it wrong is the most costly mistake available to you, because everything downstream inherits it.
2. Gap assessment. Score yourself against the regulation chapter by chapter. Our guide to scoring DORA readiness walks the seven domains and the weighting. The cost here is a function of how honest you are willing to be; a fast green assessment is worthless and you will pay for it later.
3. The ICT risk management framework. Chapter II and the associated regulatory technical standards set out what the framework has to contain. If you are adapting an existing information security management system, this is editing. If you are writing from nothing, it is a document project with board approval attached. We break down the required contents in how to write a DORA ICT risk management framework.
4. The Register of Information. Covered in detail below.
5. Contract remediation. Covered below.
6. The resilience testing programme. Covered below.
7. Incident classification and reporting capability. You need to be able to decide, quickly, whether an incident is major, and then meet the reporting deadlines that follow. The classification test is precise, and running it by hand at two in the morning is where programmes fail. See DORA major incident classification for the exact criteria and clocks.
8. Running the programme. Evidence collection, control reviews, board reporting, keeping the register current as contracts change. This is the item that is invisible in year one budgets and dominates year two.
The Register of Information: the item teams underestimate
The Register of Information is the work item that surprises people. It is not a list of suppliers. It is a structured filing built from fifteen official templates set out in Implementing Regulation (EU) 2024/2956, and the tables reference each other. Entities, branches, contracts, providers, functions and the links between them all have to reconcile, and a reference that points at a row that does not exist will fail validation.
The cost drivers are contract count, provider count, and how much of the required data you already hold in a structured form. Legal entity identifiers, country codes, function classifications and contract dates all have to be present and consistent. Most organisations discover that this data lives across procurement spreadsheets, contract PDFs and somebody's memory.
Two follow-on costs are routinely forgotten. First, the register is not a one-off: it is maintained and re-filed, so every new contract creates work. Second, submissions get rejected on validation rules rather than on substance, and each rejection cycle costs time against a filing deadline. We documented the specific rule codes in why your DORA Register of Information keeps getting rejected.
Contract remediation: the item that needs legal budget
Article 30 sets out provisions that ICT contracts must contain, with an additional set for arrangements supporting critical or important functions. That means a legal review of every ICT contract you hold, an amendment where provisions are missing, and a negotiation with each supplier who does not want to sign the amendment.
The cost is not the drafting. Standard amendment language can be written once. The cost is the negotiation, multiplied by the number of suppliers who have their own view, and it is entirely outside your control. Large cloud providers publish DORA addenda; a small niche vendor with one lawyer may take months. Budget for the tail, not the average.
Our guide to building a compliant vendor register from scratch covers which provisions apply to which contracts, and the sub-outsourcing requirements that reach past your direct suppliers.
Resilience testing and TLPT: who pays for what
DORA requires a testing programme rather than an annual penetration test. That programme has to be designed, approved by the management body, executed and evidenced, and it runs on a multi-year cycle. The budget line is therefore recurring, and it is bigger than the single test most organisations were previously buying.
Threat-led penetration testing is a separate and much larger cost, but it only applies to entities identified by the competent authorities. If you are not designated, you do not pay for it. If you are, it is a substantial multi-month engagement with specific requirements on the testers, and it recurs on a cycle. Read DORA TLPT: threat-led penetration testing before assuming either way, and the full annual testing programme your board must approve for what the standard programme has to contain.
Consultancy, legacy GRC or platform: three cost curves
How you deliver the programme changes the shape of the spend more than the total.
| If this is you | The model that usually fits | Why |
|---|---|---|
| No in-house regulatory expertise, hard deadline | Consultancy for the first pass, platform to run it | Advice alone leaves you with a report and no system |
| Large group, many entities, existing GRC investment | Extend what you have, if the implementation window fits | Configurability is real, but so is the implementation time |
| Lean team, several frameworks at once | Platform with the regulation built in | Evidence entered once counts across frameworks |
| Spreadsheets, one person, no budget | Start with the gap assessment, then decide | You cannot budget what you have not scoped |
The variable people forget is what happens when the engagement ends. A consultancy pass produces a framework document, a populated register and a remediation plan. Twelve months later, contracts have changed, the register is stale and the plan is half done. Whatever you choose, something has to own the recurring work, and that something is a line in the budget.
What DORA costs after year one
Year one is scoping, writing and remediation. Year two onward is a different and smaller bill made of five recurring items: maintaining and re-filing the register, re-testing on the programme cycle, reviewing contracts at renewal, keeping evidence current, and reporting to the board. That recurring cost is where the delivery model shows up. If the year one work produced documents, you pay a similar amount again. If it produced a maintained system, you pay a fraction.
How to cut the number without cutting the compliance
- Classify functions carefully before anything else. Every euro downstream is multiplied by this decision. Do it once, with the business in the room, and write down the reasoning.
- Count your ICT contracts before you buy anything. The number will surprise you, and it is the input every quote depends on.
- Reuse evidence across frameworks. If you also run ISO 27001, NIS2 or SOC 2, a shared control set means one piece of evidence answers several requirements. Maintaining a separate programme per framework is the most expensive way to be compliant.
- Do not buy threat-led testing until you know you are designated. It is the largest single line item and it does not apply to everyone.
- Fix the register data model early. Late data cleanup against a filing deadline is the most expensive hour in the programme.
Do this in Venvera
Venvera holds DORA as a maintained control set rather than a template you fill in: the DORA workspace covers the gap assessment, the ICT risk framework, the Register of Information with completeness scoring and xBRL-CSV export, contract clause checking, the testing programme and incident classification with the reporting clocks running. Evidence you attach once is reused by every other framework that asks for the same control, which is the single largest lever on the recurring cost above. Pricing is published and flat: from EUR 399 per month. Start with the free readiness check if you want the scoping answer before you spend anything.
Frequently asked questions
How much does DORA compliance cost?
There is no single figure, and anyone quoting one without asking about your entity type, your critical or important functions and your ICT contract count is guessing. The cost is driven by those three variables plus how much existing security work you can reuse. Use the eight work items above to build your own estimate.
Is DORA cheaper if we already have ISO 27001?
Materially, yes. A working information security management system, a vendor register and a tested incident process answer a large share of DORA's expectations, so the work becomes re-evidencing rather than building. The savings only materialise if your controls are mapped across frameworks rather than maintained separately.
What is the most underestimated DORA cost?
The Register of Information, followed by contract remediation. The register is fifteen linked templates that must reconcile and validate, not a supplier list, and it has to be maintained. Contract remediation is unpredictable because supplier negotiation is outside your control.
Do we have to pay for threat-led penetration testing?
Only if the competent authorities identify you for it. It is a significant multi-month cost with specific requirements on the testers, and it recurs on a cycle. Entities that are not designated still need a resilience testing programme, which is a smaller line.
Does DORA cost more for a group with several entities?
Yes, because scope, classification and the register all replicate per entity. Groups that can share a control set and evidence library across subsidiaries pay far less than groups running a separate programme in each one.
