Five Critical Mistakes to Avoid in Your DORA Implementation
The Pattern of Failure
DORA implementation programmes fail in predictable ways. Not because the regulation is impossibly complex — it is demanding but well-structured — but because institutions bring assumptions from previous regulatory exercises that do not apply. DORA is not GDPR (a data protection overlay on existing processes). It is not MiFID II (a market conduct regulation). It is an operational capability regulation that requires demonstrable, testable, evidence-backed resilience. Institutions that treat it as anything less discover this too late.
These five mistakes are drawn from patterns observed across the European financial sector. Each one, individually, can turn a well-funded DORA programme into an audit failure.
Mistake #1: Treating DORA as a Checkbox Exercise
What goes wrong: The institution launches its DORA programme as a compliance project. A project manager creates a spreadsheet of DORA articles, assigns each to a department, and asks teams to confirm when their article is "covered." Departments interpret "covered" generously — existing policies are relabelled, existing processes are mapped to DORA language, and the spreadsheet turns green. Senior management receives a dashboard showing 85% compliance. Everyone relaxes.
Then the auditor arrives. They do not ask whether policies exist. They ask for evidence that policies are followed. They do not ask whether the testing programme is documented. They ask for test execution records, measured recovery times, deviation tracking, and remediation evidence. They do not ask whether the risk management framework exists. They ask how it responded to the last actual incident, what changed as a result, and how those changes were validated.
Real consequences: Institutions that treat DORA as a checkbox exercise consistently fail on evidence. They have documents but not proof. They have processes but not records. They have frameworks but not measurements. The audit finding is not "you lack a policy" — it is "you cannot demonstrate that your policy works." This finding requires remediation under supervisory oversight, which is far more expensive and disruptive than getting it right the first time.
How to avoid it: Shift the programme objective from "document compliance" to "demonstrate capability." Every work stream should produce evidence, not just documents. Every process should generate records, not just exist on paper. The question is never "do we have this?" — it is "can we prove this works?"
Mistake #2: Starting with Technology Before Governance
What goes wrong: The institution's first DORA action is to issue an RFP for a GRC tool, a resilience testing platform, or an asset management system. The technology procurement takes 6-9 months. Implementation takes another 6-12 months. When the platform is finally operational, the institution discovers that it has no governance framework to implement in the tool, no agreed risk taxonomy to populate it with, and no defined workflows to automate.
This is the Art. 8 before Art. 5 mistake. Article 8 (ICT asset identification) is important, but Article 5 (governance and organisation) is foundational. Art. 5 establishes the management body's accountability, the governance structure, the risk management strategy, and the organisational roles and responsibilities. Without this foundation, every downstream activity — asset inventory, risk assessment, testing, incident management — lacks direction, ownership, and accountability.
Real consequences: Technology deployed without governance creates expensive shelfware. The platform is configured based on vendor defaults rather than institutional requirements. Data structures do not align with the institution's risk taxonomy. Workflows do not reflect the institution's governance model. Six months after go-live, teams are still using spreadsheets because the platform does not match how they actually work.
How to avoid it: Sequence the programme correctly. Start with governance (Art. 5-6): define the management body's role, establish the risk management framework, assign roles and responsibilities, and set the strategic direction. Then define the operational model (Art. 7-16): risk methodology, asset taxonomy, testing strategy, incident process. Only then select and implement technology to automate and evidence the model you have already designed. The governance design phase takes 2-3 months and costs a fraction of the technology investment — but it determines whether that technology investment creates value.
Mistake #3: Ignoring the Third-Party Register Until the Deadline
What goes wrong: Pillar IV (Art. 28-44) is deferred because it involves vendors, contracts, legal review, and procurement — all of which are slow, politically complex, and resource-intensive. The institution plans to "get to it later" after completing the "easier" pillars. Later arrives, and the team discovers that building a comprehensive register of ICT third-party arrangements, assessing concentration risk, reviewing contract clauses against Art. 30, and documenting exit strategies for critical arrangements is a 12-18 month effort, not a 3-month sprint.
Art. 28(3) requires a register of information "in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers." This register must be maintained, updated, and available to competent authorities on request. It is not a one-time exercise — it is a living governance capability.
Real consequences: The register is incomplete. Critical vendor relationships are classified as "standard" because no proper assessment was conducted. Contracts lack mandatory Art. 30 provisions, and there is insufficient time to renegotiate. Concentration risk is unknown because substitutability has never been assessed. Exit strategies are aspirational paragraphs rather than actionable plans. When the supervisor requests the register — and they will, often as one of their first supervisory actions — the institution cannot produce a credible one.
How to avoid it: Start Pillar IV in parallel with Pillar I, not after it. The third-party register and asset inventory are interconnected — ICT assets supported by third parties must reflect the dependency relationship in both directions. Begin with a rapid inventory of all ICT service arrangements (procurement records, cloud subscriptions, SaaS licences), classify them by criticality, and prioritise contract review for critical and important arrangements. Concentration risk analysis and exit strategy documentation can follow, but the register itself must be underway from the programme's first quarter.
Mistake #4: Conflating DORA Testing with Existing Penetration Testing
What goes wrong: The CISO presents the institution's existing penetration testing programme and declares Pillar III satisfied. After all, the institution conducts annual penetration tests, quarterly vulnerability scans, and periodic red team exercises. DORA requires resilience testing. The institution does resilience testing. Compliance achieved.
This conflation ignores two critical distinctions. First, Article 25 requires a broader testing programme than penetration testing alone — it specifies vulnerability assessments, network security assessments, gap analyses, source code reviews, scenario-based tests, compatibility testing, performance testing, and end-to-end testing. Penetration testing is one component, not the programme.
Second, and more consequentially, Article 26 requires threat-led penetration testing (TLPT) for designated entities. TLPT is categorically different from traditional penetration testing. It requires bespoke threat intelligence, a three-team structure (red/blue/white), testing against live production systems, NCA involvement, and external testers meeting Art. 27 qualification requirements. An existing penetration test, however rigorous, does not satisfy Art. 26 unless it was conducted under TLPT methodology.
Real consequences: The institution discovers mid-examination that its testing programme does not meet Art. 25's breadth requirements. Worse, if designated for TLPT, it has no budget, no qualified provider engagement, and no NCA coordination in place. TLPT cycles require 6-12 months from initiation to completion. There is no shortcut, and the supervisor will not accept a traditional penetration test as a substitute.
How to avoid it: Conduct a formal gap analysis between your current testing programme and Art. 25 requirements. Map each Art. 25 testing type to your existing activities and identify gaps. For TLPT, determine whether your institution is likely to be designated (or has already been designated) under Art. 26(8) and begin provider engagement immediately. The distinction between Art. 25 testing and Art. 26 TLPT must be understood, budgeted for, and governed separately. See our detailed comparison of TLPT vs traditional penetration testing for the full scope of differences.
Mistake #5: Underestimating the Management Body Obligations
What goes wrong: Article 5 is treated as a governance formality. The board receives a briefing on DORA, acknowledges its importance, delegates to the CRO or CISO, and moves on. The management body's involvement is limited to approving the compliance budget and receiving quarterly status updates.
Art. 5(2) states that the management body shall "define, approve, oversee and be accountable for the implementation of all arrangements related to the ICT risk management framework." Art. 5(4) requires members to "maintain sufficient knowledge and skills to be able to understand and assess ICT risk" and mandates training. Art. 5(6) requires the management body to "allocate and periodically review" the budget for digital operational resilience.
This is not delegation language. This is personal accountability language. The management body is not a sponsor — it is an owner.
Real consequences: When the supervisor examines the institution's DORA governance, they look for evidence of management body engagement: board minutes discussing ICT risk, documented approval of the risk management framework, training records demonstrating ongoing skill development, evidence of budget review and allocation decisions, and personal sign-off on material changes to the resilience posture.
Institutions where the management body delegated and disengaged cannot produce this evidence. The finding — inadequate management body oversight — is one of the most serious supervisory observations because it indicates a governance failure, not just a process gap. Remediation requires sustained behavioural change at the highest level of the organisation.
How to avoid it: Embed DORA governance into existing board and management committee structures. Do not create a parallel governance track — integrate ICT risk and operational resilience into the risk committee agenda, the audit committee scope, and the management board's regular oversight cycle. Ensure management body members receive structured DORA training (not a one-time briefing but an ongoing programme covering ICT risk, resilience testing results, incident trends, and third-party risk exposure). Document every board decision, discussion, and challenge related to operational resilience. Platforms that provide board-level compliance dashboards and scoring — capturing the evidence of management oversight that auditors look for — make this governance integration practical rather than aspirational.
The Common Thread
These five mistakes share a root cause: approaching DORA with the mental model of a documentation exercise rather than a capability-building programme. DORA is not asking institutions to write about operational resilience. It is asking them to demonstrate it — through governance, through testing, through evidence, through continuous assurance.
The institutions that internalise this distinction early will build genuine resilience capabilities that satisfy supervisors and — more importantly — protect the institution and its customers when disruption actually occurs. Those that discover it during their first examination will spend the next 18 months in remediation, under enhanced supervisory scrutiny, at a cost that dwarfs the original compliance budget.
The regulation is clear. The implementation path is known. The mistakes are avoidable. The only question is whether your institution will learn from the mistakes of others or insist on making its own.
This analysis reflects patterns observed across European financial institutions. Individual institution circumstances vary. The editorial opinions expressed are those of DORA Atlas and do not constitute regulatory or legal advice.