Banking cybersecurity: DORA compliance for financial entities 2026

Regulation (EU) 2022/2554, known as DORA, entered into application on 17 January 2025 and establishes a unified digital operational resilience framework for all financial entities in the European Union. Traditional banks, neobanks, insurers, fund managers, investment firms, payment institutions, crypto-asset service providers under MiCA and critical third-party ICT providers designated by the ESAs all fall within the DORA perimeter. The regulation replaces a fragmented puzzle of sectoral guidelines with a single, directly applicable normative body that carries its own sanctioning regime.

Key takeaways

• DORA is a directly applicable Regulation that prevails over NIS2 for financial entities under the lex specialis principle.
• Five pillars structure compliance: ICT risk management, incident reporting, operational resilience testing, third-party ICT risk management, and information sharing arrangements.
• TLPT (Threat-Led Penetration Testing) under TIBER-EU methodology is mandatory every three years for designated entities, using accredited threat intelligence and red team providers.
• Critical ICT third-party governance requires a reportable register, mandatory contractual clauses, audit rights, and a documented exit strategy.
• More than half of European banks started their DORA preparation late according to ECB monitoring published in 2025, opening a realistic eighteen-month remediation window.

DORA in one sentence and its impact on banking

DORA is the first European framework that unifies cybersecurity and operational resilience obligations for the financial sector into a single regulatory instrument. A regulation is directly applicable in all Member States from the date set out in its own text, without requiring transposition into national law. This removes the fragmentation that characterised the previous landscape, where every national supervisor interpreted EBA, EIOPA or ESMA guidelines with different nuances.

For banking the impact is structural. DORA consolidates into binding obligations a series of good practices that until now lived in supervisory guides, ECB recommendations, or Bank of Spain circulars. It introduces the principle of lex specialis against NIS2: when a financial entity is subject to both, DORA prevails on matters regulated by both. The compliance function does not need to maintain two parallel incident reporting frameworks, but must ensure internal harmonisation reflects this prevalence, especially in groups with non-financial subsidiaries that do fall under pure NIS2.

Entities in scope

DORA lists the categories in its article 2. The table summarises the main ones with their supervisory mapping in Spain.

Microenterprises with fewer than ten employees or two million euros in turnover have a simplified regime for some obligations but are not exempt. Proportionality adjusts the depth of controls, not their existence.

The five DORA pillars

Pillar 1: ICT risk management (articles 5 to 15)

The management body is directly responsible for the ICT risk management framework. This responsibility cannot be delegated and appears explicitly in the articles, turning cybersecurity investment decisions into a fiduciary responsibility of the board. The framework must cover identification of critical functions, ICT asset inventory, information security policies, cryptography, access control, change management, anomaly detection, business continuity with RTO and RPO per critical function, and a documented post-incident learning process.

Pillar 2: incident reporting (articles 17 to 23)

DORA imposes a uniform process of detection, classification according to RTS criteria, and escalating notification to the competent authority. The receiving authority in Spain depends on entity type: the Bank of Spain receives notifications from credit and payment institutions, the CNMV from securities markets and crypto-assets, and the DGSFP from insurance and pension funds. There is also a voluntary notification of significant cyber threats, not only of consummated incidents.

Pillar 3: operational resilience testing (articles 24 to 27)

All obligated entities must maintain a testing programme proportional to their profile including vulnerability assessments, source code reviews, network tests, continuity tests, pentesting, and physical security tests. Entities designated by the competent authority based on systemic impact, size, and risk profile must additionally perform TLPT at least every three years.

Pillar 4: third-party ICT risk management (articles 28 to 44)

DORA rewrites supplier management in the financial sector. The entity must maintain an information register of all ICT contractual arrangements, kept up to date and reportable to the supervisor in harmonised format. The minimum clauses of article 30 are exhaustive for providers of critical functions: rights of access, inspection and audit, access to information and premises, subcontracting with prior authorisation, quantified SLAs, cooperation with the supervisor, and a documented exit strategy. Designated CTPPs come under direct European supervision.

Pillar 5: information sharing arrangements (article 45)

The last pillar promotes voluntary participation in sectoral arrangements for sharing information on cyber threats, indicators of compromise, and adversarial techniques, respecting confidentiality and GDPR. It is not a hard obligation, but supervisors view positively membership of structures such as FS-ISAC or national sectoral forums.

TLPT (Threat-Led Penetration Testing) under DORA

TLPT is the most disruptive change introduced by DORA from a technical standpoint. Designated entities, generally systemic banks, market infrastructures, and large insurers, must execute an intelligence-led red team exercise on production systems at least every three years. The scope covers critical or important functions and is built from a targeting report produced by an accredited threat intelligence provider that identifies realistic actors and credible TTPs for that entity.

The provider requirements are exhaustive. The threat intelligence provider and the red team provider must be independent from each other and accredited in accordance with the RTS published by the ESAs. Accreditation validates technical competence, separation of functions, insurance coverage, and handling of sensitive information. The exercise is executed against production over twelve or more weeks, with a small internal white team aware of the exercise while the blue team is subjected to the test without prior notice.

DORA reuses the TIBER-EU framework published by the ECB in 2018 as a methodological basis. The four canonical phases are preparation, threat intelligence, red teaming, and closure with replay alongside the blue team. The difference is that TLPT under DORA turns into mandatory a practice that TIBER offered as voluntary, and adds formal accreditation requirements.

Critical ICT third-party governance

Third-party governance is the area where most entities carry the largest accumulated technical debt. A medium-sized financial entity typically maintains between two hundred and eight hundred active ICT contracts, of which a significant fraction supports critical functions. DORA requires an integral process that starts with a prior criticality and risk analysis, continues with the negotiation of clauses aligned with article 30, follows with continuous monitoring, and ends with a documented and tested exit strategy.

The information register of providers is the most visible deliverable. The ESAs published a harmonised XBRL format that entities must generate, keep updated, and deliver to their supervisor annually. The register captures provider identity, nature of the service, criticality, geographical location of processing, subcontractors, intra-group dependencies, and a quantitative assessment of risk concentration.

Audit rights are a common friction point in negotiations with hyperscalers. The entity must have effective capability to audit the provider, either directly or through pooled audits with accessible reports. Pre-existing contractual arrangements with AWS, Azure, or Google Cloud required widespread renegotiation throughout 2024 and 2025.

The exit policy must be realistic. A declarative termination clause is not enough. The entity must be able to migrate the critical function to an alternative provider or to in-house infrastructure within a reasonable timeframe, with data extractable in open formats. Exit simulation exercises are a practice recommended by the Bank of Spain.

Incident reporting: DORA vs NIS2 vs GDPR

The three regulations coexist with different deadlines, formats, and authorities.

A single incident can trigger all three notifications simultaneously. The established practice is to build a single internal process that produces the three deliverables with the common information gathered only once, avoiding duplications that delay response.

Required internal roles

DORA requires an ICT risk management function equipped with sufficient resources, effective authority, and direct reporting to a member of the management body. It is not necessarily a separate department, but it must be an identifiable function with nominated responsible parties.

The internal audit function must review the framework with at least annual frequency and with independence from the operational areas being audited. In medium-sized entities this function is often partially outsourced; DORA does not prohibit this but requires that ultimate responsibility remains internal.

The management body must receive specific training in ICT risks and operational resilience with adequate frequency. This DORA-trained board obligation appears explicitly in the articles, and supervisors are beginning to verify it in routine inspections. Training must be documentable; passive attendance at an annual presentation is not enough.

Realistic DORA compliance roadmap 2026

More than half of European credit institutions started DORA preparation behind the optimal calendar according to the monitoring published by the ECB during 2025. Many organisations find themselves in 2026 with a real gap between the current state and substantive compliance. A realistic eighteen-month plan with prioritisation by regulatory impact allows closing that gap without chaos.

Months 1 to 3: exhaustive diagnosis. Inventory of critical or important functions, mapping of ICT providers with criticality classification, gap analysis against the five pillars and the published RTS, review of contractual clauses with critical providers, assessment of the ICT risk management function and internal audit.

Months 4 to 9: design and remediation. Updated ICT governance framework approved by the board, incident reporting procedure aligned with the RTS, structured testing programme with multi-year calendar, business continuity plan with RTO and RPO per critical function, renegotiation of critical ICT contracts to incorporate article 30 clauses, construction of the information register in XBRL format.

Months 10 to 18: implementation and verification. Deployment or consolidation of detection and response capability, tabletop exercises and continuity drills, contracting of accredited TLPT providers if the entity is designated, first internal audit of the complete framework, initial regulatory reporting to the supervisor.

Common mistakes

The first recurring mistake is assuming that ISO 27001 already covers DORA. ISO 27001 certification covers a good part of pillar 1, but leaves substantial aspects uncovered: the incident reporting regime to competent authority, TLPT under TIBER-EU, the harmonised register of ICT providers, the documented exit strategy per critical provider, and specific training of the management body. A certified organisation has a relative advantage, not DORA compliance.

The second mistake is insufficient third-party scope. It is common to find provider registers that cover the large visible contracts but omit SaaS contracted by business units without involving procurement, integrations with fintech partners, or data services consumed via API. DORA requires exhaustive coverage, not selective.

The third mistake is contracting TLPT with a non-accredited provider. The RTS are exhaustive in the accreditation requirements. An exercise performed with a provider that partially meets the requirements does not satisfy the regulatory obligation, even if the technical quality is high.

The fourth mistake is lack of auditable documentation. DORA supervision is evidence-intensive: board minutes, training evidence, records of tests performed, communications with providers, and action plans. An organisation with effective controls but poor documentation will struggle in inspection.

Frequently asked questions

Is a Spanish neobank obligated by DORA?

Yes. If the neobank operates with a credit institution, payment institution, or e-money institution licence, it falls within article 2. Application is full from 17 January 2025, with the proportionality principle adjusting the depth of some obligations but not exempting from substantive compliance.

Is TLPT mandatory for all financial entities?

No. It is only mandatory for entities designated by the competent authority based on size, risk profile, and systemic role. Non-designated entities must maintain an advanced testing programme with periodic pentesting, but not formal TLPT under TIBER-EU. The designation is communicated formally and reviewed periodically.

Does a critical cloud provider become a bank for DORA purposes?

No. A designated CTPP becomes subject to direct supervision by the ESAs in relation to the services provided to the financial sector, but does not acquire the status of a financial entity. Supervision covers risk management practices, operational capability, incident management, and cooperation with authorities. The ESAs can impose binding recommendations and daily penalty payments, not prudential capital requirements.

What fine can an entity receive for not reporting an incident?

DORA delegates the sanctioning regime to national competent authorities. For financial entities the sanction can reach up to 1% of the average daily worldwide turnover during the period of non-compliance. The authority considers severity, duration, benefit obtained, and degree of cooperation. The sanction can be accompanied by named publication and temporary suspension of authorisations.

Does DORA exempt from NIS2 compliance?

For financial entities purely under the DORA perimeter, yes: the lex specialis principle makes DORA prevail. For mixed groups with non-financial subsidiaries, the subsidiaries outside the DORA perimeter must comply with NIS2 if they fall within the subjective scope of the directive. The group compliance function must precisely map which regulation applies to each legal entity.

What is a DORA inspection by the Bank of Spain like?

Inspections combine remote documentary review with on-site visit. The remote review covers the ICT risk management framework, the provider governance policy, the harmonised register, evidence of testing, and board training. The on-site visit deepens into interviews with responsible parties and review of specific evidence. The typical duration ranges between four and twelve weeks depending on size and scope, with a final report detailing findings and remediation deadlines.

Related resources

• DORA regulation: scope, deadlines and obligations (2026)
• DORA vs NIS2: when each one applies
• NIS2 in Spain: transposition, deadlines and obligations
• TIBER-EU and TLPT: intelligence-led red team in banking
• Complete cybersecurity audit guide for businesses
• What is red team: enterprise guide

DORA compliance with Secra

At Secra we support financial entities in their integral adaptation to DORA combining regulatory consulting and accredited technical capability. We perform TLPT under TIBER-EU methodology with threat intelligence and red team accredited in accordance with the RTS published by the ESAs, we execute structured gap analysis against the five pillars, and we build the harmonised register of ICT providers in XBRL format ready to deliver to the supervisor.

The team is made up of professionals with direct experience in projects for credit institutions, payment institutions, and insurers supervised by the Bank of Spain, CNMV, and DGSFP, working with both significant banks under ECB supervision and neobanks and fintechs holding Spanish licences.

If you need an initial diagnosis or want to plan a realistic DORA roadmap for the next eighteen months, contact us and we will arrange an initial conversation with no commitment.