Does DORA apply to an occupational pension fund (IORP)?
DORA does not apply to occupational pension institutions whose schemes together have no more than 15 members. Article 2(3) excludes them entirely, while small institutions that do fall within scope keep a reduced set of obligations under Article 16(1), which disapplies the full ICT risk management articles for small institutions for occupational retirement provision. The scope question is therefore a counting and classification exercise that trustees or the administrator should complete before any system work starts. Count members across every scheme the institution runs, not scheme by scheme, and confirm with the national competent authority how it reads the small institution criteria and whether it has excluded any entity from the simplified regime.
The answer also determines what must be built. An institution that falls under the simplified regime still needs a documented ICT risk management framework, continuous monitoring of its ICT systems, prompt incident handling, identification of key ICT third-party dependencies, and backup and restoration plans for critical functions, tested regularly. Trustees own these controls and the management body carries responsibility for ICT risk under the simplified regime. An implementation partner can prepare systems, configuration records and evidence, but only an independent auditor or the supervisor issues findings. The main cost and timing drivers are the number of schemes and systems in scope, how much of the platform is self-hosted or outsourced, and how many third parties must be assessed. Ask for the scope decision and its basis in writing, signed by the trustees, before any quote is accepted.
Which DORA regime fits an IORP by scheme size
This table compares the three positions an occupational pension institution can occupy under DORA: exclusion for schemes with no more than 15 members, the simplified regime for small IORPs, and full obligations for larger institutions. Read each column against your scheme membership count and legal basis. The main takeaway is that the simplified regime relieves the detailed ICT framework rules but keeps incident reporting and continuity duties, so documenting your position matters in every case.
| Aspect | Excluded (15 members or fewer) | Simplified regime (small IORP) | Full DORA (larger IORP) |
|---|---|---|---|
| Legal basis | Article 2(3): schemes that together have no more than 15 members. | Article 16(1): small IORPs are disapplied from Articles 5 to 15. | Article 2(1): IORPs in scope with no size exclusion applied. |
| Core DORA obligations | No DORA obligations as a financial entity. Confirm national pension supervision rules. | Documented ICT risk framework, monitoring, incident handling, backup and restoration, regular testing. | Full Chapters II to V, scaled by proportionality under Article 4. |
| Relief | The entire regulation does not apply to the institution. | Articles 5 to 15 disapplied, plus TLPT (Article 26(1)) and third-party strategy (Article 28(2)). | No general relief. Proportionality under Article 4 still shapes depth. |
| Management body role | Not required under DORA. Pension governance under national law still applies. | Accountable for ICT risk, roles, objectives and a budget reviewed at least yearly (2024/1774, Article 28). | Accountable for ICT risk governance and approval of the full framework under Chapter II. |
| Incident reporting | No DORA incident reporting. Check national supervisory reporting duties. | Chapter III still applies, including major incident reporting under Articles 17 to 23. | Full Chapter III: classification, major incident reporting, voluntary threat notification. |
| Evidence to keep | Dated member count per scheme and combined total, approved by the board. | Applicability analysis under Article 16(1), ICT framework, dependency list, restoration test records. | Full policy set, register of information, testing records, third-party strategy, TLPT scoping decision. |
| Re-check trigger | Membership growth or pooled schemes that push the combined count above 15. | Membership growth, a change in the small-institution test under national law, or a new critical dependency. | Changes to Article 26 criteria or outcomes of the 2028 review under Article 58(1). |
What decides whether an IORP is excluded, simplified or fully in scope
An occupational pension institution does not fall into one DORA regime by default. Member counts, the small institution test, outsourcing and cross-border arrangements each move the answer, and they interact. Work through these drivers in order and record the result before deciding how far DORA applies.
Counting members across every scheme
The exclusion in Article 2(3) turns on whether the occupational pension institutions' schemes together have no more than 15 members, so the count covers every scheme the institution administers, not each scheme on its own. Multi-employer arrangements and schemes run for several sponsors can push a count over the line without anyone noticing. Keep a dated member register that reconciles all schemes, and re-run the count whenever a scheme opens, merges or closes.
Testing the small institution criteria
Institutions for occupational retirement provision that are small fall within the disapplication of Articles 5 to 15 under Article 16(1), which leaves them under the simplified framework. Being small is a legal test, not a self-declared label, so document the facts that place the institution in that category. Confirm the treatment with the national competent authority before relying on it, and ask for the answer in writing.
Outsourcing administration and IT
Many small pension institutions hand administration, recordkeeping or hosting to a service provider. Outsourcing does not remove obligations. The institution still has to identify its ICT third-party dependencies and keep continuity for critical or important functions, even where the Article 28(2) third-party strategy does not apply. Ask each provider for its contractual terms on incidents, audit access and exit, and record which functions depend on which provider.
Cross-border arrangements that change the count
A scheme sponsored from another member state, or members living across borders, can alter both the member count and which national authority supervises the institution. Cross-border cover should be mapped before the count is finalized, since a scheme added on one side of a border may move the institution out of the exclusion. Ask the relevant authorities which regime applies to the combined arrangement, and keep their written replies with the scope file.
Linking to IORP II Article 21(5)
Article 8 of Directive (EU) 2022/2556 amends Article 21(5) of IORP II so that the network and information systems of occupational pension institutions are managed in accordance with DORA where it applies. The IORP II requirement therefore points back to DORA's scope decision, so a wrong scope call affects both regimes. Map the scope conclusion to the IORP II governance documents, and update those documents whenever the scope conclusion changes.
Recording the scope decision
The outcome of the drivers above should sit in one signed scope memo: member count by scheme, the small institution assessment, outsourced functions, cross-border facts and the authority's written confirmation. Review it at least yearly, and after any change in membership, provider or sponsor. A memo that shows how the conclusion was reached is the evidence an assessor will ask for first.
What still applies to a small IORP under the simplified regime
A small occupational pension fund that qualifies for the simplified regime is not free of DORA. Article 16(1) disapplies Articles 5 to 15 for small institutions for occupational retirement provision, but the trustees must still keep a sound, documented ICT risk management framework and keep it in writing. The framework does not need the full depth of the Chapter II requirements, yet it must show who owns ICT risk, which systems the fund depends on, and how those systems are kept under control. In practice, that means the fund should be able to produce a short, current document describing its ICT environment, its key ICT third-party dependencies (administration platforms, member portals, hosting and payment or data feeds), and the steps it takes when something fails. The ongoing duties are operational. The fund must continuously monitor its ICT systems, use sound and updated tools, detect and handle incidents promptly, and identify its key ICT third-party dependencies. Where a function is critical or important, the fund needs continuity plans that include at least backup and restoration, and it must test those plans regularly. Confirm with your administrator or hosting provider exactly which backups exist, how long a restore takes, and when the last restore test was run and recorded. A backup that has never been restored is not evidence of continuity. Article 28 of Delegated Regulation (EU) 2024/1774 places governance on the management body. For a simplified-regime entity, the board of trustees must be responsible for ICT risk, approve clear roles and objectives, and set a budget that is reviewed at least yearly. Control and internal audit functions must be independent, and critical audit findings must be remediated in time. Trustees keep these duties even when a provider performs the technical work, so the board should minute its annual review and track findings to closure. Under Article 16(1), the trustees remain accountable for the outcome, whoever runs the systems.
How an IORP gets ready for DORA, from scope decision to evidence file
This sequence turns the question of whether DORA applies into a documented position, a governed ICT risk framework, mapped dependencies, tested continuity plans and an evidence file a supervisor can review.
Confirm scope and the member count in writing
Start by counting members across every scheme the institution runs, since the exclusion in Article 2(3) applies only where the schemes together have no more than 15 members. The trustees or management body confirm the figure with the administrator's records and the scheme documents, and the count is dated and signed. The output is a short scope memo stating which schemes are included and why. Ask any partner to confirm the count method before work starts, because a miscount changes every later step.
Record the decision and the national authority's position
Once scope is settled, record whether DORA applies in full, through the simplified regime for small institutions under Article 16(1), or not at all. Check the position of the national competent authority for occupational retirement provision, because supervisory practice and reporting expectations can differ between member states. The output is a signed decision record that cites the articles relied on and notes any authority correspondence. Ask counsel or the authority to confirm how the decision should be documented.
Approve ICT roles, objectives and budget
The management body approves who owns ICT risk, the objectives for the ICT risk framework and a budget for it. Under Article 28 of Delegated Regulation (EU) 2024/1774, the simplified-regime entity must have these reviewed at least yearly, and its control and internal audit functions must be independent. The output is a board minute with named roles, a written objective set and an approved budget. Confirm whether the administrator or an outsourced function will perform any control work, and document who supervises it.
Map ICT systems and key third-party dependencies
List the ICT systems that support member administration, contributions, benefit calculations, investment reporting and member communications. Record each dependency on the administrator, any hosting provider, cloud services, data feeds and software vendors, and note which functions are critical or important. The output is an asset inventory and a dependency map with a named owner for each entry. Where self-hosted open-source software runs inside the institution's own or a provider's infrastructure, record the hosting location and who operates it.
Set up backup, restoration and continuity plans
For each critical or important function, document backup arrangements, restoration steps and a continuity plan. Article 16(1) requires at least backup and restoration, and the plans must be tested regularly. Run a restoration test on a representative system and record the result, including what failed and how it was corrected. The output is a tested plan with a test log. Ask any partner to show how restoration tests are scheduled and recorded, and who signs off on the results.
Assemble the evidence file for supervisory review
Gather the scope memo, decision record, board minutes, asset inventory, dependency map, continuity plans, test logs and any incident records into one indexed file. Each document should show its owner, approval date and review date. The output is an evidence file that a supervisor could follow without help from the people who wrote it. Keep the file under change control so later versions are traceable. Ask whether any document must be translated or submitted in a particular format for the national authority.
Schedule the yearly budget and governance review
Set a recurring review of the ICT risk objectives, budget, roles, dependency map and continuity test results, and place it on the management body calendar. The review checks whether the framework still matches the scheme and the systems in use. The output is a dated review record and a list of actions with owners. Ask any partner for a phased timeline tied to the written scope, since no fixed durations apply to every institution, and confirm which parts of the ongoing cycle are internal and which are supported under a retainer.
How the IORP II amendment links pension governance to DORA
The IORP II amendment does not create a separate ICT regime for pension funds. Article 8 of Directive (EU) 2022/2556 amends Article 21(5) of IORP II so that an occupational pension institution's network and information systems are managed in accordance with DORA where DORA applies. In practice, the pension governance provisions in IORP II point back to DORA, and the directive's measures applied from 17 January 2025. The reader's first task is therefore still the scope test under Article 2 of DORA and the exclusion for schemes with no more than 15 members. The amendment only matters once that test has placed the institution inside DORA, or in a position where DORA's requirements are the reference point for its systems.
Because the link runs through IORP II, the scope decision belongs in the governance file, not only in an IT or security folder. Record the member count used for the exclusion test, the date of the assessment, the person who signed it off and the reasoning for any simplified-regime treatment. Confirm with your national competent authority how it has applied the IORP II provisions and whether it expects any additional notification or documentation. Those national details differ and should come from the authority itself, not from a summary.
Ask your board and your service providers to confirm who is accountable for the outcome. If DORA applies, the management body must own ICT risk, and a scheme that relies on an external administrator or platform provider should check how that provider's systems are covered in the same governance record. Revisit the decision whenever membership changes, because the 15-member threshold is the point at which the analysis can shift.
Who does what: trustees, administrators, an implementation partner and the supervisor
The trustees, or whoever sits as the management body of the institution, own the ICT risk management framework and remain accountable for it even when work is outsourced. For a small IORP that falls under the simplified regime, Article 28 of Delegated Regulation (EU) 2024/1774 places responsibility for ICT risk, roles, objectives and a budget on this body, and requires that budget to be reviewed at least yearly. Trustees approve the policies, accept residual risk and decide what to fund. Signing a policy does not transfer its obligations to a provider.
- Ownership: Trustees assign named roles for ICT risk and confirm who answers for each critical function.
- Budget: They approve the ICT budget and review it at least yearly, including money for testing and remediation.
- Policies: They sign and periodically review the documents the framework depends on.
- Independence: Control and internal audit functions must be independent of the people they check, and critical audit findings must be remediated in time.
- Records: They keep minutes showing decisions on ICT risk.
Before relying on any partner's evidence, check that the trustees can explain each control in their own words and show who reviewed it.
Most IORPs outsource administration, custody, hosting or software to third parties. Each provider runs its own controls under its contract, and the IORP keeps the responsibility for overseeing them. The contract should set out how the provider supports incident reporting, testing, access to records and exit. Under the simplified regime, the IORP is not required to adopt the full third-party strategy, but it must still identify its key ICT dependencies and show how it would keep critical functions running.
- Own controls: The administrator secures its own systems and reports its own assurance to the IORP.
- Incident cooperation: The contract defines timely notice, log sharing and joint post-incident review.
- Contract terms: Ask for audit or information rights, subcontracting visibility and a documented exit route.
- Assurance documents: Request independent reports the provider already holds, and confirm their scope and period.
- Continuity: Confirm backup and restoration arrangements the provider performs for the IORP's data.
Confirm with each provider which controls it operates, which it has outsourced in turn, and what it will supply within the contract's notice period.
An implementation partner such as DeployOpen prepares systems, documentation and evidence on the IORP's behalf, within a written scope. For self-hosted open-source platforms, that can include hardening, configuring logging and backups, building the asset inventory and drafting policy material for trustee review. Where contracted, the partner can also run security testing on in-scope systems and report the findings to the client. The partner does not own the controls, does not sign policies, and does not issue reports or attestations. Those remain with the IORP, and any independent findings come from an assessor.
- Preparation: Systems, configuration baselines and evidence collection are built to a written scope.
- Documentation: Drafts of procedures and records go to the trustees for review and approval.
- Testing: Security tests on in-scope systems are delivered as findings with remediation advice.
- Limits: The partner does not certify compliance or act as the independent check on its own work.
- Handover: The client keeps the configuration, runbooks and evidence so it can operate them without the partner.
Ask for the written scope, the list of deliverables and a statement that the partner does not issue assurance reports before work starts.
The national competent authority for the IORP supervises compliance with DORA, using the powers in Article 50, and the supervisor's view of the institution comes from the Member State's own supervisory process. DORA sets no certification scheme, so there is no DORA certificate for the IORP to obtain. Any independent examination, such as an internal audit review or an external assessment that the institution commissions, is performed by an independent auditor or assessor who issues the findings. Where a threat-led penetration test is required, the authority-issued attestation under Article 26(7) is the only attestation DORA provides for, and that regime does not apply to entities under Article 16(1).
- Supervision: The national authority decides how it examines the institution and what it requests.
- No certification: Compliance is shown through evidence and supervisory review, not a DORA certificate.
- Independent findings: Auditors and assessors state their own conclusions in their own reports.
- Scope limits: Confirm with the authority whether any testing or reporting duty applies to a small IORP.
- Records: Keep the evidence that a supervisor or assessor would ask to see.
Confirm with your national competent authority how it expects small IORPs to demonstrate compliance and whether it asks for any attestation.
What a pension fund must have in place before a supervisor asks
Small occupational pension schemes that fall under the simplified regime still need a working ICT control set. The six items below are the records a supervisor is most likely to ask for, and each one can be checked internally before a review starts.
Documented ICT risk management framework
The institution needs a written ICT risk management framework that the management body has approved, covering how ICT risk is identified, protected against, detected, responded to and recovered from. Under the simplified regime, Delegated Regulation (EU) 2024/1774 makes the management body responsible for ICT risk, roles and objectives. To check it internally, confirm the framework carries an approval date, names an owner for each control area, and was reviewed in the last year.
Current inventory of ICT systems and providers
A supervisor will expect a list of the ICT systems that support the scheme's administration, member data and payments, along with the providers that run or host them. The inventory is the starting point for judging which functions are critical or important and which dependencies need contract attention. Check that every system has an owner, a classification and a link to the provider that supplies it, including self-hosted open-source components.
Backup and restoration tests with dated records
For a simplified-regime institution, plans for critical or important functions must include at least backup and restoration, and those plans must be tested regularly. A supervisor will ask for test records, not just a policy. Check that each test has a date, the system tested, the restore time achieved, who ran it and what failed and was fixed.
Incident detection and handling records
The institution must detect and handle ICT incidents promptly, which means keeping a log of what was detected, how it was classified and what action followed. Logs should show the timeline from detection to closure and any lessons applied afterward. To check this internally, sample recent incidents, including minor ones, and confirm each has a complete timeline and a named decision-maker.
Contracts identifying key ICT dependencies
The institution must identify its key ICT third-party dependencies, even though entities under the simplified regime are excused from the full third-party strategy. Contracts with those providers should state the services provided, the locations of data and the support available during an incident. Check that each key dependency is named in a contract or service agreement that a reviewer can find within a short time.
Management body records on budget and yearly review
The management body must review ICT risk, roles, objectives and a dedicated budget at least once a year, and the control and internal audit functions must be independent with critical findings fixed in time. Minutes should show the review took place, what was decided and who owns each action. Check that the budget line for ICT exists, that the yearly review is minuted, and that open audit findings have dated remediation plans.
Questions trustees and administrators ask before bringing in help
Does DORA apply to a small occupational pension scheme?
It depends on the number of members and the criteria your national authority applies, so confirm the position in writing with the authority that supervises your institution. Article 2(3) of DORA excludes occupational pension institutions whose schemes together have no more than 15 members. Institutions that fall outside that exclusion are in scope, and a small institution for occupational retirement provision may then qualify for the simplified framework under Article 16(1). Ask your supervisor to confirm which category your scheme sits in, and keep a dated record of that confirmation in your governance file. Membership counts change over time, so review the position whenever membership moves toward a threshold.
Can our trustees and staff do the DORA work themselves?
Yes, if the people involved have the time, the technical knowledge and the authority to carry the work through. The work includes setting ICT risk roles and a budget, keeping a documented ICT risk framework, monitoring systems, handling and recording incidents, identifying key ICT dependencies, and testing backup and restoration plans. Under the simplified regime, the management body remains responsible for ICT risk, and Article 28 of Delegated Regulation (EU) 2024/1774 expects objectives and a budget to be reviewed at least yearly. Where the scheme relies on a small internal team or a single administrator, check whether someone can hold the control and audit roles independently. If not, external support for specific tasks may be more practical than a full engagement.
What drives the cost of DORA readiness for a pension scheme?
No fixed figure applies to every scheme, so the cost depends on the scope agreed before work starts. The main drivers are the number and complexity of ICT systems, including administration platforms, member portals and data stores; how many third-party providers and cloud services the scheme depends on; how mature current records, policies and testing already are; and whether the scheme hosts open-source platforms in its own infrastructure. Costs fall into one-time items such as gap analysis, policy drafting and initial testing, and recurring items such as annual reviews, backup testing and provider monitoring. Ask any provider for a written scope quote that lists systems, deliverables, assumptions and what the scheme must supply itself, and compare quotes on that basis.
How long does a DORA readiness project take for an IORP?
The timeline depends on scope, the state of existing documentation and how quickly decisions can be made by the trustee board. Ask for a plan divided into phases, such as scoping and gap analysis, policy and framework preparation, technical hardening and evidence collection, and an internal review before any supervisory contact. Each phase should have named deliverables, dependencies on the scheme's own staff and third parties, and a sign-off point. Be cautious of any provider who offers a fixed duration before reviewing your systems and contracts. A written schedule tied to the agreed scope lets the board track progress and decide where to add capacity.
Do we need a DORA certificate to show compliance?
No. DORA sets no certification scheme, so there is no DORA certificate to obtain. Competent authorities supervise compliance using their powers under Article 50, and they assess the evidence your scheme can produce, such as its ICT risk framework, incident records, testing results and provider arrangements. The only authority-issued attestation the Regulation provides for relates to threat-led penetration testing under Article 26(7), and that regime is generally not required for schemes in the simplified framework. Be wary of any offer to sell a DORA certificate, because no such certificate is provided for in the Regulation. If you want independent assurance on specific controls, an independent auditor can examine them and issue a report on what they found.
If our scheme is excluded from DORA, are there no other obligations?
No. An exclusion from DORA does not remove other obligations. Directive (EU) 2022/2556 amends Article 21(5) of IORP II so that occupational pension institutions manage their network and information systems in accordance with DORA where it applies, and national law and supervisory expectations continue to apply in every case. Trustees still have duties to manage the scheme prudently and to protect member data, and data protection rules under the GDPR apply to the scheme's processing regardless of DORA. Confirm with your supervisor which rules apply to your scheme specifically, and record that analysis so the board can show how it reached its conclusion.
What should we ask a provider before signing an implementation agreement?
Ask for a written scope that names the systems, the deliverables and the responsibilities of each party before any work begins. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside a client's own infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certificates, and only an independent auditor or competent authority can do that. Ask who keeps the records, who owns the controls, how exit and handover work, and what the scheme must maintain after delivery. Most engagements are fixed-scope, so the written scope should be the reference point for any change request.
How DeployOpen scopes DORA work for pension institutions
DeployOpen starts with a written scope that establishes whether the institution falls under the full regime, the simplified framework or the exclusion, then prepares systems and evidence against what applies. We plan, implement and document self-hosted open-source platforms inside the institution's own infrastructure, and an independent auditor or competent authority remains the party that assesses compliance.
How we scope
- We confirm with the institution its member count and whether its scheme falls under the Article 2(3) exclusion or the Article 16 simplified framework.
- We map which DORA obligations apply to the institution's ICT systems, outsourced services and governance arrangements.
- Engagements are fixed-scope, so the written scope sets out deliverables, timelines and responsibilities before any work begins.
How we build
- We set up or harden self-hosted open-source platforms in the institution's cloud accounts, data centers or air-gapped networks.
- We configure backup, restoration and continuity arrangements for critical or important functions, with tests scheduled at regular intervals.
- We document how logging, monitoring and incident detection work so the institution can show its ICT controls in operation.
How we hand over
- We deliver the ICT risk framework, policies and asset inventory in a form the management body can review and approve.
- We provide evidence packs that show configurations, test results and continuity exercises, mapped to the institution's own scope.
- We transfer operational knowledge and runbooks so the institution's staff can run, audit and update the systems after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
- Retainers can cover yearly reviews of the ICT risk framework and budget that the management body is expected to approve.
- Ask any provider to confirm in writing which assessment outputs they prepare and which the institution's independent auditor issues.
