DORA operational resilience for occupational pension funds, built for lean, heavily outsourced schemes that depend on third-party administrators, asset managers and custodians.
How many members do your pension schemes have in total?
DORA does not apply to an IORP operating pension schemes which together do not have more than 15 members in total. Keep the count under review: from 16 members DORA applies, with the simplified framework of Article 16 until you reach 100.
Next step: DORA Scope DeterminationA small IORP (fewer than 100 members in total) applies Article 16, which replaces Articles 5 to 15 only. Incident reporting, resilience testing and ICT third-party risk still apply, proportionately (Article 4(2)). Article 26(1) leaves small IORPs outside TLPT.
Next step: DORA Compliance ChecklistApplies to every IORP with 100 members or more in total, calibrated by the proportionality principle of Article 4. Outsourcing administration, asset management or custody does not move the obligations: the IORP remains fully responsible (Article 28(1)(a)). TLPT applies only if your competent authority identifies you (Article 26(8)).
Next step: DORA Gap AnalysisNot sure your entity is a financial entity at all? Run the free scope determination.
Institutions for occupational retirement provision are named as financial entities under DORA (Regulation (EU) 2022/2554, Article 2(1)(p)), so the digital operational resilience rules that govern banks and insurers also reach pension funds. DORA has applied since 17 January 2025, and an IORP that is in scope must now evidence a board-owned ICT risk framework, incident reporting, resilience testing and contractual oversight of the technology providers that keep member benefits flowing.
For IORPs this lands differently than for most other financial entities. Pension funds are typically small, run by lean boards and tiny in-house teams, and they outsource almost everything that touches technology: scheme administration to third-party administrators, investment to external asset managers, safekeeping to custodians and record-keeping to specialist platforms. DORA recognises this reality through proportionality, a simplified framework for small IORPs and an exclusion for the smallest schemes, but where it applies it forces the outsourced ICT chain into a governed framework so that a provider outage, a member-data breach or a delayed benefit payment is anticipated, contained and reported rather than discovered after the fact.
IORPs are DORA financial entities under Article 2(1)(p), and the Regulation itself sets the thresholds, with no national option to transpose: DORA does not apply to an IORP operating pension schemes which together have not more than 15 members in total (Article 2(3)(c)). An IORP whose schemes together have fewer than 100 members in total is a small IORP (Article 3(53)): it stays in scope and applies the simplified ICT risk management framework of Article 16 instead of Articles 5 to 15. From 100 members, the full framework applies. The count is the total across all the schemes the IORP operates, so a fund just over a threshold changes regime. Where DORA does apply, Article 4 proportionality scales the expectations to the IORP's size, nature, scale and complexity, so a small single-employer scheme that outsources everything carries lighter internal-control expectations than a large multi-employer fund, yet no in-scope IORP escapes the core ICT risk, incident-reporting and third-party rules.
National Competent Authorities supervise IORPs in each Member State (for example BaFin in Germany, DNB in the Netherlands, and the pensions or financial-conduct authority elsewhere), with EIOPA coordinating at EU level, issuing guidelines and maintaining the cross-border IORP register.
The IORP II Directive (Directive (EU) 2016/2341) already requires an effective system of governance, the three key functions (risk management, internal audit and actuarial) and, importantly, controls over outsourcing under Article 31, including the duty not to impair governance, increase operational risk or undermine supervision when activities are delegated. DORA acts as the cross-sectoral lex specialis that deepens the ICT dimension of those duties: rather than running two parallel programmes, an IORP should map its IORP II governance and Article 31 outsourcing arrangements onto DORA's five pillars so a single control set serves both. The risk-management key function naturally owns the DORA ICT risk framework, internal audit tests it, and the existing outsourcing register and due-diligence process becomes the backbone of DORA's register of information and third-party clauses. The practical challenge unique to IORPs is doing this with very little in-house IT, which makes third-party governance and proportionate documentation the dominant workstreams.
Six obligations that play out differently in your sector. Open a card for the detail.
Most IORPs delegate scheme administration, contribution collection, member record-keeping and benefit calculation to a third-party administrator (TPA) running its own ICT platform. DORA's third-party rules (Articles 28-30) require the TPA to be inventoried in the register of information, risk-assessed for concentration and substitutability, and held to contractual audit, access and exit rights, because the IORP remains accountable even though it owns little of the technology.
DORA excludes IORPs whose schemes together have not more than 15 members in total (Article 2(3)(c)); below 100 members in total, a small IORP applies the simplified framework of Article 16 (Article 3(53)); Article 4 proportionality scales the rest. The first task for any IORP is to establish its total member count and, from there, to right-size the framework so a lean scheme is not held to large-bank expectations.
The administration system that records entitlements and the member portal that lets people view and manage their pension are the IORP's critical or important functions. DORA expects these to be identified as critical ICT assets, with availability, integrity and recovery requirements set and monitored, even when the platform is hosted and operated by an outsourced provider.
External asset managers, custodians and fund-accounting providers deliver services through their own ICT systems on which the IORP depends to value assets, settle trades and safekeep holdings. Every arrangement for ICT services belongs in the Register of Information (Article 28(3)); where the dependency supports a critical or important function, the enhanced requirements apply: due diligence, the additional contractual clauses of Article 30(3) and consideration of concentration when several functions sit with the same group.
DORA's incident management (Articles 17-19) applies even though most IORPs have no 24/7 security operations centre. The realistic answer is to define a major-incident procedure that relies on the providers' detection and notification duties, secure contractual obligations on TPAs and asset managers to alert the IORP promptly, and pre-agree who classifies and submits the report to the NCA within the regulatory clock.
DORA does not require a new committee structure for a small IORP; it requires ownership. The risk-management key function can own the ICT risk framework, internal audit can provide independent assurance, and the management body must approve the strategy and oversee third-party risk, reusing the IORP II system of governance rather than building a parallel one.
7 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 the ICT risk management framework your member count requires (full, or Article 16 below 100 members), owned by the risk-management key function and given independent assurance by internal audit?
Are the administration platform and member portal identified as supporting critical or important functions, with recovery targets checked against your providers' continuity plans?
Can a named person classify an incident reported by your administrator or asset manager against the Article 18 criteria and file the initial notification within 4 hours of classifying it as major?
Are the ICT services provided by your administrator, asset managers, custodians, fund-accounting and hosting providers recorded in your Register of Information, with those supporting critical or important functions flagged?
Do your contracts with ICT third-party service providers contain the Article 30 clauses and an obligation to alert you promptly to incidents, with an exit plan for administration and custody services?
Do you run a proportionate testing programme that reviews your providers' test results and tests recovery of benefit payments, and have you recorded whether TLPT applies to you?
Does your management body follow ICT risk training on a regular basis, and do staff complete digital operational resilience training (Articles 5(4) and 13(6), or Article 16(1)(h) for a small IORP)?
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.
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 IORPs the most consequential ICT incidents are breaches of member personal and financial data, outages of the pension-administration platform or member portal, corruption of entitlement records, and disruptions that delay or misdirect the payment of benefits and pensions; many of these originate at an outsourced provider rather than inside the fund. DORA (Articles 18 and 19 and the related RTS/ITS) requires major incidents to be classified against thresholds such as the number of clients or members affected, amounts and duration, geographic spread, data losses, criticality of the affected services and economic impact, then reported to the NCA on a strict clock of an initial notification, an intermediate report and a final root-cause report. Because a lean IORP often learns of an incident only when its TPA or asset manager tells it, the reporting clock and the contractual notification duties on providers must be aligned in advance, with pre-drafted templates and a named person empowered to classify and submit, so that an outsourced breach still meets the early notification window.
In a lean IORP a handful of people carry every DORA decision. The risk-management key function owns the ICT risk framework and establishes whether the full or the Article 16 framework applies. Whoever manages the administrator and asset manager contracts negotiates Article 30 clauses and exit plans. The person named to classify incidents starts the reporting clock, often on the strength of a provider's alert. The management body approves the framework and oversees third-party risk. Each role needs to know what DORA expects of it, and to be able to show 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 ICT risk framework within the IORP II system of governance, establishes whether the full or Article 16 framework applies, and keeps the evidence your competent authority will ask for.
The first lesson is open to read before you buy.
Oversees the administrator, asset managers and custodians: Register of Information, Article 30 clauses, concentration within one group and exit plans for administration and custody.
The first lesson is open to read before you buy.
Classifies incidents reported by providers against the Article 18 criteria and drafts the initial, intermediate and final reports to your competent authority.
The first lesson is open to read before you buy.
Gives independent assurance on the ICT risk framework and on how the fund oversees the ICT services it outsources to its providers.
The first lesson is open to read before you buy.
Approves the ICT risk management framework, oversees ICT third-party risk and keeps its own 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.
Enter the ICT services of your administrator, asset managers, custodians and hosting providers in the ITS templates and run the validation rules before you report.
Open FreeScore your administrator, asset managers and custodians and see which ones need an exit plan first.
Open Initial report free · full drafts €99Draft the initial notification for an administration-platform outage or a member-data breach at a provider, with the reporting deadlines computed.
Open FreeTest a past provider outage or data breach against the major-incident criteria before you have to classify one under time pressure.
Open €149Set MTPD, RTO and RPO for the administration platform, member portal and benefit payments in one workbook.
Open FreeMeasure your position on the five pillars in 16 questions and get a prioritised list of gaps.
OpenAll tools: browse the full list. Prices exclude VAT.
Everything tailored to your sector, ready to use on day one.
It depends on your total member count, not on your Member State. IORPs are financial entities under DORA Article 2(1)(p). DORA does not apply where the IORP's pension schemes together have not more than 15 members in total (Article 2(3)(c)). Below 100 members in total you are a small IORP and apply the simplified framework of Article 16; from 100 members the full framework applies, scaled by Article 4 proportionality. A Regulation applies directly: there is no national transposition to check.
Yes, and outsourcing does not transfer accountability. Under DORA the IORP remains responsible for managing the ICT risk of its third-party administrator, asset managers and custodians: due diligence, contractual audit and access rights, monitoring, and a documented exit plan, all recorded in your register of information under Articles 28-30. Most of your DORA effort will sit in this third-party pillar precisely because so little technology is in-house.
Almost never. TLPT under DORA Articles 26-27 applies only to entities identified by their competent authority on the basis of their impact, systemic character and ICT risk profile (Article 26(8)), and small IORPs (fewer than 100 members in total) are excluded from it by Article 26(1). Every in-scope IORP must still run a proportionate testing programme such as vulnerability assessments and reviews of key systems, but full threat-led testing is unlikely to be required of a pension fund.
Treat DORA as the detailed ICT layer that deepens IORP II. IORP II already requires a system of governance, the three key functions and controls over outsourcing (Article 31); DORA standardises and extends the technology dimension of those duties. Map your IORP II governance and outsourcing arrangements onto DORA's five pillars so one control set, and one provider register, satisfies both regimes rather than running them separately.
You may still have to report it. If the incident at your TPA meets DORA's major-incident thresholds for your fund, the IORP is responsible for classifying it under Article 18 and notifying the NCA on the initial, intermediate and final report clock. Because you will often learn of it from the provider, your administration contract should oblige the TPA to alert you promptly and supply the facts you need, and you should have a named person and templates ready to classify and submit.
Use the structure IORP II already gives you. The risk-management key function is the natural owner of the ICT risk framework, internal audit provides independent assurance, and the management body approves the strategy and oversees third-party ICT risk. You do not need a large new function; you need clear ownership, proportionate documentation and reliable provider obligations.
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.