MFSA ORSA and DORA: putting tested ICT risk into the own risk assessment

If you run risk or compliance at a Malta insurer, you probably searched for an ORSA tool at some point this year. The software question is real, but it hides a harder one: since January 2025, the part of your ORSA that covers ICT risk has to agree with a second regime, DORA, and the MFSA reads both.

This piece is about where those two meet, and what evidence makes the cyber section of an ORSA defensible.

What the ORSA actually asks for

The own risk and solvency assessment comes from Article 45 of Solvency II. Every insurer and reinsurer has to assess its overall solvency needs "taking into account the specific risk profile, approved risk tolerance limits and the business strategy of the undertaking", run that assessment regularly and without delay after any material change in its risk profile, and report the results to its supervisor.

EIOPA's guidelines on the ORSA go further on scope. Guideline 7 asks for a quantification of capital needs and a description of other means "to address all material risks irrespective of whether the risks are quantifiable or not", with stress tests or scenario analyses where appropriate. The same document expects the board to be aware of all material risks "regardless of whether the risks are captured by the Solvency Capital Requirement".

Cyber risk is the clearest example of a material risk the standard formula does not price well. That is exactly the gap the ORSA is supposed to fill.

What changed in January 2025

DORA names insurance and reinsurance undertakings as financial entities in scope, and the regulation applies from 17 January 2025. Alongside it, the DORA Amending Directive rewrote Article 41(4) of Solvency II: insurers must now "set up and manage network and information systems in accordance with Regulation (EU) 2022/2554", which is DORA itself.

The MFSA followed through locally. In December 2024 it published revised rulebooks transposing the DORA Amending Directive, including Chapter 6, System of Governance, of the insurance rules. That sits on top of the MFSA's earlier guidance on technology arrangements and ICT risk, which already applied to insurers and captives.

So the ORSA still covers ICT risk, but the controls behind that risk are now defined by DORA. Your ORSA and your DORA file describe the same exposure, and a supervisor can put them side by side.

Testing is where the evidence comes from

DORA is specific about testing. Article 24 requires a digital operational resilience testing programme as an integral part of the ICT risk management framework, and every financial entity other than a microenterprise must test all ICT systems and applications supporting critical or important functions at least yearly. Article 25 lists the tests, and penetration testing is on that list. Entities the supervisor designates must also run threat-led penetration testing at least every three years.

Put those obligations next to the ORSA and the link is plain. The ORSA asks you to describe and stress your material risks. The DORA testing programme produces the only first-hand evidence of how exposed your critical systems really are. If the cyber scenario in your ORSA is built from industry averages while your pentest report sits in another folder, the two documents are telling the supervisor different stories.

An ORSA that scores cyber risk without reading the last test report is a forecast with no observation behind it.

We wrote up the DORA testing requirements in detail separately, and the DORA view for insurers maps the obligations one by one.

What to do before the next ORSA cycle

1. Name ICT risk as a material risk in the ORSA policy. If it is material, say so, and say which DORA artefacts feed its assessment.
2. Wire test results into the cyber scenario. Use findings from the yearly tests on critical or important functions as inputs to the stress scenario, not a generic loss figure.
3. Align the calendars. Schedule DORA testing so fresh results land before the ORSA is drafted, not after it is filed.
4. Trigger an ad hoc review on serious findings. A critical, exploitable flaw on a core system can be a change in risk profile. Decide in advance who judges that.
5. Keep one evidence trail. The same report, with reproducible proof for each finding, should support both the DORA register and the ORSA narrative.

Two questions to take to your risk function on Monday: which pentest results did the last ORSA actually use, and how old were they when the board signed it?

Building Fleuret around exactly this gap: test evidence a risk function can put straight into its filings. See Fleuret in action.

Sources

• Directive 2009/138/EC (Solvency II), Article 45, Own risk and solvency assessment, legislation.gov.uk (EU directive as adopted)
• Final report on the Guidelines on own risk and solvency assessment, EIOPA-BoS-14/259, EIOPA, 2015
• Regulation (EU) 2022/2554 (DORA), Articles 2, 24, 25 and 26, consolidated text
• Directive (EU) 2022/2556, Article 2, amendments to Directive 2009/138/EC, OJ L 333, 27.12.2022
• Notice of Publication of MFSA's Revised Rulebooks transposing the DORA Amending Directive, Luigi Farrugia, Ganado Advocates, 2024-12-04
• How to ensure your company is compliant with the MFSA ICT Guidance, Ivan Spiteri and Benjamin Zahra, BDO Malta, 2021-06-30