DORA operational resilience for central counterparties, central securities depositories and trading venues, built for systemic markets where outages are measured in minutes.
Which type of market infrastructure do you operate?
Applies whatever your size, calibrated by Article 4; Article 16 is not open to CCPs. Recovery plans must recover all transactions at the time of disruption so settlement completes on the scheduled date (Article 12(3)), and vulnerability assessments come before any deployment or redeployment of applications, infrastructure components and ICT services supporting critical or important functions (Article 25(2)).
Next step: DORA Gap AnalysisApplies whatever your size, calibrated by Article 4; Article 16 is not open to CSDs. You keep at least one secondary processing site with a distinct risk profile (Article 12(5)), provide your competent authority with copies of ICT business continuity test results (Article 11(9)) and run vulnerability assessments before any deployment or redeployment (Article 25(2)).
Next step: Business Impact Analysis ToolkitApplies whatever the size of the venue, calibrated by Article 4: Article 3(60) excludes trading venues from the microenterprise definition, and Article 16 is not open to them. Your ICT systems must cope with peak order and message volumes and with stressed market conditions (Article 7).
Next step: DORA Gap AnalysisNot sure your entity is a financial entity at all? Run the free scope determination.
Central counterparties, central securities depositories and trading venues are explicitly listed as financial entities under DORA (Regulation (EU) 2022/2554), with CSDs named in Article 2(1)(g), CCPs in Article 2(1)(h) and trading venues in Article 2(1)(i). The same digital operational resilience rules that apply to banks and investment firms therefore apply to the institutions that clear, settle and match the bulk of European financial transactions. DORA has applied since 17 January 2025, and for these infrastructures it sits on top of already demanding sector regimes under EMIR, CSDR and MiFID II.
For market infrastructures this is not a paperwork exercise. CCP clearing and CSD settlement are critical functions whose outage can halt entire markets, and a trading venue's matching engine processes orders continuously, so recovery objectives must weigh the impact on market efficiency. Most of these entities depend on market-data feeds, connectivity providers, colocation facilities and a small number of specialised technology vendors they do not fully control. DORA forces these operational realities into a governed framework: a board-owned ICT risk strategy, a tested incident response capability, threat-led penetration testing for the most systemically important firms, and contractual control over the third parties that keep clearing, settlement and trading online.
CCPs (DORA Art. 2(1)(h)), CSDs (Art. 2(1)(g)) and trading venues, that is regulated markets, MTFs and OTFs (Art. 2(1)(i)), are all DORA financial entities, and each already carries strong sector resilience duties: EMIR requires CCPs to maintain operational reliability and business continuity, CSDR requires CSDs to manage operational risk and maintain continuity arrangements, and MiFID II requires trading venues to ensure systems resilience, sufficient capacity and orderly trading. DORA applies proportionately under Article 4, but proportionality is limited here because these entities are systemically critical: a small CSD or niche trading venue still operates infrastructure whose failure has market-wide consequences, so the digital operational resilience expectations are the highest of any sector and no infrastructure is exempt from the core ICT risk, incident-reporting, testing and third-party rules.
National Competent Authorities authorise and supervise CCPs, CSDs and trading venues under EMIR, CSDR and MiFID II, with ESMA coordinating at EU level; the ECB and members of the ESCB are involved in the oversight of CCPs and CSDs, and supervisory colleges are convened for systemic infrastructures.
EMIR, CSDR and MiFID II already impose operational-resilience duties on market infrastructures: EMIR Article 34 requires CCPs to maintain business continuity and disaster-recovery arrangements that ensure timely recovery of operations, CSDR Article 45 requires CSDs to identify and manage operational risk and to maintain robust business continuity and disaster recovery, and MiFID II Article 48 (operationalised by Commission Delegated Regulation (EU) 2017/584, known as RTS 7) requires trading venues to ensure systems resilience, adequate capacity, tested failover, business continuity and circuit breakers. DORA acts as the cross-sectoral lex specialis that deepens and standardises the ICT dimension of those duties. Rather than running parallel programmes, firms should map their EMIR Art. 34, CSDR Art. 45 and MiFID II Art. 48 / RTS 7 obligations onto DORA's five pillars so a single control set satisfies all the regimes: DORA's ICT risk framework operationalises the existing continuity and operational-risk clauses, and DORA incident reporting feeds the same evidence base competent authorities and colleges already expect. The challenge unique to market infrastructures is meeting these requirements at systemic scale, where recovery objectives must weigh the impact on market efficiency (Article 12(6)) and a control gap matters to the ESCB members and supervisory colleges involved as well as to the competent authority.
Six obligations that play out differently in your sector. Open a card for the detail.
Competent authorities identify the financial entities that must perform threat-led penetration testing on the basis of their impact, systemic character and ICT risk profile (Article 26(8)). A CCP, a CSD or a major trading venue should prepare for the advanced, intelligence-led cycle (at least every three years, aligned with TIBER-EU) rather than assume it will not be identified.
A trading venue's matching engine, gateways and market-data dissemination are critical functions whose failure stops the market. DORA's resilience requirements reinforce MiFID II Article 48 and RTS 7: documented capacity headroom for peak and stressed message rates, tested failover, latency and throttling monitoring, and circuit breakers that halt orderly when systems degrade.
Clearing and settlement cannot tolerate extended downtime. DORA's ICT business-continuity and recovery requirements (Articles 11-12) build on EMIR Article 34 and CSDR Article 45: redundant capacity (for CSDs, a secondary processing site under Article 12(5)), recovery objectives set with regard to the impact on market efficiency (Article 12(6)), documented recovery point objectives, and regular live failover and data-integrity testing of the settlement and margining engines.
Market infrastructures depend on a small number of market-data feeds, network and connectivity providers, colocation facilities and specialised matching or clearing technology vendors. DORA's third-party rules (Articles 28-30) require these to be inventoried in the register of information, risk-assessed for concentration and substitutability, and contractually governed with audit and access rights and tested fallbacks.
For a CCP, novation, margining and default management are critical functions; for a CSD, securities settlement and the maintenance of securities accounts are critical functions. DORA requires each to be identified, mapped to its supporting ICT assets, protected and recovered to demanding objectives, because an outage in any of them halts the market rather than merely inconveniencing one firm.
Resilience evidence for these infrastructures is examined not only by the national authority but by ESMA, the ECB and ESCB members in their oversight of CCPs and CSDs, and by supervisory colleges for systemic entities. DORA reporting and testing outputs must be fit to satisfy this multi-authority, cross-border audience, with consistent evidence across all the regimes in scope.
8 questions drawn from the requirements above. Each gap you declare comes back with the course that covers it and the tool that does the work. Your answers stay in this browser.
Has your management body approved an ICT risk management framework that maps clearing, settlement or order matching to their ICT assets and to your EMIR, CSDR or MiFID II resilience duties?
Are RTO and RPO documented for your clearing, settlement and matching systems, set with regard to the impact on market efficiency, and is the switchover to redundant capacity or your secondary site tested at least yearly?
Do you test every ICT system supporting a critical or important function at least yearly, including capacity under peak and stressed volumes and, for a CCP or CSD, a vulnerability assessment before each deployment?
Have you recorded whether your competent authority has identified you for TLPT, and mapped the critical or important functions and live production systems a test would cover?
Can your incident desk classify a matching-engine, settlement or margining outage against Delegated Regulation (EU) 2024/1772 and file the initial notification within 4 hours of classifying it as major?
Are your market-data, connectivity, colocation and matching or clearing technology providers recorded in your Register of Information?
Have you assessed concentration and substitutability for those providers, and do your contracts carry the Article 30 clauses, with an exit strategy for every service supporting a critical or important function?
Does your management body follow specific ICT risk training on a regular basis, and do all staff complete digital operational resilience training?
You declared 0 areas to work on, gaps first. Each one names what to learn and what to use.
Indicative self-assessment based on your own answers, not a compliance opinion. Prices exclude VAT.
Your score and your priorities, each with the course and the tool that cover it. The newsletter only if you tick the box.
Three reports to your competent authority, each with its own clock. Enter two times to see your deadlines.
Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it.
Enter the classification timeWithin 72 hours of submitting the initial notification, and updated when the situation changes.
Follows the initial notificationWithin one month of the latest intermediate report, once the root cause analysis is complete.
Follows the intermediate reportDelegated Regulation (EU) 2025/301, Article 5; classification under Delegated Regulation (EU) 2024/1772. The later deadlines assume each report goes in at its latest permissible time. A deadline falling on a weekend or bank holiday moves to noon of the next working day (Article 5(4)), except for the initial notification and intermediate report of credit institutions, central counterparties, operators of trading venues and essential or important entities under NIS2, or where your competent authority has decided otherwise (Article 5(5) and (6)); the dates shown do not apply that extension.
For market infrastructures the most consequential ICT incidents are matching-engine or trading-platform outages, settlement failures or delays at a CSD, margining or default-management disruption at a CCP, market-data dissemination failures, and connectivity or colocation losses that cut participants off from clearing, settlement or trading; a corrupted order book or distorted price feed can also qualify where an ICT failure threatens market integrity. DORA (Article 19 and the related RTS/ITS) requires major incidents to be classified against thresholds such as clients and counterparties affected, transactions and amounts affected, duration, geographic spread, data losses, criticality of services and economic impact, then reported to the competent authority on a strict clock: an initial notification, an intermediate report, and a final root-cause report. Because these systems sit at the centre of the market and an outage propagates to every connected participant within minutes, detection and classification have to run continuously: the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it, and for CCPs and operators of trading venues the weekend extension does not apply to it (Delegated Regulation (EU) 2025/301, Article 5). Always-on monitoring, pre-drafted templates and a tested escalation path to your competent authority are essential.
When a matching engine, a margining run or a settlement batch fails, the person who classifies the incident starts the reporting clock: the initial notification is due within 4 hours of classifying it as major. Your continuity team sets recovery objectives that must weigh the impact on market efficiency. Your outsourcing lead negotiates Article 30 rights with market-data, connectivity and colocation providers that are hard to replace. Your management body approves the ICT risk management framework and has to keep its own knowledge current. Each role needs to know what DORA expects of it.
Members of the management body must “actively keep up to date with sufficient knowledge and skills” to understand and assess ICT risk, including by following specific training on a regular basis.
Regulation (EU) 2022/2554, on EUR-Lex Article 13(6) · All staffICT security awareness programmes and digital operational resilience training are “compulsory modules” of staff training, for all employees and senior management, at a level that matches each function.
Regulation (EU) 2022/2554, on EUR-LexOwns the DORA programme, the mapping of EMIR, CSDR or MiFID II resilience duties onto DORA, and the evidence file your competent authority will ask for.
The first lesson is open to read before you buy.
Classifies matching-engine, settlement, margining or market-data outages against Delegated Regulation (EU) 2024/1772 and drafts the initial, intermediate and final reports.
The first lesson is open to read before you buy.
Sets RTO and RPO for clearing, settlement and trading systems, and runs the yearly switchover and recovery tests, including to the secondary processing site where one is required.
The first lesson is open to read before you buy.
Handles market-data, connectivity, colocation and specialised technology providers: Register of Information, concentration and substitutability, Article 30 clauses and exit strategies.
The first lesson is open to read before you buy.
Approves the ICT risk management framework and the ICT business continuity policy, and must keep its ICT risk knowledge current, including through specific training (Article 5(4)).
The first lesson is open to read before you buy.
Several people to train? Team seats cost less per learner from 2 seats, on one invoice: see team pricing.
Starting out? DORA Fundamentals is free, certificate included.
The tools that matter most for your sector, and what each one does for you.
Draft the initial notification for a matching-engine halt, a settlement failure or a margining outage, with the reporting deadlines computed.
Open €149Set MTPD, RTO and RPO for clearing, settlement and matching systems, weighing the impact on market efficiency as Article 12(6) requires.
Open FreeCheck how ready the live production systems behind clearing, settlement and trading are for TLPT, should your competent authority identify you.
Open Free to build · export licence €249 a yearEnter market-data, connectivity, colocation and technology providers in the ITS templates and run the validation rules before submission.
Open FreeScore your ICT third-party service providers and see where reliance on a few specialised providers calls for an exit strategy first.
Open FreeMeasure your position on the five pillars and prioritise the gaps your EMIR, CSDR or MiFID II controls leave open.
OpenAll tools: browse the full list. Prices exclude VAT.
Everything tailored to your sector, ready to use on day one.
Yes. CCPs are named in DORA Article 2(1)(h), CSDs in Article 2(1)(g) and trading venues in Article 2(1)(i), so all of DORA applies in full. Your sector regime gives you market authorisation and sets your operational duties; DORA governs and standardises the ICT and digital operational resilience side of running the infrastructure, and your authority will expect evidence of both.
Treat DORA as the detailed ICT framework that operationalises your existing obligations: EMIR Article 34 business continuity for CCPs, CSDR Article 45 operational risk and continuity for CSDs, and MiFID II Article 48 with RTS 7 systems resilience and capacity for trading venues. Map a single control set to DORA's five pillars and reuse it as evidence across all the regimes rather than building separate programmes.
Your competent authority decides. TLPT under DORA Articles 26-27 applies to the entities it identifies on the basis of their impact, systemic character and ICT risk profile (Article 26(8)), and CCPs, CSDs and major trading venues sit at the systemic end of that assessment. Prepare for the intelligence-led cycle (at least every three years, aligned with TIBER-EU), while still maintaining the full proportionate testing programme of vulnerability scans, penetration tests and scenario-based resilience tests.
DORA does not set a fixed number: Article 12(6) requires recovery objectives that take into account whether a function is critical or important and the potential overall impact on market efficiency. This aligns with EMIR Article 34 and CSDR Article 45 expectations of timely recovery and with MiFID II Article 48 tested failover. Document and regularly test your recovery time and recovery point objectives at a secondary site for the matching, margining and settlement engines.
Yes, where you depend on them to deliver clearing, settlement or trading they fall within DORA's third-party rules (Articles 28-30). They must appear in your register of information, be risk-assessed for concentration and substitutability, be backed by tested fallbacks where feasible, and carry audit, access and termination rights in contract. Concentration in a small pool of specialised providers makes this assessment especially important.
Yes. DORA Articles 31-44 establish an EU oversight framework for ICT providers designated as critical to the financial sector, and the matching, clearing, market-data and connectivity vendors that several infrastructures share are plausible candidates. You should flag any such vendor in your register, monitor its potential designation, and ensure your concentration and exit analysis accounts for a provider whose disruption could affect multiple infrastructures at once.
Need the full risk view? See the Risk Assessment Toolkits or compare all kits. All prices exclude VAT; an EU VAT invoice is issued at checkout. Professional templates, not legal advice.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.