DORA Certifications Bundle
399 € excl. VAT
DORA Sector Guide
DORA for Investment Firms (MiFID II)
DORA for MiFID II investment firms: trading-system resilience, algo controls and proportionate ICT risk management.
DORA for MiFID II investment firms: trading-system resilience, algo controls and proportionate ICT risk management.
Which of these describes your firm?
Applies by operation of law to investment firms meeting the conditions of IFR Article 12(1). Article 16 replaces Articles 5 to 15 only: incident reporting, the Register of Information and ICT third-party risk management still apply, proportionately (Article 4(2)). TLPT does not apply (Article 26(1)). Monitor the IFR conditions as you grow.
Next step: DORA Compliance ChecklistApplies whatever your size if you do not meet the IFR Article 12(1) conditions, calibrated by the proportionality principle of Article 4. Such a firm cannot elect Article 16. If you trade algorithmically, your RTS 6 controls stay in force alongside the framework.
Next step: DORA Gap AnalysisDORA does not apply to natural or legal persons exempted pursuant to Articles 2 and 3 of MiFID II (Directive 2014/65/EU). If you also hold an authorisation listed in Article 2(1), run the scope check for that activity.
Next step: DORA Scope DeterminationNot sure your entity is a financial entity at all? Run the free scope determination.
Investment firms authorised under MiFID II sit squarely within DORA's scope, and for many trading-driven firms ICT is not a back-office concern but the core of the business: order routing, execution, market-data ingestion and risk checks all run on systems whose downtime translates directly into missed fills, mispriced positions and best-execution failures. DORA reframes these operational dependencies as a regulated resilience obligation, requiring a documented ICT risk-management framework, incident reporting, resilience testing and tight oversight of the vendors, venues and data feeds the firm relies on.
What makes investment firms distinctive is the overlap between DORA and the pre-existing MiFID II algorithmic-trading regime. RTS 6 (Commission Delegated Regulation (EU) 2017/589) already mandates pre-trade controls, kill-switch functionality, system testing and capacity monitoring for firms engaged in algorithmic trading. DORA does not replace these obligations but wraps them in a horizontal, group-wide resilience framework, and firms that treat the two regimes as one integrated control set, rather than parallel compliance silos, will both reduce duplication and close the gaps that supervisors are most likely to probe.
DORA applies to investment firms within the meaning of MiFID II under Article 2(1)(e) of Regulation (EU) 2022/2554, so almost all authorised investment firms are in scope regardless of size. However, the regulation is proportionate: the simplified ICT risk-management framework of Article 16 applies, in place of Articles 5 to 15, to firms classified as small and non-interconnected under Article 12(1) of the Investment Firms Regulation (IFR, (EU) 2019/2033), broadly the IFD/IFR "class 3" cohort, while larger class 2 firms must apply the full Article 5-15 framework. Microenterprises also benefit from lighter testing and governance expectations, but no investment firm is exempt outright, and even class 3 firms must still report major incidents and manage third-party ICT risk.
Supervised by national competent authorities (NCAs) under MiFID II/IFD, with ESMA setting RTS and coordinating, and the ESAs jointly overseeing critical ICT third-party providers under DORA.
DORA operates alongside MiFID II rather than overriding it: the RTS 6 obligations on algorithmic trading systems (pre-trade limits, real-time monitoring, kill-switch, conformance and stress testing, business-continuity arrangements) remain in force and now feed directly into the DORA ICT risk and resilience-testing framework. Order-routing engines, smart order routers and market-data feeds become "ICT systems supporting critical or important functions," so their availability, capacity and failover must be evidenced under DORA Articles 8-12 while still satisfying MiFID II best-execution (Article 27) and orderly-trading duties. In practice firms should map each RTS 6 control to a DORA framework element so that testing, change management and incident handling are governed once, not twice.
Six obligations that play out differently in your sector. Open a card for the detail.
Order-management, execution and matching engines are ICT systems supporting critical or important functions, so DORA requires documented availability targets, capacity management and tested failover. Outages must be detectable in real time and recoverable within defined RTOs, with evidence retained for supervisors. This dovetails with RTS 6 capacity and resilience requirements already binding on algorithmic-trading firms.
RTS 6 already mandates a kill-switch to cancel orders and halt algorithms; DORA elevates this into the ICT resilience framework, requiring it to be tested, access-controlled and integrated with incident response. The firm must be able to demonstrate who can trigger it, how fast it acts, and that it is exercised regularly. Failure of the kill-switch itself should be treated as a potential major ICT-related incident.
Reliance on co-located infrastructure, exchange gateways and real-time market-data vendors creates concentration and latency-sensitivity that DORA treats as third-party ICT risk. Firms must monitor feed integrity, staleness and failover to secondary feeds, since corrupted or stale data can drive mispriced orders and best-execution breaches. Data-feed contracts must include DORA Article 30 resilience and audit clauses.
MiFID II best-execution (Article 27) depends on the integrity of pricing data, venue connectivity and the algorithms that route orders, all of which are ICT dependencies under DORA. An ICT incident degrading connectivity or data quality can therefore become a conduct as well as a resilience failure. Mapping execution-quality risks to ICT controls links DORA testing to demonstrable best-execution outcomes.
Many firms outsource order/execution management systems (OMS/EMS), post-trade processing or even whole trading platforms to third parties. Under DORA Articles 28-30 these arrangements need a register of information, exit strategies, security and audit rights, and assessment of ICT concentration. Sub-outsourcing of the OMS/EMS stack must be traced and contractually controlled.
Class 3 (small and non-interconnected) investment firms apply the simplified ICT risk-management framework of DORA Article 16 instead of the full Articles 5-15. This still requires identifying critical functions, protective measures, incident detection and recovery, but with lighter governance and testing expectations. Firms near the class 2/class 3 boundary should monitor whether growth tips them into the full regime.
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.
Is your ICT risk management framework (full or Article 16) documented, covering order routing, execution, market data and risk checks, with RTS 6 controls mapped into it where they apply?
Do your order-management and execution systems have a business impact analysis with RTO and RPO targets, capacity monitoring and a failover you have tested?
Does your risk-based testing programme cover failover of trading systems, secondary market-data feeds and, if you trade algorithmically, the kill-switch, and have you recorded whether TLPT applies to you?
Can your incident process classify an ICT-related incident against the criteria of Delegated Regulation (EU) 2024/1772 and file the initial notification within 4 hours of classifying it as major?
Have you pre-mapped trading-floor scenarios (outage, erroneous orders, market-data corruption, loss of venue connectivity) to the classification criteria, and aligned DORA reporting with your MiFID II orderly-trading and venue-notification duties?
Are your OMS/EMS, post-trade, co-location and market-data providers recorded in your Register of Information, with any subcontracting of the OMS/EMS stack traced?
Do your contracts with ICT third-party service providers contain the Article 30 clauses, with a documented exit strategy for the OMS/EMS, market-data and co-location services that support critical or important functions?
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 investment firms a major ICT-related incident often manifests as a trading outage, an erroneous-order event, a market-data corruption, or loss of venue connectivity, any of which can cause direct market impact and client harm. Classification under the RTS on incident classification (Commission Delegated Regulation (EU) 2024/1772) turns on criteria such as clients/transactions affected, data losses, duration and geographic spread, and a major incident triggers the staged reporting timeline (initial notification, intermediate and final reports) to the NCA. Firms should pre-map trading-floor scenarios to these thresholds so the desk, risk and compliance can decide quickly whether an event is reportable, and align this with any parallel MiFID II orderly-trading and venue-notification duties.
The person who decides whether a trading outage, an erroneous-order event or a market-data corruption is a major ICT-related incident starts the reporting clock: the initial notification is due within 4 hours of classifying it as major. Your outsourcing manager negotiates Article 30 clauses with OMS/EMS, co-location and market-data providers that may be hard to replace. Your compliance lead applies the IFR Article 12(1) test that decides between Article 16 and the full framework. Your management body oversees the framework and keeps its 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-LexUnder the simplified framework of Article 16, the same duty comes from Article 16(1)(h): ICT security awareness programmes and digital operational resilience training for staff and management, according to needs and ICT risk profile.
Owns the DORA programme, the IFR Article 12(1) check behind the full or Article 16 framework, the RTS 6 control map and the evidence your competent authority may ask for.
The first lesson is open to read before you buy.
Decides whether a trading outage, erroneous-order event or market-data corruption is major under Delegated Regulation (EU) 2024/1772, and drafts the initial, intermediate and final reports.
The first lesson is open to read before you buy.
Handles OMS/EMS, post-trade, co-location and market-data providers: Register of Information, Article 30 clauses, subcontracting chains, concentration and exit strategies.
The first lesson is open to read before you buy.
Runs order-management and execution systems: capacity and failover, kill-switch and secondary-feed tests, and the RTO and RPO evidence behind them.
The first lesson is open to read before you buy.
Oversees the ICT risk management framework and must keep its ICT risk knowledge current through specific, regular training (Article 5(4)). Under Article 16, management training follows your needs and ICT risk profile.
The first lesson is open to read before you buy.
For MiFID investment firms: compliance, ICT risk, third-party oversight and the Register of Information for delegation-heavy models.
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.
Test a past trading outage, erroneous-order event or market-data corruption against the major-incident criteria of Delegated Regulation (EU) 2024/1772.
Open Initial report free · full drafts €99Draft the initial notification for a trading or venue-connectivity outage, with the 4-hour, 72-hour and one-month deadlines computed.
Open Free to build · export licence €249 a yearEnter OMS/EMS, post-trade, co-location and market-data providers in the ITS templates and run the validation rules before reporting to your competent authority.
Open FreeScore your OMS/EMS, market-data and co-location providers and see which ones need an exit strategy first.
Open €149Set MTPD, RTO and RPO for order-management, execution and market-data systems in one workbook.
Open FreeAnswer 16 questions on the five pillars and get a prioritised list of gaps, whether the full framework or Article 16 applies.
OpenAll tools: browse the full list. Prices exclude VAT.
Everything tailored to your sector, ready to use on day one.
No. All MiFID II investment firms are in scope under Article 2 of DORA. However, firms classified as small and non-interconnected under IFR Article 12 (broadly class 3) apply the simplified ICT risk-management framework of DORA Article 16, and microenterprises face lighter testing and governance expectations. Even these firms must still report major ICT incidents and manage third-party ICT risk.
No, the two regimes coexist. RTS 6 (Delegated Regulation (EU) 2017/589) obligations such as pre-trade controls, kill-switch, testing and capacity monitoring remain fully in force. DORA wraps them inside a horizontal ICT risk-management and resilience-testing framework, so the cleanest approach is to map each RTS 6 control to its DORA framework element and govern them as one integrated control set.
Only a subset of firms must perform TLPT under DORA Articles 26-27; it is targeted at firms identified by authorities as significant from an ICT and systemic perspective, based on criteria in the relevant RTS. Most smaller investment firms will not be designated and instead carry out the standard digital operational resilience testing programme (vulnerability scans, scenario tests, etc.) under Article 24-25. You should confirm your status with your NCA rather than assume.
Yes. Real-time market-data feeds, co-location, exchange gateways and OMS/EMS providers are ICT third-party services supporting trading functions, so they fall under DORA Articles 28-30. They must appear in your register of information, be assessed for concentration risk, and their contracts must include the mandatory provisions on security, audit rights, sub-outsourcing and exit. Some major providers may also be designated as critical ICT third-party providers subject to direct ESA oversight.
Apply the criteria in the RTS on incident classification (Delegated Regulation (EU) 2024/1772): clients and transactions affected, data losses, reputational impact, duration, service downtime, geographical spread, economic impact and criticality of services. A trading outage, erroneous-order cascade or market-data corruption breaching these thresholds is a major incident and triggers staged reporting to your NCA. Pre-mapping desk scenarios to these thresholds speeds the reportability decision.
Best execution under MiFID II Article 27 depends on accurate pricing data, reliable venue connectivity and sound routing logic, all of which are ICT dependencies under DORA. An ICT failure that degrades data quality or connectivity can therefore become both a resilience and a conduct breach. Linking execution-quality risks to DORA ICT controls lets you evidence best execution and operational resilience from the same testing and monitoring.
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.